Closed dla-discher closed 3 weeks ago
mastacontrola
commented
3 weeks ago Deploy tasks are "imaging tasks.
This means, you're telling the whole system to get a new image. As a part of that, it's assumed any snapins (all snapins) associated to the host will all be retasked as well.
If you only wanted to redeploy a specific snapin, you would use the advanced options and create tasks for each of the individual snapins you just added.
This is by design.
darksidemilk
commented
3 weeks ago I would recommend updating to at least 1.5.10 if you're still on 1.5.9, could be a long since fixed bug. Just associating a snapin shouldn't queue any tasks, should just associate. When doing an image task it's as tom describes.
dla-discher
commented
3 weeks ago Deploy tasks are "imaging tasks.
This means, you're telling the whole system to get a new image. As a part of that, it's assumed any snapins (all snapins) associated to the host will all be retasked as well.
If you only wanted to redeploy a specific snapin, you would use the advanced options and create tasks for each of the individual snapins you just added.
This is by design.
Thank you for clarifying. Also updating seems like a good idea as darksidemilk suggested.
Describe the bug Hello there,
as the title states, I was wondering wether this is intended or some kind of bug.
When associating a new snapin to a host or group via the “Snapins” tab it queues all previously already associated snapins, even though they were already deployed and succesfully installed. It also seems to always create a new imaging task for the client when doing this, even though the client has long been imaged already. When this happens the imaging task starts but wont run by itself and blocks any further deploying of all kinds of snapins until manually cancelled. Which of course makes sense because we’re not starting a network boot again for an already productive client but in reverse as mentioned blocks all further deployment of snapins or tasks.
Is my understanding of that feature wrong? Should associating only be used for imaging tasks? We tried using it so hosts would automatically get the missing snapins associated to them, not a completey new imaging with all associated snapins.
To Reproduce Steps to reproduce the behavior:
Expected behavior We expected that this procedure would only task the newly added snapin for hosts of the target group, something like an "update" button that would queue only the missing snapins for hosts that have already been deployed/imaged.
Software (please complete the following information):
Additional context Also sometimes the behavior was slightly different: only the newly added snapin would be visible in the tab 'snapin history', no other snapins would be shown here, even though the other ones were already associated for a long time. They apparently never got queued and were still missing even after adding the new snapin to the list like explained before.
Thanks already in advance.