Re: some questions


Chronological Thread 
  • From: Adam Jacob <adam@opscode.com>
  • To: chef@lists.opscode.com
  • Subject: Re: some questions
  • Date: Tue, 21 Apr 2009 01:43:36 -0700

Makes sense - you want to update the wiki page? :)

Adam

On Tue, Apr 21, 2009 at 1:15 AM, David Lee <david.lee@kanji.com.au> wrote:
> Sounds good.
>
> I'd like to propose a tweak: tags should be assignable to a node, cookbook,
> or role.
>
> a node's effective tag list would be the union of all of the above
> (including all roles & recipes).
>
> cheers,
> David
>
> Adam Jacob wrote:
>>
>> We've got some thoughts on how this might be accomplished, which I
>> just posted to the wiki at:
>>
>http://wiki.opscode.com/display/chef/Roles+and+Infrastructures
>>
>> The gist is adding three new concepts:
>>
>> 1) Tags
>>
>> Support for tags already exists, but we don't use it.  This is
>> essentially allowing you to easily tag/untag a given node, from the
>> ui, an attribute file, or a recipe.  Tags might be something like
>> 'dl380', 'ec2', etc.
>>
>> 2) Roles
>>
>> Right now, a node is configured based on the list of recipes it should
>> apply.  That will remain the same, but we're going to add another
>> layer on top, which is a 'role'.  In addition to the recipes that
>> would be applied, it will also contain a list of the cookbooks needed
>> to fulfill that role, and potentially any attributes that would need
>> to be set.
>>
>> A node wind up in a given role in one of two ways: manual placement or
>> tag matching.  Each role would have a set of tags that, if present on
>> a node, cause the node to automatically receive a given role.
>>
>> Nodes can have multiple roles.
>>
>> 3) Infrastructures
>>
>> Infrastructures are where you can define what roles are available for
>> a given environment.  Think 'production', 'testing', etc.  It would
>> also allow you to define a 'policy', which would be evaluated against
>> a given node and place it dynamically into roles.
>>
>> The ways this would change chef:
>>
>> A) We would be able to compute the exact set of recipes for a given
>> node, making sure we only ship the minimal set.
>>
>> B) It would allow for automatic assignment of recipes based on policies.
>>
>> C) It would eliminate the need for lots of small cookbooks that do
>> nothing but contain a default recipe full of 'include_recipe' - for
>> example, no more 'web_server' cookbooks.
>>
>> What do ya'll think?
>>
>> Adam
>>
>> On Fri, Apr 17, 2009 at 10:28 AM, snacktime <snacktime@gmail.com> wrote:
>>
>>>
>>> I actually have a similar need and was looking at how difficult it would
>>> be
>>> to add domains to chef.  So a domain could contain it's own cookbooks,
>>> nodes, etc..
>>>
>>> Chris
>>>
>>> On Fri, Apr 17, 2009 at 5:39 AM, AJ Christensen <aj@junglist.gen.nz>
>>> wrote:
>>>
>>>>
>>>> This is a major problem, and something we've discussed although no
>>>> concrete decisions going forward have been made.
>>>>
>>>> I'm interested in potential solutions for this, but walking recipes
>>>> (server) included on a node for include_recipe and only caching those
>>>> ones
>>>> seems like a pretty good solution.
>>>>
>>>> On 17/04/2009, at 11:48 PM, Miguel Cabeça wrote:
>>>>
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Chef client will cache all cookbooks available from the Chef server
>>>>>> each
>>>>>> time.
>>>>>>
>>>>>
>>>>> Does anyone else see a problem with this?This means any node managed by
>>>>> a
>>>>> chef server will have access to recipes, files and templates meant for
>>>>> any
>>>>> other node. If one node is compromised, the atacker will have access to
>>>>> sensitive data for that node and for any other node just by looking at
>>>>> the
>>>>> Chef client cache.
>>>>>
>>>>> I know that the chef server is dumb and all the smarts are on the chef
>>>>> client by design, but perhaps a smart move would be to give some recipe
>>>>> processing brains to Chef server. At least to let it make decisions
>>>>> about
>>>>> what coockbooks to provide to each client based on "include_recipe"
>>>>> directives.
>>>>>
>>>>> For now, I'll have to leave my multi-user machines outside of chef
>>>>> management because of that.
>>>>>
>>>>> I know that this may not be a big problem for the typical use of  Chef
>>>>> that I'm aware of (Web app server farms), for for my usage scenario
>>>>> (Computer center of a major University in Portugal, with servers,
>>>>> multi-user
>>>>> clusters and personal workstations) it is.
>>>>>
>>>>> What are your thoughts on that?
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Miguel Cabeça
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>>
>
>



-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com



Archive powered by MHonArc 2.6.16.

§