Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Associating a new Snapin, queues complete chain of previously associated snapins. #584

Open
dla-discher opened this issue Feb 20, 2024 · 0 comments

Comments

@dla-discher
Copy link

dla-discher commented Feb 20, 2024

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:

  1. Go to 'Groups'
  2. Select Target Group
  3. Go to the tab "Snapins"
  4. "Click to see what snapins can be added"
  5. Selected target snapin and click "Add"
  6. Go to Basic Tasks and hit "Deploy"

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):

  • FOG version [1.5.9]
  • FOS kernel [4.19.0-17-amd64]
  • OS: [Debian GNU/Linux 10]

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant