Sascha Peilicke (speili...@suse.com) wrote:
> Hi guys,
>
> I recently wrote a barclamp to update system packages on deployed nodes.
> We will need this for SUSE Cloud to be able to deploy maintenance /
> security updates to customers. However, due to the nature of the
> barclamp, it isn't supposed to run all time. Instead, a cloud operator
> wants to trigger the federated update for a specific set of machines at
> a specific point in time.
Very nice :)
> In essence, this means the wrapped cookbook is a one-shot one. With only
> Chef-means, you would simply remove the updater recipe from a node's
> run-list afterwards [1]. However, since Crowbar doesn't store the
> run-list in the node object but a special role (crowbar-$FQDN) we seem
> to run out of luck with only chef means. Chef-client running on a node
> simply lacks the rights to modify a global role (i.e. remove a recipe
> from the role's run-list).
>
> The simplest approach would be to just use a special attribute in the
> cookbook that acts as the 'actually-do-something' switch, e.g.
> "defaults[:updater][:first-run] = true" which is then set to false after
> the recipe was applied. This way, the barclamp would end up in "ready"
> state showing success. But it's totally unclear for the user that the
> thing is actually one-shot or that he has to edit / re-apply the proposal.
I think this could be solved by including a flag in the barclamp which
indicates that it's one-shot, e.g. in crowbar.yml or just
def oneshot?
true
end
in the model or something, and then extending the UI to adjust to this
accordingly: changing button names, maybe even exposing info about
previous runs.
> So the idea was to deactivate the proposal immediately after it was
> applied so that it is obvious to the admin that he has to re-apply it
> (with a potentially different set of nodes). A first shot was to add a
> callback that is run after ServiceObject#apply_role [2],[3]. However, we
> won't end up in ready state thus no green bubble, thus there's no
> mechanism left to actually notify about success or failure. This could
> be mitigated somewhat with a new state that signals "I ran successfully
> and disabled myself".
But how would that interact with other roles being applied on the same
node, without resulting in confusion? The state is per node, not per
node role (in contrast to current design proposals for Crowbar 2.0).
> It will be very likely that we will have more one-shot barclamps in the
> future (e.g. evacuate-compute-node)
Agreed, this is good functionality to have for sure.
> therefore I'd like to get some
> feedback before going further in any direction.
I think I prefer the first approach above rather than introducing a
new state for the reasons given. But I could be missing something.
_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
