Now that we no longer have the Inventory distro, we have to create a new job and add the inventory task. What would be nice is a more convenient way of doing this. Adding a ksmeta var into the kickstart might be slightly easier. Even easier, would be having a button on the system page that added this for us, and kicked off a job.
Related to this, it would be nice if there was an alternative to hostRequires that only worked for explicitly named machines, but ignored the system status. That way, maintainers/users could just click the inventory button on the system page, even if the system state was set to Manual or Broken.
(In reply to Raymond Mancy from comment #0) > Now that we no longer have the Inventory distro, we have to create a new job > and add the inventory task. > > What would be nice is a more convenient way of doing this. > > Adding a ksmeta var into the kickstart might be slightly easier. > Even easier, would be having a button on the system page that added this for > us, and kicked off a job. +1 to the idea of having a button on the system page which kickstarts a inventory job for the system.
Ultimate goal was to have a live image that would be able to push the inventory data up. That would allow us to inventory systems without re-provisioning them.
Bug 851354 adds the ability to run recipes on Manual and Broken systems by explicitly specifying a system rather than using normal host filtering, which is one of the requirements to make it easier to properly test systems before putting them back into service. That leaves this issue to cover providing both a simple bkr CLI command and a button in the web UI to rescan a system. However, to avoid having to implement it twice, such a change should likely wait until after the system page redesign.
Bug 1121462 now covers the addition of a dedicated "bkr update-inventory" command, so this issue has been narrowed in scope to just providing an inventory button in the web UI (which won't happen until after the system page changes are merged).
The system page changes landed in Beaker 19, so perhaps we could look at implementing this one in a 19.x release?
I think we discussed a new API endpoint to implement this. Something like: GET /systems/<fqdn>/inventory I am not sure GET is really the right HTTP method for this, but that seemed to be the most suitable. It is the responsibility of the server to figure out the most suitable distro for the system and submit a beaker job containing the /distribution/install and /distribution/inventory tasks.
Started a beaker-devel thread to discuss this: https://lists.fedorahosted.org/pipermail/beaker-devel/2015-May/001242.html
http://gerrit.beaker-project.org/#/c/4201/
Beaker 21.0 has been released.