Project

General

Profile

Actions

Bug #6944

closed

The inventory-endpoint outputs a successful HTTP error code even if the inventory can not be stored

Added by Matthieu CERDA over 9 years ago. Updated about 9 years ago.

Status:
Rejected
Priority:
2
Assignee:
Matthieu CERDA
Category:
Web - Nodes & inventories
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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

Actions #1

Updated by Matthieu CERDA over 9 years ago

  • Priority changed from 5 (lowest) to 2
Actions #2

Updated by François ARMAND over 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.

Actions #3

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.0.8 to 3.0.9
Actions #4

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.0.9 to 3.0.10
Actions #5

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 3.0.10 to 3.0.11
Actions #6

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 3.0.11 to 3.0.12
Actions #7

Updated by Matthieu CERDA about 9 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 !

Actions

Also available in: Atom PDF