-------- Original Message -------- Subject: Re: [Crowbar] one-shot barclamps Date: Fri, 14 Jun 2013 16:08:48 +0200 From: Sascha Peilicke <[email protected]> Organization: SUSE To: [email protected] CC: Adam Spiers <[email protected]> On 06/12/2013 03:13 PM, Judd Maltin wrote: > Hi Sascha and Adam, > > Adam's on the right track with the flag to exit a recipe if it's "one shot." Sure, I uploaded something at https://github.com/SUSE-Cloud/barclamp-updater for which I would like to get some feedback. So the solution is now centered about the presence of a special normal attribute (or lack thereof): node[@bc_name][:one_shot_run]. If set to true, it marks that the one-shot recipe was indeed run. So the idea is to just reset/delete this attr when commiting the proposal again. As far as I understand the code, this should happen in (subclassed) ServiceObject#apply_role_pre_chef_call, i.e. like this: https://github.com/SUSE-Cloud/barclamp-updater/blob/master/crowbar_framework/app/models/updater_service.rb#L46 However it seems like manipulating normal attributes doesn't seem to have a persistent effect. After node.save, the underlying Chef::Node object indeed has the right attribute, even after fetching it with Chef::Search:Query again. But when I do a "knife node edit $NODE" afterwards, the node still has [:updater][:one_shot_run] present in the normal attrs. Supposedly I've made a logical mistake somewhere but it seems like I ran out of ideas ;-) > We do have a script in /opt/dell/bin called on-node, which will > probably also do what you like. > > The larger issue, and especially for Crowbar 2.0, is the very nature > of one-shot vs. continuous, eventual convergence. There be some > pretty severe demons here once you get into any level of complex > system interdependence. This is a topic we'll be expanding on in the > orchestration design for Crowbar 2.0, hopefully providing some sane > primitives. > > I'd be eager to continue fleshing out these ideas on the Community Design > call. > > -judd > > > > On Wed, Jun 12, 2013 at 7:17 AM, Adam Spiers <[email protected]> wrote: >> Sascha Peilicke ([email protected]) 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 >> [email protected] >> https://lists.us.dell.com/mailman/listinfo/crowbar >> For more information: http://crowbar.github.com/ > > > -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
