Agent should run tasks in a specific order

[mohierf]

I think that the agent should run the tasks in a specific order. Especially, it should always run the collect task before the inventory task.

Let me explain why... The collect task stores information with a Glpi computer and these information are available in a tab panel of the computer page. But these information may also be used in some rules of the FI plugin. As an example the computer status may be assigned from a variable collected from the computer registry...

The main problem is that the rules engine only runs when an inventory is imported into the DB.

If one is lucky the collect task runs before the inventory task and the Glpi computer information are updated on the first inventory, else one must wait for the next scheduled inventory which may happen only some hours later!

[mohierf]

Please note that this is a rela problem to me because I am using intensively registry collected information for more than 3k computers that report inventory only twice a day ... the best I can expect is to have fresh information in the Glpi computers only once a day... and it is not always reliable :/

[tabad]

Hello @mohierf,

I think the "idea" Set a prearranged (and tidy) tasks execution plan in UserEcho could help you.

Regards,

[mohierf]

Thanks @tabad

A great workaround !

[mohierf]

IMHO, the best task order would be:

1. Deploy
2. Collect
3. Inventory
4. WakeOnLan
5. NetDiscovery
6. NetInventory
7. ESX

Deploy first and then collect host information before inventorying because the FI Glpi plugin updates the inventory with the collected information before updating the DB 😉

If needed, run a collect + inventory jsut before deploying may also help if the deployment might fail...

[wawax]

Hi @mohierf ,

You can set your own workflow by uncommenting and using the following option : #tasks = inventory,deploy,inventory

We plan to totally rework this agent tasks scheduling when working on version 3.0

[g-bougard]

Hi @mohierf

The tasks option accepts to repeat a task and so the agent really runs the 2 tasks as @wawax show you.

Maybe you should try: tasks=inventory,deploy,collect,inventory,...

Really with the 3 dots after last comma, so agent knows it can run other tasks. But you also can just list all the tasks you want, removing the ones you don't need.

On my point of view, the actual design of server and agent communication doesn't permit to handle efficiently some cases. You're telling us the agent should behave in another way as the server has itself a specific comportment regarding Collect informations. We should also review how Collect informations are handled on server side and focus on a better design making Collect informations more reliable.

[mohierf]

Thanks @g-bougard The main point for the collected information is that the rules engine is only running when an inventory is managed by the server. As such, the information are available for the computer in the appropriate tab but the rules are not executed until the next inventory ... what is, IMHO, disappointing for the end-user.

[g-bougard]

So, are you telling us the issue is server-side finally ?

[mohierf]

No. I simply explain what I discussed with @ddurieux .

The information collected by the collect task are inserted into the computer information tab but ... if you define some rules using the collected information to update some computer information (eg. Status) this update will only happen when the inventory task is run.

This is quite disappointing for an aware user 😉

[g-bougard]

So what if the rules are also run as the Collect task result is received ?

Maybe the server should tell the agent it should run Collect task before inventory, this is actually not in the inventory protocol, but we can plan to add such support if the server devs request that. @ddurieux @trasher @orthagh @wawax ? What do you think ?

[wawax]

I'm perplex. I'm wondering if we did the right way... It would be much easier to add the collect infos to the XML inventory file. by doing so, we avoid task precedence problem, and we can process the inventory and then collect rules;

what do you think about that ?

[mohierf]

Collect and Inventory are two separate features ... you can collect information from files or Windows registry that are not related at all to your computer Inventory. IMHO, Collect and Inventory must remain separate tasks ...

The actual problem is that the collected information may be used in some rules to update the computer information AND that these rueles are not played unitl an inventory takes place ... if you never have any inventory, then the rules are never played!

Actually, the FI plugin updates the inventory information with the most recent collected information before playing the rules to update the computer. Perharps this update should be done only for the collected information once the collect is finished

I know tat @ddurieux will say that it is complicated and that the actual solution is easier 😉 ... easier for the developer, yes! But not easy to understand for the end-user...

[orthagh]

for collect, no idea, this part is also confusing on my developper pov. But, i think deploy should be by default before inventory. It's actually very confusing for the tech user to have a software deployed but not present in the inventory (and i need to explain everytimes). Also in a looping deploy scenaries (with dynamic rules), we need two agent execution to have the displayed job up to date (because 1min after deploy, dynamic groups re-prepare the job).

[orthagh]

the #tasks customisation exists, ok, but the default order si not good imo

[mohierf]

I agree with you @ortagh for Deployment to take place before Inventory. Indeed, Collect should also take place before Inventory because of the current server behavior: the collected information rules running when the inventory data are used to update the computers...

As such: Deploy -> Collect -> Inventory