Re: some questions

[Adam Jacob <adam@opscode.com>]

First off, this email is great, Miguel.  Thanks for putting so much
thought in to how to make Chef better. :)

It's 12:24am PST right now, but I wanted to get something out before I
go to bed.  I'll follow up with more detail in the morning.

On Wed, Apr 22, 2009 at 5:57 AM, Miguel Cabeça <cabeca@ist.utl.pt> wrote:
> I think there are four new concepts in this description, the fourth being
> the policy that was mentioned on B). As I told Adam on #chef, there are four
> new concepts to add to the existing Nodes, Cookbooks, Recipes, Definitions,
> Attributes, Libraries, Files, Templates, Resources, Providers and Search
> Indexes. It will steep even more the chef learning curve.

That may be true.  I think there are two parts to Chef having a high
learning curve right now: one is that it is early enough in
development to be in flux, the other is that we still need to write
documentation that guides users through the process clearly.  Roles
and Infrastructures are both things that people already essentially do
with Chef today - we just don't call them that.

> I think this is a bit of over-engeneering, at least to solve the original
> all-cookbooks-to-all-clients security problem I've mentioned. And it may not
> solve the problem completely. If the chef server unit of access control is
> the cookbook, it will be impossible to have sensitive data in one cookbook
> that has recipes for multiple types of servers. For example I have a postfix
> cookbook with postfix::sattelite, postfix::relay and postfix::store recipes,
> the postfix::relay serves remote files with sensitive data that the
> postfix::sattelite should not have acess to.

In the case outlined for Roles and Infrastructures, you should only be
served the components of the cookbook that are required for your Role.
 Essentially, a postfix::relay machine would get the postfix::relay
recipe, but none of the others in that cookbook.  Files and Templates
both get transferred when they are used, not up-front, so any
sensitive data you store there would only live on the Chef Server and
the nodes themselves.

You bring up a good point here (and again later) regarding the fact
that any chef client can request any file or template, which isn't
resolved by this mechanism, and I think may lead to a change in the
cookbook file structure.   I'll talk more about this tomorrow.

> I have some (maybe uninformed) opinions on the new concepts introduced:
>
> 1) Tags : I don't see the diference of this and an attribute of the node
> named 'tags' that could be set automaticaly or manually in a recipe.

That is exactly what the implementation would be. (In fact, it's
already their - we just aren't using it.)

> 2) Roles: I've implemented this already as a toplevel cookbook with several
> recipes in it. Each node has  one or more of this recipes like for example
> role::mailstore, or role::ldapmaster or role::kerberoskdc. It's not dynamic,
> but is there a need for this to be dynamic?

There are a couple reasons why roles are handy: they could be defined
easily without any need to write code (processing the ruby recipes on
the server is less than ideal, given the fact that it's just ruby -
who knows what the code might do, especially if it came from a third
party repository,) they let us group cookbooks together for
distribution, and they provide for dynamic assignment.

The dynamic assignment use-case is useful, but I agree it's not
super-high on the list of things that need to get done.  As one
example, you might have a specific set of configuration based on
whether the system is an HP DL380, running Ubuntu 9.10 and a member of
a Hadoop cluster.  All of that could be accomplished with a cookbook
and some fancy footwork, but now we're really starting to overload the
things you can/should use recipes for - and we would require that to
happen at the edge, which means we need to ship the ruby there before
we execute it.

> 3) I didn't understand the use for this concept. Doesn't this overlapp with
> roles? A 'testing' infrastructure should have nodes with 'testingX' roles

You might have different sets of roles, or even different sets of
cookbooks, based on the infrastructure.

> 4) I didn't understand this policy concept either.

I think we didn't do a very good job of explaining it! :)  I'll
expound on this tomorrow.

> I'm afraid that the complexities involved in implementing all this features
> will postpone the resolution of the all-cookbooks-to-all-clients problem.

I'm definitely interested in getting it fixed sooner rather than
later.  I think we all agree on that. :)

> I was thinking of an approach based on scanning all recipes on chef server
> for include_recipes, remote_file and remote_directory resources. That would
> build an ACL that would allow only authorized nodes to acess the resources.

Scanning the recipes on the server is something I'm trying really hard
to avoid.  The prime reason is a strong desire to not be executing
arbitrary code on the system responsible for distributing the
configuration information to the edges.

More to come, but feel free to follow up before (my) morning.

Regards,
Adam

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