[NEW FEATURE] Full inventory postpone or reduce inventory size most of the time

[g-bougard]

We implemented a new configuration variable named full-inventory-postpone. The purpose is to reduce the inventory size sending partial inventories with only the changed categories.

It works in the following way:

1. the inventory task runs as usual
2. before sending a full inventory, the agent computes a sha256 digest of the collected datas for all supported category
3. if the digest found didn't change from the previous run for a given category, the agent can decide to:
   1. remove that category part from the inventory
   2. and set the partial inventory property

That last step is the way the agent can make a "full inventory postpone". There are few conditions to make this possible:

• if the target is a GLPI server, it must be a GLPI 10,
• if the target is local, the json option must also be set,
• native inventory must be used and json format must have been negotiated with the server: the partial inventory property is only supported in that case,
• full-inventory-postpone must be set to a non null positive value. Actually its value is set by default to 14.

The postpone number is stored with the digests. It grows until it reaches the configured value. The next time the inventory task runs, the full inventory won't be postponed, so a full inventory is sent or stored and the postpone number stored with digests is set to 0. So with the default value, the agent can postpone 14 times the full inventory sending and the 15th will always be a full inventory. With the default inventory delay set to 24h on server-side, this means an agent will send a full inventory after 2 weeks.

The main goal of this feature is to reduce load on GLPI servers with a big number of assets to integrate.

Before this feature, the category digest was still computed but only for a restricted number of categories. This was only used to output a line in log to tell which category changed. Now most category digests are computed. One of the required change was to make the inventory output consistent when a category doesn't change. In that way, some category should now report their objects list ordered. This involves you'll be able to make a diff on 2 inventories and only the really changed categories should appear in the diff.

As a reminder, you can see all the inventory categories in the glpi-agent man page. By default, digest won't be computed for accesslog and provider. The first because it changes all the time as this is indeed the inventory run date. The second because it's used for debugging purpose as it reports the used agent. By default, bios and hardware categories will always be kept even if they didn't change in inventory as they are simply required by GLPI to integrate consistently the inventory with the known asset: import and update rules required few properties from these categories.

As example, for linux, the largest category in inventory is the software one. It may change often but this depends on the frequency softwares are updated. When no change is found, this can reduce the inventory size up to 90%. This is also valid for windows, but the size reducing will probably be lower.

What to know about this feature at the time of this writing:

• no dedicated variable has been defined for MSI windows installer. This anyway should be before the next release. But you'll still be able to create the full-inventory-postpone key in registry using string format and set it to another value or even disabling it with 0.

If you want to get involved in that feature evaluation, we would appreciate all feedback and thought about the feature by itself. From the technical perspective, we would appreciate a feedback if you find a category which is still included even if it didn't really change. This could be the sign we still need to reorder a list reported for the category.

[g-bougard]

UPDATE:

• FULL_INVENTORY_POSTPONE has been added as option to MSI Installer
• --full-inventory-postpone is now supported by glpi-agent script
• --full is also a new option for glpi-agent script to force a full inventory

TODO:

• Update documentation

[erique-souza]

UPDATE:

• FULL_INVENTORY_POSTPONE has been added as option to MSI Installer
• --full-inventory-postpone is now supported by glpi-agent script
• --full is also a new option for glpi-agent script to force a full inventory

TODO:

• Update documentation

I have a question about this, the information today already exists correctly in version 1.11 after installation, that is, if I have the agent installed and I say glpi-agent --help it appears normally, as described in the documentation

However, at installation time, the --full-inventory-postpone and --full parameters are currently not accepted, and if we give the command: perl glpi-agent-1.11-linux-installer.pl --help it does not exist in the description installation, I believe the declaration in the .pl file is missing for it to work correctly

I noticed the same behavior for: delaytime

[g-bougard]

Hi @erique-souza

about --full option, it can only be used with glpi-agent script for one run to punctually force a full inventory. This is not a configuration option, so it's normally not usable with installer.

About --full-inventory-postpone, this has been fixed in 03222e3 to fix #792 issue... which is an issue reported by yourself.

Actually, you can use installer from nightly builds with this option: https://nightly.glpi-project.org/glpi-agent/ and next release will support this option.

About --delaytime, can you open a dedicated issue ?

[erique-souza]

Hi @erique-souza

about --full option, it can only be used with glpi-agent script for one run to punctually force a full inventory. This is not a configuration option, so it's normally not usable with installer.

About --full-inventory-postpone, this has been fixed in 03222e3 to fix #792 issue... which is an issue reported by yourself.

Actually, you can use installer from nightly builds with this option: https://nightly.glpi-project.org/glpi-agent/ and next release will support this option.

About --delaytime, can you open a dedicated issue ?

Thanks for the guidance.

Regarding open delaytime
#816