raise_unless


#1

I want cookbooks that mandate that something else set certain attributes as
part of their contract.

I’ve been toying with a ‘raise_unless’ defined in node.rb for these
attributes.

Does anyone else have concerns or opinions about this?


#2

Someone told me I didn’t explain what I was asking well enough, so here is
an attempt to do that.

I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.

I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.

I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and 0.9
that make it different between versions, but it’s pretty straight forward.

I’m interested if other people see any use for this and if so, is there a
better semantic or mechanism to accomplish it.

On Thu, Jul 15, 2010 at 8:15 AM, Andrew Shafer andrew@cloudscaling.comwrote:

I want cookbooks that mandate that something else set certain attributes as
part of their contract.

I’ve been toying with a ‘raise_unless’ defined in node.rb for these
attributes.

Does anyone else have concerns or opinions about this?


#3

On Fri, Jul 16, 2010 at 6:37 AM, Andrew Shafer andrew@cloudscaling.com wrote:

I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.

+1

When cookbooks depend on each other, theres some situations where its
best to share certain attributes between the cookbooks. So having
raise_unless (or an equivalent) seems like a good idea.

dreamcat4
dreamcat4@gmail.com


#4

I agree

right now I am relying on documentation and process to deal with this.

On Jul 16, 2010, at 12:03 AM, Dreamcat4 wrote:

On Fri, Jul 16, 2010 at 6:37 AM, Andrew Shafer andrew@cloudscaling.com wrote:

I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.

+1

When cookbooks depend on each other, theres some situations where its
best to share certain attributes between the cookbooks. So having
raise_unless (or an equivalent) seems like a good idea.

dreamcat4
dreamcat4@gmail.com


#5

+1, ticket. Etc.

On 16 Jul 2010 19:27, “Jesse Nelson” spheromak@gmail.com wrote:

I agree

right now I am relying on documentation and process to deal with this.

On Jul 16, 2010, at 12:03 AM, Dreamcat4 wrote:

On Fri, Jul 16, 2010 at 6:37 AM, Andrew Shafer andrew@cloudscaling.com
wrote:

I have some configurations where there is not really a sensible default
and

I want to ensure the cookbook parameters are pushed down from another
cookbook or role.

+1

When cookbooks depend on each other, theres some situations where its
best to share certain attributes between the cookbooks. So having
raise_unless (or an equivalent) seems like a good idea.

dreamcat4
dreamcat4@gmail.com


#6

I’d love to see this.

On Fri, Jul 16, 2010 at 08:50, AJ Christensen aj@junglist.gen.nz wrote:

+1, ticket. Etc.

On 16 Jul 2010 19:27, “Jesse Nelson” spheromak@gmail.com wrote:

I agree

right now I am relying on documentation and process to deal with this.

On Jul 16, 2010, at 12:03 AM, Dreamcat4 wrote:

On Fri, Jul 16, 2010 at 6:37 AM, Andrew Shafer andrew@cloudscaling.com
wrote:

I have some configurations where there is not really a sensible default
and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.

+1

When cookbooks depend on each other, theres some situations where its
best to share certain attributes between the cookbooks. So having
raise_unless (or an equivalent) seems like a good idea.

dreamcat4
dreamcat4@gmail.com


#7

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer andrew@cloudscaling.com wrote:

Someone told me I didn’t explain what I was asking well enough, so here is
an attempt to do that.
I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and 0.9
that make it different between versions, but it’s pretty straight forward.
I’m interested if other people see any use for this and if so, is there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


#8

Good points.

raise_unless (or whatever it should be called… assert, ensure, your_mom,
whatever…) should probably go in the recipe itself, and then just don’t
set it in the attributes for that cookbook.

On Fri, Jul 16, 2010 at 9:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer andrew@cloudscaling.com
wrote:

Someone told me I didn’t explain what I was asking well enough, so here
is
an attempt to do that.
I have some configurations where there is not really a sensible default
and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and 0.9
that make it different between versions, but it’s pretty straight
forward.
I’m interested if other people see any use for this and if so, is there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


#9

Yo,

On 17 July 2010 03:36, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer andrew@cloudscaling.com
wrote:

Someone told me I didn’t explain what I was asking well enough, so here
is
an attempt to do that.

[snip]

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.

This sounds like it solves a commonly overlooked problem in sharing
cookbooks with other users; especially (sharing with) those not familiar
enough around Ruby or Chef to understand some advanced recipe constructs or
usage.

Simply being able to request that particular dataz are available on the node
by way of assertion seems to largely reduce any confusion that might occur.
Even works for solo.

I can dig the shit outta this

Regards,

AJ


#10

Actually, you can do:

include_attribute “foo”

To ensure it gets loaded first.

+1 for raise_unless

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer andrew@cloudscaling.com wrote:

Someone told me I didn’t explain what I was asking well enough, so here is
an attempt to do that.
I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and 0.9
that make it different between versions, but it’s pretty straight forward.
I’m interested if other people see any use for this and if so, is there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


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


#11

On Fri, Jul 16, 2010 at 4:27 PM, Adam Jacob adam@opscode.com wrote:

Actually, you can do:

include_attribute “foo”

To ensure it gets loaded first.

+1 for raise_unless

I considered this, but I don’t think it’s sufficient for the problem
at hand. Every decent-sized chef deployment I’ve ever looked at uses
roles to denormalize the majority of explicitly-set attributes. Role
attributes aren’t applied to the node until after attribute files are
read, so if you have this in an attribute file:
raise_unless(attribute_foo)
And this in a role:
default_attributes(:attribute_foo => “bar”)
The attribute file would always raise when evaluated, even though chef
would have set that attribute soon afterward. You could still put your
raise_unless statement in a recipe as node.raise_unless though.
But maybe this is enough to cover the use case? If it was a resource,
I’m imagining something like

fail_if("This host does not have  a domain name set.") do
  assert { node[:domain] }
end

It would probably be necessary to run this immediately (or at least
have an option to do so).

I’m +1 on the idea in either case, though I think an implementation
that encourages use from within recipes is favorable to one that does
not.

Dan DeLeo

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer andrew@cloudscaling.com wrote:

Someone told me I didn’t explain what I was asking well enough, so here is
an attempt to do that.
I have some configurations where there is not really a sensible default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and 0.9
that make it different between versions, but it’s pretty straight forward.
I’m interested if other people see any use for this and if so, is there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


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


#12

+1 for raise_unless (or similar) in an attributes file

If you think of the attributes file as the ‘API’ of the recipe then I would
prefer to have something in the attributes file so it is a full
specification of all required attributes. How this specification is then
used to assert that all required attributes are set is a matter of
implementation. The error raising should probably be part of evaluation the
recipe.

Regards,
K-J

On Mon, Jul 19, 2010 at 6:49 PM, Daniel DeLeo dan@kallistec.com wrote:

On Fri, Jul 16, 2010 at 4:27 PM, Adam Jacob adam@opscode.com wrote:

Actually, you can do:

include_attribute “foo”

To ensure it gets loaded first.

+1 for raise_unless

I considered this, but I don’t think it’s sufficient for the problem
at hand. Every decent-sized chef deployment I’ve ever looked at uses
roles to denormalize the majority of explicitly-set attributes. Role
attributes aren’t applied to the node until after attribute files are
read, so if you have this in an attribute file:
raise_unless(attribute_foo)
And this in a role:
default_attributes(:attribute_foo => “bar”)
The attribute file would always raise when evaluated, even though chef
would have set that attribute soon afterward. You could still put your
raise_unless statement in a recipe as node.raise_unless though.
But maybe this is enough to cover the use case? If it was a resource,
I’m imagining something like

fail_if(“This host does not have a domain name set.”) do
assert { node[:domain] }
end

It would probably be necessary to run this immediately (or at least
have an option to do so).

I’m +1 on the idea in either case, though I think an implementation
that encourages use from within recipes is favorable to one that does
not.

Dan DeLeo

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer <
andrew@cloudscaling.com> wrote:

Someone told me I didn’t explain what I was asking well enough, so here
is

an attempt to do that.
I have some configurations where there is not really a sensible default
and

I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not
set.

I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and
0.9

that make it different between versions, but it’s pretty straight
forward.

I’m interested if other people see any use for this and if so, is there
a

better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


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


Groeten,

Klaas Jan
k.j.wierenga@gmail.com


#13

Hi,
Its also worthwhile to address Daniel’s point about the role
attributes. Perhaps that represents a more general architectural
inconsistency between the sources for configuration attributes.

Lets see…
In most cases an attribute dependency in the other recipe should
usually be filled in with a default value. Wheras a role value could
be different, and override that with any other arbitrary value.

Perhaps the role configuration can (in some cases) can require the
defaults to be cleared, emptied, nil’d. Typically for an "either-or"
scenario whereby you have to choose one or the other backend, eg “it
requires either MYSQL or POSTGRES, but not both”.

It then would require (to catch that inconsistency) in the recipe file
with a raise_unless for the zero’d attribute(s). But in all other
cases it wont as there should be a default attribute. That is either
overrided to a role value (or left to the default).

Am I right?

On the other side we have someone like K-J here who dutifully looks
through the attributes.rb files to decide what to set his role values
should be when creating a new role definition. K-J would see the
raise_unless statements in there more easily, and be sure set up those
dependant attributes up (in the other CBs) also.

If raise_unless were allways only in the recipe files, K-J would feel
uneasy, or somehow more obliged to have to carefully trawl through all
the whole recipes to get that same information.

OTOH (again), if K-J just didnt bother trawling through and gave it a
run, would not quickly find the Chef::Exception saying “hey you didnt
set this value in the other recipe”, if the other recipe had set a
default to the value for that particular require’d attribute.

So K-J (presumably a chef attributes junkie that he is) wouldn’t
really be aware of that extra configuration attribute he could
possible set differently and tailored to his role.

So to summarize:

One way is best for guaranteeing that the role attrubite value is set
(but not caring if it was overriden from the default?). That is
Daniels put it in the recipe way.

The other way is best choice for showing that some attribute in a
dependant recipe is “taken in” or inherited, and being shared between
both recipes as a first-class attribute. So thats when raise_unless is
in the attributes.rb file. You can really see its a part of the
cookbook you are looking at, even though the attribute belongs from a
different cookbook.

Maybe thats a subtly different kind of a problem and the raise_unless
idiom is not the best way to represent these shared attributes?

On Sat, Aug 7, 2010 at 12:13 PM, Klaas Jan Wierenga
k.j.wierenga@gmail.com wrote:

+1 for raise_unless (or similar) in an attributes file

If you think of the attributes file as the ‘API’ of the recipe then I would
prefer to have something in the attributes file so it is a full
specification of all required attributes. How this specification is then
used to assert that all required attributes are set is a matter of
implementation. The error raising should probably be part of evaluation the
recipe.

Regards,
K-J

On Mon, Jul 19, 2010 at 6:49 PM, Daniel DeLeo dan@kallistec.com wrote:

On Fri, Jul 16, 2010 at 4:27 PM, Adam Jacob adam@opscode.com wrote:

Actually, you can do:

include_attribute “foo”

To ensure it gets loaded first.

+1 for raise_unless

I considered this, but I don’t think it’s sufficient for the problem
at hand. Every decent-sized chef deployment I’ve ever looked at uses
roles to denormalize the majority of explicitly-set attributes. Role
attributes aren’t applied to the node until after attribute files are
read, so if you have this in an attribute file:
raise_unless(attribute_foo)
And this in a role:
default_attributes(:attribute_foo => “bar”)
The attribute file would always raise when evaluated, even though chef
would have set that attribute soon afterward. You could still put your
raise_unless statement in a recipe as node.raise_unless though.
But maybe this is enough to cover the use case? If it was a resource,
I’m imagining something like

fail_if(“This host does not have a domain name set.”) do
assert { node[:domain] }
end

It would probably be necessary to run this immediately (or at least
have an option to do so).

I’m +1 on the idea in either case, though I think an implementation
that encourages use from within recipes is favorable to one that does
not.

Dan DeLeo

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer
andrew@cloudscaling.com wrote:

Someone told me I didn’t explain what I was asking well enough, so
here is
an attempt to do that.
I have some configurations where there is not really a sensible
default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not
set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and
0.9
that make it different between versions, but it’s pretty straight
forward.
I’m interested if other people see any use for this and if so, is
there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


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


Groeten,

Klaas Jan
k.j.wierenga@gmail.com


#14

On Sat, Aug 7, 2010 at 6:24 PM, Dreamcat4 dreamcat4@gmail.com wrote:

Hi,
Its also worthwhile to address Daniel’s point about the role
attributes. Perhaps that represents a more general architectural
inconsistency between the sources for configuration attributes.

Sorry I didnt mean to say theres any deficiency.

Lets see again…

The other way is best choice for showing that some attribute in a
dependant recipe is “taken in” or inherited, and being shared between
both recipes as a first-class attribute. So thats when raise_unless is
in the attributes.rb file. You can really see its a part of the
cookbook you are looking at, even though the attribute belongs from a
different cookbook.

Maybe thats a subtly different kind of a problem and the raise_unless
idiom is not the best way to represent these shared attributes?

It makes sense to reserve have raise_unless() function in the
recipe.rb files like Daniel says. But we could also accompany that
with a more broader and flexible addition to the attribute syntax in
the attribute.rb file.

For example:

attributes.rb:
include_attribute(OtherCookbook::OtherAttribute)

Would show that this cookbook uses / pinches / steals some attribute
from another cookbook and what that specifically is. Then its more
useful because it can espress optional attributes too.

So for example there might be plenty of cases where an optional
extension or module/plugin can interact with another program. Eg
mod_php for apache. Then that attributes from php cookbook can
optionally be set. Its quite useful.

Not just for the raise_unless, but also for any parts of a recipe
which might have

recipe.rb:
if (other_cookbook_attribute)

install optional plugin

end

and so wouldnt necessarily need this raise_unless checking in all
instances of this usage. This is more expressive and flexible, I think
for J-K and different enough not to be a duplication of efforts and
aim at solving the 2 distinct different kinds of problems.

Of course if you actually used raise_unless() in your recipe file you
might also want to have a matching includes_attribute() line in the
attributes.rb. But thats just common sense and not necessarily a
duplication of things.

On Sat, Aug 7, 2010 at 12:13 PM, Klaas Jan Wierenga
k.j.wierenga@gmail.com wrote:

+1 for raise_unless (or similar) in an attributes file

If you think of the attributes file as the ‘API’ of the recipe then I would
prefer to have something in the attributes file so it is a full
specification of all required attributes. How this specification is then
used to assert that all required attributes are set is a matter of
implementation. The error raising should probably be part of evaluation the
recipe.

Regards,
K-J

On Mon, Jul 19, 2010 at 6:49 PM, Daniel DeLeo dan@kallistec.com wrote:

On Fri, Jul 16, 2010 at 4:27 PM, Adam Jacob adam@opscode.com wrote:

Actually, you can do:

include_attribute “foo”

To ensure it gets loaded first.

+1 for raise_unless

I considered this, but I don’t think it’s sufficient for the problem
at hand. Every decent-sized chef deployment I’ve ever looked at uses
roles to denormalize the majority of explicitly-set attributes. Role
attributes aren’t applied to the node until after attribute files are
read, so if you have this in an attribute file:
raise_unless(attribute_foo)
And this in a role:
default_attributes(:attribute_foo => “bar”)
The attribute file would always raise when evaluated, even though chef
would have set that attribute soon afterward. You could still put your
raise_unless statement in a recipe as node.raise_unless though.
But maybe this is enough to cover the use case? If it was a resource,
I’m imagining something like

fail_if(“This host does not have a domain name set.”) do
assert { node[:domain] }
end

It would probably be necessary to run this immediately (or at least
have an option to do so).

I’m +1 on the idea in either case, though I think an implementation
that encourages use from within recipes is favorable to one that does
not.

Dan DeLeo

Adam

On Fri, Jul 16, 2010 at 8:36 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thu, Jul 15, 2010 at 10:37 PM, Andrew Shafer
andrew@cloudscaling.com wrote:

Someone told me I didn’t explain what I was asking well enough, so
here is
an attempt to do that.
I have some configurations where there is not really a sensible
default and
I want to ensure the cookbook parameters are pushed down from another
cookbook or role.
I want the opposite behavior of set_unless[:foo][:bar], I want
raise_unless[:foo][:bar] to stop the run if node[:foo][:bar] is not
set.
I monkey patched Chef::Node to make raise_unless work. There is some
differences in the way node interacts with attributes between 0.8 and
0.9
that make it different between versions, but it’s pretty straight
forward.
I’m interested if other people see any use for this and if so, is
there a
better semantic or mechanism to accomplish it.

If you use this in an attributes file, it’s tricky since Chef doesn’t
guarantee the attribute files are loaded in any order (except when
using include_attribute, which only ensures one attribute file will be
loaded before the other). Also, it seems fair that you would set this
critical attribute in a role, in which case it would not be set until
after the attribute files were read.

So in my view, you’d want to put this in a recipe file, and if you put
it there, it might make sense to use a more general “assert” method
and define it on Chef::Recipe or even make it a LWRP. Then you could
make assertions about the system state outside of Chef if you needed
to. On the other hand, maybe I’m architecture astronaut-ing.

I like the idea though, many times new users have not set their FQDN
before running the bootstrap and then been confused by the “attribute
domain is not defined” error. It would be much nicer to see that the
attribute is not defined and abort with a message about setting the
domain name.


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


Groeten,

Klaas Jan
k.j.wierenga@gmail.com