Bug #6944
closed
The inventory-endpoint outputs a successful HTTP error code even if the inventory can not be stored
Description
I tested on a 3.0.6 switching rudder-slapd to mdb instead of hdb (which is the default).
mdb creates fixed size databases, which by default give little room for storing stuff (about 10M by default, as seen in the manpage:
maxsize <bytes>
Specify the maximum size of the database in bytes. A memory map
of this size is allocated at startup time and the database will
not be allowed to grow beyond this size. The default is 10485760
bytes. This setting may be changed upward if the configured
limit needs to be increased.
I then happened to store a large amount of inventories with stess_suite/tsung to test something.
Of course, after a few seconds I hit the storage size limit and something funny happened:
agent:
2015-06-17T13:08:21+0000 info: /default/sendInventoryToCmdb/files/'/var/rudder/inventories/incoming'[0]: Code: 202 2015-06-17T13:08:21+0000 info: /default/sendInventoryToCmdb/files/'/var/rudder/inventories/incoming'[0]: Transformer '/var/rudder/inventories/incoming/RDR-TST-RandHost00-8b9ea23e-7c02-4f79-a31c-96e85d1c715d.ocs' => '/var/rudder/tools/send-clean.sh http://localhost:8080/endpoint/upload/ /var/rudder/inventories/incoming/RDR-TST-RandHost00-8b9ea23e-7c02-4f79-a31c-96e85d1c715d.ocs /var/rudder/inventories/received/ /var/rudder/inventories/failed/' seemed to work ok 2015-06-17T13:08:21+0000 info: /default/sendInventoryToCmdb/files/'/var/rudder/inventories/incoming'[0]: Transforming '/var/rudder/tools/send-clean.sh http://localhost:8080/endpoint/upload/ /var/rudder/inventories/incoming/RDR-TST-RandHost3131-c15081e0-afa2-48c0-8e02-f0ba13ea41f9.ocs /var/rudder/inventories/received/ /var/rudder/inventories/failed/'
=> Inventory accepted, promise successful
webapp log:
[2015-06-17 13:08:21] ERROR com.normation.inventory.provisioning.endpoint.FusionReportEndpoint - Error when trying to process report: Can't merge inventory report in LDAP directory, aborting <- Can not apply modifiction on 'machineId=80975353-43a3-ac2a-0eda-c1db2f58dc07,ou=Machines,ou=Pending Inventories,ou=Inventories,cn=rudder-configuration': entry update failed <- Can not apply modifiction on 'nodeId=8b9ea23e-7c02-4f79-a31c-96e85d1c715d,ou=Nodes,ou=Pending Inventories,ou=Inventories,cn=rudder-configuration': entry update failed <- : Can't merge inventory report in LDAP directory, aborting [2015-06-17 13:08:21] INFO com.normation.inventory.provisioning.endpoint.FusionReportEndpoint - Report file processed in 80 milliseconds
Updated by François ARMAND almost 9 years ago
- Status changed from New to Discussion
- Assignee changed from François ARMAND to Matthieu CERDA
Well, actually the inventory was accepted, but not correctly saved. This is two separated tasks, and the separation is for the following reason:
- accpeting inventory (check xml, check mandatory attributes): in the 100ms order of magnitude
- saving the inventory, merging existing attribute, updating data in backend: 1-20s.
We don't want to force the agent to wait 1-20s x nb_inventory_to_accept for the run.
That means that we can't have error happening in the second part reported to cf-agent. And that's why we only promise to having correctly sent the inventory to endpoint.
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.0.8 to 3.0.9
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.0.9 to 3.0.10
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.0.10 to 3.0.11
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 3.0.11 to 3.0.12
Updated by Matthieu CERDA over 8 years ago
- Status changed from Discussion to Rejected
Well then it is expected behavior. And actually, if the mdb limit is reached / the slapd service is ill, the user would notice it (the webapp would misbehave.)
Rejecting then !