Bug #4265
onegate append new attributes instead of replacing existing
Status: | Closed | Start date: | 12/23/2015 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | Ruben S. Montero | % Done: | 0% | |
Category: | Core & System | |||
Target version: | Release 5.0 | |||
Resolution: | worksforme | Pull request: | ||
Affected Versions: | OpenNebula 4.14 |
Description
When pushing monitoring attribute values through onegate they are appended, not replaced.
The result is many attributes with the same name what crashes oneflow-server.
Related bug is http://dev.opennebula.org/issues/4258.
Related issues
History
#1 Updated by Ruben S. Montero over 5 years ago
- Related to Bug #4258: oneflow-server crashing added
#2 Updated by Ruben S. Montero over 5 years ago
- Category set to 37
- Target version set to Release 5.0
#3 Updated by Daniel Molina over 5 years ago
- Assignee set to Daniel Molina
#4 Updated by Daniel Molina over 5 years ago
I can't reproduce this issue. Could you send us the command you are using to push these new values?
#5 Updated by Daniel Molina about 5 years ago
- Assignee deleted (
Daniel Molina)
#6 Updated by Rolandas Naujikas about 5 years ago
Daniel Molina wrote:
I can't reproduce this issue. Could you send us the command you are using to push these new values?
"Sample Application Monitoring Script" from http://docs.opennebula.org/4.14/advanced_administration/application_insight/onegate_usage.html
It creates multiple attributes NAME/VALUE tags in VM XML body with the same NAME.
#7 Updated by Ruben S. Montero about 5 years ago
- Assignee set to Ruben S. Montero
#8 Updated by Ruben S. Montero about 5 years ago
- Status changed from Pending to Closed
- Resolution set to worksforme
This is not in 5.0 at least. Creating a VM with TOKEN=YES in CONTEXT, ssh it and execute:
[root@localhost ~]# onegate vm update --data READY=YES [root@localhost ~]# onegate vm update --data READY=YES [root@localhost ~]# onegate vm update --data READY=YES [root@localhost ~]# onegate vm update --data OTHER=YES [root@localhost ~]# onegate vm update --data OTHER=YES [root@localhost ~]# onegate vm update --data OTHER=YES [root@localhost ~]# onegate vm update --data OTHER=NO
I get from oned:
USER TEMPLATE OTHER="NO" READY="YES"
Thanks
#9 Updated by Rolandas Naujikas about 5 years ago
I retested with a customer VM, which uses oneflow service template and monitoring script from http://docs.opennebula.org/4.14/advanced_administration/application_insight/onegate_usage.html.
Finally got the cause of problem. A customer improperly implemented monitoring script and it was always adding new values to the end of metrics file with the same names in every monitoring cycle.
But it rise another DoS problem on OpenNebula service. Onegate accepts unlimited size of attributes/values and that could slow down the OpenNebula service to impossible to use level. We saw VM XML body grow to >1MB that made every operation require >30s to wait and impossible to use Sunstone.
#10 Updated by Ruben S. Montero about 5 years ago
Rolandas Naujikas wrote:
I retested with a customer VM, which uses oneflow service template and monitoring script from http://docs.opennebula.org/4.14/advanced_administration/application_insight/onegate_usage.html.
Finally got the cause of problem. A customer improperly implemented monitoring script and it was always adding new values to the end of metrics file with the same names in every monitoring cycle.
But it rise another DoS problem on OpenNebula service. Onegate accepts unlimited size of attributes/values and that could slow down the OpenNebula service to impossible to use level. We saw VM XML body grow to >1MB that made every operation require >30s to wait and impossible to use Sunstone.
Totally agree. I've filled an issue for this #4479. Not sure if this can be done for 5.0, though. But something we want to tackle after that.
THANKS!