[chef] Re: Identifying if a node is being bootstrapped

["John E. Vincent (lusis)" < >]

On Fri, Mar 9, 2012 at 12:55 PM, Bryan McLellan 
<
 >
 wrote:
> On Fri, Mar 9, 2012 at 1:04 AM, John E. Vincent (lusis)
> <
 >
>  wrote:
>> Came across a situation tonight that I wanted to get feedback on. I've
>> got some standard patterns I use for dealing with TRUE one-time run
>> recipes.
>>
>> Thoughts?
>
> Maybe you are making this too complicated and hard on yourself?
>
> Why is the work done by the resources in the recipe not idempotent?
> If that is complicated, why not wrap the whole recipe in a wrapper
> that prevents it from happening again?
>
> unless File.exists('/opt/app/.done')
>  # do stuff
>
>  # done with stuff
>  file "/opt/app/.done"
> end
>
> If you do a lot of on every system, maybe a 'bootstrap' role that is
> in the beginning of a run list for all nodes that contains the
> bootstrap recipes?
>
> Bryan

That's pretty much exactly what I had to do.

As to the idempotent question, I'll give a bit of background as to why
it needed to be done that way:

(please note this applied to my previous company)

We had our application code stored in S3. We did not use the
application cookbook because it didn't fit our model.

So when we provisioned one of our components, the "bootstrap" process was:

- Download tarball of latest released code from S3
- extract tarball
- Move some files around because the tarball didn't actually reflect
the final on-disk representation (long story as to why that wasn't
modifiable at the time)
- run some commands that HAD to be run on the local system and
couldn't be packaged (think compiling of sorts)
- Start jetty

Each and every one of those steps ONLY needed to be run to bootstrap a
new node of that type of application. Deploys to that app server from
that point on were done via jenkins. Having it run again meant wiping
out any newer app code we pushed.

The way I worked around this (though it was HIGHLY fragile and scared
me from day one was:

- move onetime operations into a bootstrap recipe
- move the steps of moving files around into a template shell script
that got called
- Shell script created a dotfile akin to what you describe that I
could use in a not_if guard
- use notifications to trigger the compilation-alike behaviors
- start the server
- remove the bootstrap recipe from the runlist

Again, while it was fragile it worked 100% of the time. The problem
was around training and teaching others. It would have been nice if I
could simply said 'bootstrap the node with this role' but instead it
was 'bootstrap the node with this role and this recipe'. I'm a big fan
of composition in roles and I personally prefer a server to have a
single role (even if it's made up of 20 other roles). Yes it's a bit
of extra hierarchy but it's easier to for people to grok (I think)
instead of a top-level run_list that's got roles, recipes and more
roles.

As I said, I'm not at that company anymore but I was running into a
similar need at enStratus. AWS does a lot of things for you that you
take for granted. I needed to do some cloud-init type work as part of
the initial bootstrap of our private cloud nodes. Now I just (as of
about an hour ago) discovered that Cloudstack indeed has meta-data and
user-data support so my original needs are not the same.

The question still stands (and I think there's a valid use case for
it). A good example has already come up several times - changing the
hostname of a system. You only need to do it once, reload ohai, and
continue on with the run. It's not something you need to do more than
once and it's not something you WANT to do every single run.

Hope that clears up the issue/question?