- From: Hedge Hog <
>
- To:
- Subject: [chef] Re: Re: Request for input on orchestration
- Date: Sun, 30 Jan 2011 18:27:02 +1100
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=W1rs8wXG7ZqtQKHJV8P4VkcqyoQpi0NevnllUxHm3SsYCB3pTETHlRm1ziglbdJ87M +fgHhkVmYc1NiEdivMXhLk8QI8m+p04R9A9zKIEeetWdPVx17F2lFqLpB8LHXEg53mZe kADHqUGdtDolOB/w2iIQhBt3NBQB/9GSk412M=
On Sat, Jan 29, 2011 at 8:19 AM, Dan Nemec
<
>
wrote:
>
Mandatory disclosure. We've been using Control Tier for over a year.
>
I don't know that I am interested in Chef being the orchestration engine. I
>
would like to see Chef more friendly with other existing orchestration
>
tools. Control Tier is great if you want to code much of your customized
>
commands into the tool. The spinoff RunDeck is great if you have your own
>
scripts but just need them orchestrated.
>
We envision a scenario where Chef is mainly configuration and Control Tier
>
is orchestration. We would go so far as having Chef configure Control Tier
>
which could then call back to Chef to initiate Chef actions.
>
Orchestration is a difficult problem and Control Tier/RunDeck is already
>
fairly mature. Now that they support arbitrary workflows in Jobcenter
>
Control Tier is't missing any feature we require for orchestrating our very
>
complex deployments.
>
I don't know that I have much to add to your questions above. We're fairly
>
new to Chef and it being Friday afternoon is making my head hurt thinking of
>
how to incorporate orchestration into Chef. All I can imagine is how we're
>
doing it today with Control Tier.
>
1) You hit the high points in your overview of scope.
>
2/3) All I can say is to read Control Tier's documentation. In Control Tier
>
you define a "command" that performs a piece of work. You string a bunch of
>
commands together into a workflow. Then you can also string different
>
workflows into larger events. You add to that the error-handling and gating
>
so that the next step only executes after the first one completed
>
successfully. Threading concurrently across servers is mandatory to make it
>
go fast.
>
Happy Friday,
>
Dan
>
>
On Fri, Jan 28, 2011 at 3:26 PM, Chris Walters
>
<
>
>
wrote:
>
>
>
> Ohai Chefs!
>
> We're in the preliminary stages of designing possible solutions for
>
> orchestration and would like to understand the community's
>
> requirements.
>
> I'm going to write down my thoughts and questions. Nothing is gospel,
>
> so please feel free to comment on everything, including the framing.
>
> Background:
>
> Chef, as currently conceived, does a great job of exposing a model for
>
> how to get a system from either an embryonic state or a slightly
>
> misconfigured state to the desired state, mainly via the mechanism of
>
> resource idempotence.
>
> What I think is not yet well-modeled is how to go from one
>
> well-configured state to a completely different well-configued
>
> state. It also doesn't yet model synchronization of actions across
>
> multiple boxes in that there isn't a first-class way to gate actions
>
> that are dependent on the completion of steps on other servers. For
>
> example, a complex migration or deployment might require bringing
>
> boxes up or down, copying data, cleanly removing artifacts or services
>
> installed by previous chef runs, not restarting load balancers until
>
> some quorum of webservers have re-started, etc.
>
> We'd like to collect the use cases, requirements, and thoughts that
>
> best serve the community.
>
> 1) What do you think the scope of orchestration is and is not?
>
> 2) What are the use cases that you would like to see an orchestration
>
> system/DSL accommodate? The more specific and granular the steps of
>
> the orchestration, the better. (If you would not like your use case
>
> made public but would nonetheless like it considered during design,
>
> validation, and testing, please send it to me directly at
>
>
)
>
> 3) What generic primitives do you think would be useful in such a
>
> system?
>
> Thanks!
>
> Chris Walters
>
Orchestration is something I have yet to deal with. It will loom and
I had in mind to try and use Ruote[1].
RunDeck sounds like it might be a specialized (aka limited?) workflow engine.
Given ruote-kit (RESTful)[2], ruote-jig[3] decision tables[4],
persistence, ampq, etc. etc. I'd be surprised if solving Chef
orchestration didn't involve adopting/employing a subset of ruotes
existing functionality.
As mentioned any chef specifics could be placed in a ruote-chef project?
I think a route-chef project might give biggest bang-for-the-buck.
[1]
http://openwferu.rubyforge.org/
[2]
https://github.com/kennethkalmer/ruote-kit
[3]
https://github.com/jmettraux/rufus-jig
[4]
http://jmettraux.wordpress.com/?s=decision+tables
HTH
--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
Archive powered by MHonArc 2.6.16.