[chef] Re: Re: Re: Re: One-Shot runlists with inheritance

[Rob Guttman < >]

> If anyone else has opinions on any aspect of one-off run lists, please respond, as well.

I don't know if this is classified as a "one-off run list" but it's certainly in the camp of orchestration models.  We have a need to deploy to a cluster of nodes behind a load balancer.  We want to pull one out of rotation, deploy code and configs, smoke test it, and if it passes, put it back into rotation then serially move on to the next one, etc.  I can provide more details offline if this use case would be helpful to you, Chris.

Regards.
- Rob

On Fri, Jan 28, 2011 at 2:12 PM, Chris Walters < "> > wrote:

Dan,

Absolutely. One-off run lists are one of the most requested features. They also fit into some of the preliminary discussions we've had about orchestration models. We plan to get a design together for one-off run lists in the next few weeks to share with the community for feedback.

If you're willing to comment on your use case more, here are a few questions that I have.

For your use case, does the multi-node solution with a shared base run list work, or do you actually need to have only one node object for the purpose of searching?

Should run lists be first-class objects instead of just properties on nodes and roles? Should they be able to contain not only roles and recipes but run list-containing entities (nodes and other dis-embodied run lists), as well?

If anyone else has opinions on any aspect of one-off run lists, please respond, as well.

Thank you for your input.

-chris

On Fri, Jan 28, 2011 at 7:31 AM, Dan Nemec < " target="_blank"> > wrote:

So, the obligatory next questions is:

"Is this anywhere on the roadmap?"

Thanks for the suggestion about multiple nodes. We'll play with that and see if it may be a workable, but not ideal solution.

Dan

On Wed, Jan 26, 2011 at 5:46 PM, Chris Walters < " target="_blank"> > wrote:

Hi Dan,

There isn't currently a way that I can think of to run one run list after another except to package up the main run list into a role and prepend that role to the one-off run list's items.

As for one-off run lists, there isn't currently a built-in solution. Since a single server can be managed by many chef nodes, one way to do it is to have different JSON files like you do, but run them as different nodes. Something like:

infrastructure maintenance runs:

"chef-client -j infra-maint.json -n node-XYZ-infra-maint"

deployment team runs:

"chef-client -j deployment.json -n node-XYZ-deployment"

etc.

Does that help?

-chris

On Wed, Jan 26, 2011 at 1:55 PM, < " target="_blank"> > wrote:

We have run into an interesting problem. We want to segregate runlists by
activity (e.g infrastructure maintenance, deployment, one-off, etc…). But we
want all the runlists to share some common role information about a node. We
have a node that has some roles (datacenter, servergroup, tier) that are
important identifiers and drive selection of certain attributes. We want
different groups to be able to do maintenance on their parts at different times
without impacting others. So if a sysadmin wants to update /etc/hosts he
shouldn’t have to worry if the application team has put in a new attribute
for a deployment later. The sysadmin can run a runlist that only affects the
parts of the system he is responsible for without worrying that an application
deployment recipe will run. Conversely in a software deployment the deployment
team should be able to update the applications without updating the operating
system (given the os changes are not part of the software deployment).

I thought “chef-client -j” would do this, but it didn’t. This is what I
did: I created a node and bootstrapped it with a runlist of its identity roles.
I then made a json file with a  runlist for a set of activity and ran the
runlist via “chef-client -j <jsonfile>”. The problem is that the runlist
for the node that existed before chef-client gets wiped out and only the
runlist in the json file gets run thus wiping out its “identity” and
breaking the one-off runlist because certain attributes no longer exist.

I’d like to be able to append a runlist on the fly to an existing runlist on
the node where the new runlist exists on the node only for the duration of the
chef-client run. The node has a “base” runlist that should always be run,
but I want to run some other recipes and roles one at a time while keeping the
“base” runlist. I do not want to have to copy the base runlist into the
json file of the one-shot runlist that I am running as I’m trying to keep the
“activity” runlists environment independent.

Is there a way to run a one-off runlist on a node that is effectively appended
to the runlist that is already on the node and is removed after the run?

Thanks,

Dan