[Puppet-dev] Environment inconsistencies between evaluated classes and sourced files.

[Nigel Kersten]

Before I go so far as to report some bugs, I thought I'd throw this past people to see if my reasoning is correct. (rich formatted to aid in legibility).

This is a little verbose, but hopefully not too much. It's easy reading. :)

This is on 0.25.4, but scanning through the changelog didn't show anything that should affect this. I'll repeat this with 0.25.5 later.

3 environments defined, each with a single class "base".

/etc/puppet/puppet.conf

<...snip...>

[one]

  modulepath = /etc/puppet/environments/one/modules

[two]

  modulepath = /etc/puppet/environments/two/modules

[three]

  modulepath = /etc/puppet/environments/three/modules

/etc/puppet/environments/one/modules/base/manifests/init.pp

class base {

  notify { "hardwired one": }

  notify { "variable $environment": }

  file { "/tmp/environment_test":

source => "puppet:///base/tester",

  }

}

/etc/puppet/environments/two/modules/base/manifests/init.pp

class base {

  notify { "hardwired two": }

  notify { "variable $environment": }

  file { "/tmp/environment_test":

source => "puppet:///base/tester",

  }

}

/etc/puppet/environments/three/modules/base/manifests/init.pp

class base {

  notify { "hardwired three": }

  notify { "variable $environment": }

  file { "/tmp/environment_test":

source => "puppet:///base/tester",

  }

}

$ cat /etc/puppet/environments/{one,two,three}/modules/base/files/tester

one

two

three

Right? So we have two notify resources and a file resource.

• The "hardwired" notify is to illustrate which class is being loaded.
• The "variable" notify is to illustrate what $environment evaluates to in the manifests.
• The file source is to illustrate which file is being sourced.

I also have an external node classifier that always returns this:

---

classes:

 - base

environment: one

So our classifier always includes base, and always sets the environment.

I then invoke a puppet run on a client, specifying the environment to be *different* to the classifier.

Between all of these runs I delete cached client yaml info on the server. (find /var/puppet/yaml -type f -delete)

# puppetd -t --environment two 

notice: hardwired one

notice: //base/Notify[hardwired one]/message: defined 'message' as 'hardwired one'

notice: variable two

notice: //base/Notify[variable two]/message: defined 'message' as 'variable two'

notice: Finished catalog run in 0.18 seconds

# cat /tmp/environment_test

two

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

Now, to throw the big spanner in the works.... we try not specifying an environment at all.

# puppetd -t

notice: hardwired one

notice: //base/Notify[hardwired one]/message: defined 'message' as 'hardwired one'

notice: variable production

notice: //base/Notify[variable production]/message: defined 'message' as 'variable production'

err: //base/File[/tmp/environment_test]: Failed to retrieve current state of resource: Error 400 on SERVER: Not authorized to call find on /file_metadata/base/tester Could not retrieve file metadata for puppet:///base/tester: Error 400 on SERVER: Not authorized to call find on /file_metadata/base/tester at /etc/puppet/environments/one/modules/base/manifests/init.pp:6

notice: Finished catalog run in 0.08 seconds

As we don't have an environment "production" defined at all, the server tries to read the metadata from a non-existent environment and fails.

This really doesn't seem right to me.... am I missing something here?

I understand we have bugs around like the closed #2748 and the open #2834 but those don't seem to have caught this particular problem and they contain some incorrect info like:

"Whatever is defined in the external node database will be used instead of what was passed on the command line"

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

[Markus Roberts]

As of Puppet Camp SF, my reading of this was that we have a loop in our thinking, and that no matter what we do will seem "wrong" from some perspective.  No one seemed to agree with me, so I may well be incorrect, but I have yet to see how the nodes / facts / environments / modules loop can be sorted out so that everything depends on the right thing without having additional round trips between the client and the server.

Still, that's better than what we have, that seems wrong from several perspectives.  :)

Finally, for the most part, these issues are being addressed in master; we haven't been looking at making such changes in 0.25.x.

That said, I basically agree with you.

-- Markus

[Nigel Kersten]

On Fri, May 21, 2010 at 3:11 PM, Markus Roberts <mar...@puppetlabs.com> wrote:

As of Puppet Camp SF, my reading of this was that we have a loop in our thinking, and that no matter what we do will seem "wrong" from some perspective.  No one seemed to agree with me, so I may well be incorrect, but I have yet to see how the nodes / facts / environments / modules loop can be sorted out so that everything depends on the right thing without having additional round trips between the client and the server.

Still, that's better than what we have, that seems wrong from several perspectives.  :)

Finally, for the most part, these issues are being addressed in master; we haven't been looking at making such changes in 0.25.x.

That said, I basically agree with you.

Oh I'm not pretending this is simple :)  There are a whole raft of issues around determining who is authoritative for setting the environment, and I absolutely agree that I don't see a clear way forward without having several round trips.

I just feel like no matter what happens, classes and files should be coming from the same environment :)

 

-- Markus

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[eric.sorenson]

On May 21, 2010, at 02:48 PM, Nigel Kersten <nig...@google.com> wrote:

I also have an external node classifier that always returns this:

---

classes:

 - base

environment: one

So our classifier always includes base, and always sets the environment.

I then invoke a puppet run on a client, specifying the environment to be *different* to the classifier.

Between all of these runs I delete cached client yaml info on the server. (find /var/puppet/yaml -type f -delete)

# puppetd -t --environment two 

notice: hardwired one

notice: //base/Notify[hardwired one]/message: defined 'message' as 'hardwired one'

notice: variable two

notice: //base/Notify[variable two]/message: defined 'message' as 'variable two'

notice: Finished catalog run in 0.18 seconds

# cat /tmp/environment_test

two

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

Hi Nigel - a while back I found out quite by accident that yaml from external node classifier 

parameters:

  - environment: testing

set the puppetmaster environment to testing..maybe that's part of it? There seemed to me to be no namespace separation between the global variable '$environment' and the server's idea of which capital-E Environment a client ought to slot into.

-=Eric

[Nigel Kersten]

On Fri, May 21, 2010 at 4:44 PM, eric.sorenson <eric.s...@me.com> wrote:

On May 21, 2010, at 02:48 PM, Nigel Kersten <nig...@google.com> wrote:

I also have an external node classifier that always returns this:

---

classes:

 - base

environment: one

So our classifier always includes base, and always sets the environment.

I then invoke a puppet run on a client, specifying the environment to be *different* to the classifier.

Between all of these runs I delete cached client yaml info on the server. (find /var/puppet/yaml -type f -delete)

# puppetd -t --environment two 

notice: hardwired one

notice: //base/Notify[hardwired one]/message: defined 'message' as 'hardwired one'

notice: variable two

notice: //base/Notify[variable two]/message: defined 'message' as 'variable two'

notice: Finished catalog run in 0.18 seconds

# cat /tmp/environment_test

two

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

Hi Nigel - a while back I found out quite by accident that yaml from external node classifier 

parameters:

  - environment: testing

set the puppetmaster environment to testing..maybe that's part of it? There seemed to me to be no namespace separation between the global variable '$environment' and the server's idea of which capital-E Environment a client ought to slot into.

So if I do that as well, then:

err: //base/File[/tmp/environment_test]: Failed to retrieve current state of resource: Error 400 on SERVER: Not authorized to call find on /file_metadata/base/tester Could not retrieve file metadata for puppet:///base/tester: Error 400 on SERVER: Not authorized to call find on /file_metadata/base/tester at /etc/puppet/environments/one/modules/base/manifests/init.pp:6

notice: hardwired one

notice: //base/Notify[hardwired one]/message: defined 'message' as 'hardwired one'

notice: variable one

notice: //base/Notify[variable one]/message: defined 'message' as 'variable one'

notice: Finished catalog run in 0.11 seconds

 

So this "fixes" the $environment variable in manifests, but doesn't help the incorrect file source issue :(

--
nigel

[Nigel Kersten]

On Fri, May 21, 2010 at 3:11 PM, Markus Roberts <mar...@puppetlabs.com> wrote:

As of Puppet Camp SF, my reading of this was that we have a loop in our thinking, and that no matter what we do will seem "wrong" from some perspective.  No one seemed to agree with me, so I may well be incorrect, but I have yet to see how the nodes / facts / environments / modules loop can be sorted out so that everything depends on the right thing without having additional round trips between the client and the server.

Still, that's better than what we have, that seems wrong from several perspectives.  :)

Finally, for the most part, these issues are being addressed in master; we haven't been looking at making such changes in 0.25.x.

Can we get any insight into how the situation is in master ?

I'll do some testing, but I have no overall picture of how things are *intended* to work with environments in master.

 

That said, I basically agree with you.

-- Markus

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Luke Kanies]

On May 21, 2010, at 5:07 PM, Nigel Kersten wrote:

On Fri, May 21, 2010 at 3:11 PM, Markus Roberts <mar...@puppetlabs.com> wrote:

As of Puppet Camp SF, my reading of this was that we have a loop in our thinking, and that no matter what we do will seem "wrong" from some perspective.  No one seemed to agree with me, so I may well be incorrect, but I have yet to see how the nodes / facts / environments / modules loop can be sorted out so that everything depends on the right thing without having additional round trips between the client and the server.

Still, that's better than what we have, that seems wrong from several perspectives.  :)

Finally, for the most part, these issues are being addressed in master; we haven't been looking at making such changes in 0.25.x.

Can we get any insight into how the situation is in master ?

I'll do some testing, but I have no overall picture of how things are *intended* to work with environments in master.

The short answer is, "about to be fixed".

This is on my short list of things to fix in the next couple of days.

My plan at this point is to have the external node tool be the ultimate arbiter, then facts, then server environment.  If you want your external node tool to take the client's preferred environment into account, then you have to write a plugin that does this -- it's quite easy, though.

I guess we need to add one more bit that says $environment in the compile should always be set to the client's actual environment -- I don't think this happens right now (that is, it's always the fact value).

Are there any cases where this wouldn't work?

There's one potential weirdness in that the client uses the environment in the request and also passes it in the facts; they should always be the same, but it's still two sources of data.

-- 

The Roman Rule:
    The one who says it cannot be done should never interrupt the
    one who is doing it.

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

[Markus Roberts]

Can we get any insight into how the situation is in master ?

> I'll do some testing, but I have no overall picture of how things are *intended* to work with environments in master.

I think that's the best course; there have been a number of interrelated changes aimed at specific symptoms (and there are a few more in the queue).  Regardless of the specific intent of the individual patches, what we get is the combined effect of all of them working together, so that's what we ought to look at.

The generally intent is that all this should be sane / principle of least surprise in master.  But to see if it actually is (or will be, with the queued changes), testing the code is our only recourse.

The questions are roughly, 1) what does it do?  2) do we like that?  3) if not, was it intentional or an unintended consequence?  4) if intentional, what was the reasoning behind the decisions? 5) if unintentional, what went wrong and how should we fix it?

-- Markus
-----------------------------------------------------------
The power of accurate observation is
commonly called cynicism by those
who have not got it.  ~George Bernard Shaw
------------------------------------------------------------

[Luke Kanies]

On May 21, 2010, at 5:29 PM, Markus Roberts wrote:

>
> Can we get any insight into how the situation is in master ?
>
> > I'll do some testing, but I have no overall picture of how things
> are *intended* to work with environments in master.
>
> I think that's the best course; there have been a number of
> interrelated changes aimed at specific symptoms (and there are a few
> more in the queue). Regardless of the specific intent of the
> individual patches, what we get is the combined effect of all of
> them working together, so that's what we ought to look at.
>
> The generally intent is that all this should be sane / principle of
> least surprise in master. But to see if it actually is (or will be,
> with the queued changes), testing the code is our only recourse.
>
> The questions are roughly, 1) what does it do? 2) do we like that?
> 3) if not, was it intentional or an unintended consequence? 4) if
> intentional, what was the reasoning behind the decisions? 5) if
> unintentional, what went wrong and how should we fix it?

Urgh; I don't really care what it does right now.

Environments are about 100x more complicated than the original idea,
and I think we need to focus a lot more on the 'should' than the 'does'.

--
To be positive: To be mistaken at the top of one's voice.
-- Ambrose Bierce

---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199

[Nigel Kersten]

On Fri, May 21, 2010 at 5:25 PM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 5:07 PM, Nigel Kersten wrote:

On Fri, May 21, 2010 at 3:11 PM, Markus Roberts <mar...@puppetlabs.com> wrote:

As of Puppet Camp SF, my reading of this was that we have a loop in our thinking, and that no matter what we do will seem "wrong" from some perspective.  No one seemed to agree with me, so I may well be incorrect, but I have yet to see how the nodes / facts / environments / modules loop can be sorted out so that everything depends on the right thing without having additional round trips between the client and the server.

Still, that's better than what we have, that seems wrong from several perspectives.  :)

Finally, for the most part, these issues are being addressed in master; we haven't been looking at making such changes in 0.25.x.

Can we get any insight into how the situation is in master ?

I'll do some testing, but I have no overall picture of how things are *intended* to work with environments in master.

The short answer is, "about to be fixed".

This is on my short list of things to fix in the next couple of days.

My plan at this point is to have the external node tool be the ultimate arbiter, then facts, then server environment.  If you want your external node tool to take the client's preferred environment into account, then you have to write a plugin that does this -- it's quite easy, though.

I take it this would be done by examining the client fact cache on the server?

Does this mean we simply don't set the environment parameter in the config file? 

 

I guess we need to add one more bit that says $environment in the compile should always be set to the client's actual environment -- I don't think this happens right now (that is, it's always the fact value).

++

 

Are there any cases where this wouldn't work?

What if you don't have an external node tool?  Will the puppetmaster automatically set the environment to the value suggested by the client?

  

There's one potential weirdness in that the client uses the environment in the request and also passes it in the facts; they should always be the same, but it's still two sources of data.

I feel that if we're demoting the client environment setting to a "this is what I'd like my environment to be" then we simply shouldn't name that setting "environment".  Equally, I feel like we shouldn't allow a fact called "environment".

Perhaps "preferred_environment" ? "suggested" ? something to indicate that this is no longer authoritative?

This is perhaps out of scope for rowlf, but I really do feel that provisioning clients is more complicated with Puppet than it should be, and all of this is somewhat tangled up with that, but as Markus said earlier, is difficult to do without having a few round trips between the server and client.

[Nigel Kersten]

On Fri, May 21, 2010 at 5:33 PM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 5:29 PM, Markus Roberts wrote:

Can we get any insight into how the situation is in master ?

> I'll do some testing, but I have no overall picture of how things are *intended* to work with environments in master.

I think that's the best course; there have been a number of interrelated changes aimed at specific symptoms (and there are a few more in the queue).  Regardless of the specific intent of the individual patches, what we get is the combined effect of all of them working together, so that's what we ought to look at.

The generally intent is that all this should be sane / principle of least surprise in master.  But to see if it actually is (or will be, with the queued changes), testing the code is our only recourse.

The questions are roughly, 1) what does it do?  2) do we like that?  3) if not, was it intentional or an unintended consequence?  4) if intentional, what was the reasoning behind the decisions? 5) if unintentional, what went wrong and how should we fix it?

Urgh; I don't really care what it does right now.

Environments are about 100x more complicated than the original idea, and I think we need to focus a lot more on the 'should' than the 'does'.

The improvement of having plugins in modules in environments for 0.25.x was huge for me, but I concur that they've become a nasty tangled web.

I'd be perfectly happy to have to re-jig my entire environment setup for something conceptually simpler and more functional for the next major version, but maybe that's just me.

 

--
To be positive: To be mistaken at the top of one's voice.
   -- Ambrose Bierce

---------------------------------------------------------------------
Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Nigel Kersten]

Oh, and one extra thing.

I quite strongly feel we should drop the idea of a default environment in defaults.rb, especially one hard-wired to the name "production".

I assume this is part of the changes of making the external node classifier authoritative, but we really should be able to cope with the client not passing any information whatsoever to the server regarding a desired environment.

[Luke Kanies]

On May 21, 2010, at 6:17 PM, Nigel Kersten wrote:

> Oh, and one extra thing.
>
> I quite strongly feel we should drop the idea of a default
> environment in defaults.rb, especially one hard-wired to the name
> "production".
>
> I assume this is part of the changes of making the external node
> classifier authoritative, but we really should be able to cope with
> the client not passing any information whatsoever to the server
> regarding a desired environment.

Hmm. That's a bit tough, since every URI has the environment in it.

I'll think about this as I fly to London and Ghent; maybe we'll be
able to sprint on a solution at PuppetCamp.

--
If two men agree on everything, you may be sure that one of them is
doing the thinking. -- Lyndon B. Johnson

---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199

[Nigel Kersten]

On Sat, May 22, 2010 at 9:03 PM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 6:17 PM, Nigel Kersten wrote:

Oh, and one extra thing.

I quite strongly feel we should drop the idea of a default environment in defaults.rb, especially one hard-wired to the name "production".

I assume this is part of the changes of making the external node classifier authoritative, but we really should be able to cope with the client not passing any information whatsoever to the server regarding a desired environment.

Hmm.  That's a bit tough, since every URI has the environment in it.

I'll think about this as I fly to London and Ghent; maybe we'll be able to sprint on a solution at PuppetCamp.

How can we possibly make the server-side node classifier authoritative without this feature?  

 

--
If two men agree on everything, you may be sure that one of them is
doing the thinking. -- Lyndon B. Johnson

---------------------------------------------------------------------
Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Thomas Bellman]

On 2010-05-22 02:25, Luke Kanies wrote:

> My plan at this point is to have the external node tool be the ultimate
> arbiter, then facts, then server environment. If you want your external
> node tool to take the client's preferred environment into account, then
> you have to write a plugin that does this -- it's quite easy, though.

I would like to suggest a slight variation. I think it would be better
to move the responsibility of deciding what environment to use away from
the node classifier and into a separate script. That way it would be
possible to make external_nodes a per-environment setting, instead of
just a global setting as it is now.


/Bellman

[Ohad Levy]

On Tue, May 25, 2010 at 5:30 PM, Thomas Bellman <bel...@nsc.liu.se> wrote:

I would like to suggest a slight variation.  I think it would be better
to move the responsibility of deciding what environment to use away from
the node classifier and into a separate script.  That way it would be
possible to make external_nodes a per-environment setting, instead of
just a global setting as it is now.

I tend to disagree here, if you want your logic to be in external nodes, you probably want to be able to define the environment too.

afaik, you can already define the node in a simple nodes file, and not to return anything from your external nodes script, so the functioanility (if I got it right) you are asking, is already here.

Ohad

[Thomas Bellman]

On 2010-05-25 13:18, Ohad Levy wrote:

> On Tue, May 25, 2010 at 5:30 PM, Thomas Bellman <bel...@nsc.liu.se
> <mailto:bel...@nsc.liu.se>> wrote:
>
>
> I would like to suggest a slight variation. I think it would be better
> to move the responsibility of deciding what environment to use away from
> the node classifier and into a separate script. That way it would be
> possible to make external_nodes a per-environment setting, instead of
> just a global setting as it is now.
>
> I tend to disagree here, if you want your logic to be in external nodes,
> you probably want to be able to define the environment too.

But, you can't have *different* external nodes script for different
environments. That's what I think would be nice to have. Environments
are great for testing changes to your manifests, templates, files and
custom facts (as of 0.25), without risking your production machines.
But currently you can't test changes to custom functions, custom types,
or to your external nodes classifier that way. I think custom functions
and types are being solved for Rowlf.

> afaik, you can already define the node in a simple nodes file, and not
> to return anything from your external nodes script, so the
> functioanility (if I got it right) you are asking, is already here.

But then you are limited to the more static configuration of a normal
manifest file, and won't get the benefits of the dynamicity an external
node classifier can give you (if you need it).

What I suggest is to add a config parameter 'environment_classifier'
which points to a script whose *only* point is to tell puppetmasterd
what environment to use for a node. That parameter must by design
be global; it doesn't make sense for it to be per-environment. The
'external_nodes' parameter should be kept, but made per-environment,
and that script should then not have any say in which environment
gets chosen.

(Just a note: I don't use external nodes today, and I don't really
foresee any need to do so in the future either, but I can definitely
see the utility of it in some circumstances. If I ever get into
such circumstances, I would definitely want external_nodes to be
per-environment.)


/Bellman

[Nigel Kersten]

On Tue, May 25, 2010 at 5:18 AM, Thomas Bellman <bel...@nsc.liu.se> wrote:

On 2010-05-25 13:18, Ohad Levy wrote:

On Tue, May 25, 2010 at 5:30 PM, Thomas Bellman <bel...@nsc.liu.se

<mailto:bel...@nsc.liu.se>> wrote:


   I would like to suggest a slight variation.  I think it would be better
   to move the responsibility of deciding what environment to use away from
   the node classifier and into a separate script.  That way it would be
   possible to make external_nodes a per-environment setting, instead of
   just a global setting as it is now.

I tend to disagree here, if you want your logic to be in external nodes,
you probably want to be able to define the environment too.

But, you can't have *different* external nodes script for different
environments.

Sure you can. You make your master script call another different script per environment with the same arguments as it received..

--
nigel

[Thomas Bellman]

On 2010-05-25 15:32, Nigel Kersten wrote:

> On Tue, May 25, 2010 at 5:18 AM, Thomas Bellman <bel...@nsc.liu.se
> <mailto:bel...@nsc.liu.se>> wrote:
>
> But, you can't have *different* external nodes script for different
> environments.
>
> Sure you can. You make your master script call another different script
> per environment with the same arguments as it received..

Well, yes, there are of course ways to work around many of the limitations
of Puppet. Like we can use exec resources, and inline_template() calls
for a lot of things. But that doesn't make it right...

[Nigel Kersten]

On Tue, May 25, 2010 at 9:06 AM, Thomas Bellman <bel...@nsc.liu.se> wrote:

On 2010-05-25 15:32, Nigel Kersten wrote:

On Tue, May 25, 2010 at 5:18 AM, Thomas Bellman <bel...@nsc.liu.se

<mailto:bel...@nsc.liu.se>> wrote:

   But, you can't have *different* external nodes script for different
   environments.

Sure you can. You make your master script call another different script
per environment with the same arguments as it received..

Well, yes, there are of course ways to work around many of the limitations
of Puppet.  Like we can use exec resources, and inline_template() calls
for a lot of things.  But that doesn't make it right...

So here's my problem with this idea.

If the external node classifier is to be *authoritative* for specifying the client environment, how does it make sense to have a different classifier per environment?

What does having a separate classifier per environment give us exactly?

 

       /Bellman

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Luke Kanies]

On May 23, 2010, at 5:02 PM, Nigel Kersten wrote:

On Sat, May 22, 2010 at 9:03 PM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 6:17 PM, Nigel Kersten wrote:

Oh, and one extra thing.

I quite strongly feel we should drop the idea of a default environment in defaults.rb, especially one hard-wired to the name "production".

I assume this is part of the changes of making the external node classifier authoritative, but we really should be able to cope with the client not passing any information whatsoever to the server regarding a desired environment.

Hmm.  That's a bit tough, since every URI has the environment in it.

I'll think about this as I fly to London and Ghent; maybe we'll be able to sprint on a solution at PuppetCamp.

How can we possibly make the server-side node classifier authoritative without this feature?

The client just needs to have a means of semi-permanently overriding the default, I think.

It's obviously a challenge, but it's one we have to solve some way or another.

-- 

We must believe in luck. For how else can we explain the success of
those we don't like? -- Jean Cocteau

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

[Luke Kanies]

On May 21, 2010, at 10:48 PM, Nigel Kersten wrote:

Before I go so far as to report some bugs, I thought I'd throw this past people to see if my reasoning is correct. (rich formatted to aid in legibility).

This is a little verbose, but hopefully not too much. It's easy reading. :)

This is on 0.25.4, but scanning through the changelog didn't show anything that should affect this. I'll repeat this with 0.25.5 later.

[...]

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

[...]

This really doesn't seem right to me.... am I missing something here?

I understand we have bugs around like the closed #2748 and the open #2834 but those don't seem to have caught this particular problem and they contain some incorrect info like:

"Whatever is defined in the external node database will be used instead of what was passed on the command line"

Looking at this more closely, you're right - this is a larger problem.

I think the main fix we need to make is that the server needs to be able to change the client's environment in a semi-permanent way.  IMO, this should be done through something like (and my proposal is) an environment file, which should just contain the name of an environment.  So /etc/puppet/environment would set the client's environment, and if the client received a catalog back that specified a different environment, it would write that file with the new environment's name.

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

I think that connection is less important, as long as any env info the client gets from the server is permanent.

Would that do most/all of the necessary work?

-- 

A lot of people mistake a short memory for a clear conscience.
    -- Doug Larson

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

[Luke Kanies]

On May 25, 2010, at 5:39 PM, Nigel Kersten wrote:

On Tue, May 25, 2010 at 9:06 AM, Thomas Bellman <bel...@nsc.liu.se> wrote:

On 2010-05-25 15:32, Nigel Kersten wrote:

On Tue, May 25, 2010 at 5:18 AM, Thomas Bellman <bel...@nsc.liu.se

<mailto:bel...@nsc.liu.se>> wrote:

   But, you can't have *different* external nodes script for different
   environments.

Sure you can. You make your master script call another different script
per environment with the same arguments as it received..

Well, yes, there are of course ways to work around many of the limitations
of Puppet.  Like we can use exec resources, and inline_template() calls
for a lot of things.  But that doesn't make it right...

So here's my problem with this idea.

If the external node classifier is to be *authoritative* for specifying the client environment, how does it make sense to have a different classifier per environment?

What does having a separate classifier per environment give us exactly?

I agree with this - it's a rare enough request that building your own per-environment pass-through classifier is a better approach here.

-- 

If I want your opinion, I'll read your entrails.
    --Doug Shewfelt

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

[Nigel Kersten]

On Tue, May 25, 2010 at 9:19 AM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 10:48 PM, Nigel Kersten wrote:

Before I go so far as to report some bugs, I thought I'd throw this past people to see if my reasoning is correct. (rich formatted to aid in legibility).

This is a little verbose, but hopefully not too much. It's easy reading. :)

This is on 0.25.4, but scanning through the changelog didn't show anything that should affect this. I'll repeat this with 0.25.5 later.

[...]

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

[...]

This really doesn't seem right to me.... am I missing something here?

I understand we have bugs around like the closed #2748 and the open #2834 but those don't seem to have caught this particular problem and they contain some incorrect info like:

"Whatever is defined in the external node database will be used instead of what was passed on the command line"

Looking at this more closely, you're right - this is a larger problem.

I think the main fix we need to make is that the server needs to be able to change the client's environment in a semi-permanent way.  IMO, this should be done through something like (and my proposal is) an environment file, which should just contain the name of an environment.  So /etc/puppet/environment would set the client's environment, and if the client received a catalog back that specified a different environment, it would write that file with the new environment's name.

Does this give us anything more than we have now with shipping puppet.conf as an erb template?

 

I'm not quite sure what the benefits would be of having this info stored in another config file compared to our existing one? Is the move to a unified binary changing the config file situation at all?

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

++ This would be brilliant and is pretty much what I want.

What would make it perfect would be if any existing client facts were available to the server at this same point in order for the server to make an educated decision regarding the environment, and in a more transparent manner than examining the server side fact cache for that client.

I think that connection is less important, as long as any env info the client gets from the server is permanent.

Would that do most/all of the necessary work?

-- 

A lot of people mistake a short memory for a clear conscience.
    -- Doug Larson

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Markus Roberts]

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

++ This would be brilliant and is pretty much what I want.

What would make it perfect would be if any existing client facts were available to the server at this same point in order for the server to make an educated decision regarding the environment, and in a more transparent manner than examining the server side fact cache for that client.

By "existing client facts" I assume you mean "as shipped / default facts" as opposed to "user written facts," as the later are per environment?  And re-asking a question I had a few months back, can anyone give me a use case for the node tool using facts to determine the environment?

-- Markus

[Nigel Kersten]

On Wed, May 26, 2010 at 6:40 AM, Markus Roberts <mar...@puppetlabs.com> wrote:

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

++ This would be brilliant and is pretty much what I want.

What would make it perfect would be if any existing client facts were available to the server at this same point in order for the server to make an educated decision regarding the environment, and in a more transparent manner than examining the server side fact cache for that client.

By "existing client facts" I assume you mean "as shipped / default facts" as opposed to "user written facts," as the later are per environment? 

No, I just mean whatever the client has on the system at that point. This gives people various options for bootstrapping.

 

And re-asking a question I had a few months back, can anyone give me a use case for the node tool using facts to determine the environment?

What other info would you use to determine it?

Some of us have too many clients/too much flux to individually assign environments to them, so we need to carve them up into broad chunks based on facts.

1) Rule based phased releases.

Use environments for release tracks.

When you have a new release, you write rules to evenly distribute the phasing in of the release based upon fact values, ie to evenly spread the canaries across hardware types, geographic locations, etc etc etc.

The external node classifier looks at the facts and determines whether this particular client should operate as a canary for the course of this release.

2) Self-organizing environments.

Facts like "hardware_type" etc to distinguish between laptops/desktops/servers., major_os_release, to be used as components in an environment.

[Luke Kanies]

Just to be clear - it's straightforward to build and use a plugin that sends client facts to the node tool and allows it to use them to make decisions about the environment.

I don't think Puppet will ever have direct support for doing this in the lookup itself.  I could, however, see Puppet supporting easy write-access for facts, so they're automattically written where you want when the client uploads them.

-- 

Sent from mobile device | +1-615-594-8199

[Nigel Kersten]

Note, finally reported as http://projects.puppetlabs.com/issues/3910

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel

[Luke Kanies]

On May 25, 2010, at 11:54 AM, Nigel Kersten wrote:

On Tue, May 25, 2010 at 9:19 AM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 10:48 PM, Nigel Kersten wrote:

Before I go so far as to report some bugs, I thought I'd throw this past people to see if my reasoning is correct. (rich formatted to aid in legibility).

This is a little verbose, but hopefully not too much. It's easy reading. :)

This is on 0.25.4, but scanning through the changelog didn't show anything that should affect this. I'll repeat this with 0.25.5 later.

[...]

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

[...]

This really doesn't seem right to me.... am I missing something here?

I understand we have bugs around like the closed #2748 and the open #2834 but those don't seem to have caught this particular problem and they contain some incorrect info like:

"Whatever is defined in the external node database will be used instead of what was passed on the command line"

Looking at this more closely, you're right - this is a larger problem.

I think the main fix we need to make is that the server needs to be able to change the client's environment in a semi-permanent way.  IMO, this should be done through something like (and my proposal is) an environment file, which should just contain the name of an environment.  So /etc/puppet/environment would set the client's environment, and if the client received a catalog back that specified a different environment, it would write that file with the new environment's name.

Does this give us anything more than we have now with shipping puppet.conf as an erb template?

If you ship puppet.conf, it takes at least one run to take affect; this skips that extra run.

I'm not quite sure what the benefits would be of having this info stored in another config file compared to our existing one? Is the move to a unified binary changing the config file situation at all?

The unified executable doesn't really affect this at all.

The reason I like it to be in a different file is that the assumption would be that Puppet maintains this file rather than the user (i.e., it would generally be written to by Puppet rather than read from), which is not at all the case with puppet.conf.

It's also something external tools could come to rely on.

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

++ This would be brilliant and is pretty much what I want.

What would make it perfect would be if any existing client facts were available to the server at this same point in order for the server to make an educated decision regarding the environment, and in a more transparent manner than examining the server side fact cache for that client.

Don't want much, do you? :/

Given this request, my tendency for now is to skip the extra step and rely on whatever env info comes back from the catalog.  We're already sending the facts along with that request, so it's not extra work.

-- 

One of the Ten Commandments for Technicians:
    (7) Work thou not on energized equipment, for if thou dost, thy
    fellow workers will surely buy beers for thy widow and
    console her in other ways.

[Nigel Kersten]

On Mon, May 31, 2010 at 2:22 PM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 25, 2010, at 11:54 AM, Nigel Kersten wrote:

On Tue, May 25, 2010 at 9:19 AM, Luke Kanies <lu...@puppetlabs.com> wrote:

On May 21, 2010, at 10:48 PM, Nigel Kersten wrote:

Before I go so far as to report some bugs, I thought I'd throw this past people to see if my reasoning is correct. (rich formatted to aid in legibility).

This is a little verbose, but hopefully not too much. It's easy reading. :)

This is on 0.25.4, but scanning through the changelog didn't show anything that should affect this. I'll repeat this with 0.25.5 later.

[...]

So we have the class being evaluated in environment "one", but the file being sourced coming from environment "two" ! And less importantly, $environment evaluates to "two".

[...]

This really doesn't seem right to me.... am I missing something here?

I understand we have bugs around like the closed #2748 and the open #2834 but those don't seem to have caught this particular problem and they contain some incorrect info like:

"Whatever is defined in the external node database will be used instead of what was passed on the command line"

Looking at this more closely, you're right - this is a larger problem.

I think the main fix we need to make is that the server needs to be able to change the client's environment in a semi-permanent way.  IMO, this should be done through something like (and my proposal is) an environment file, which should just contain the name of an environment.  So /etc/puppet/environment would set the client's environment, and if the client received a catalog back that specified a different environment, it would write that file with the new environment's name.

Does this give us anything more than we have now with shipping puppet.conf as an erb template?

If you ship puppet.conf, it takes at least one run to take affect; this skips that extra run.

Ok. It wasn't clear this was designed to happen within the one run.

 

I'm not quite sure what the benefits would be of having this info stored in another config file compared to our existing one? Is the move to a unified binary changing the config file situation at all?

The unified executable doesn't really affect this at all.

The reason I like it to be in a different file is that the assumption would be that Puppet maintains this file rather than the user (i.e., it would generally be written to by Puppet rather than read from), which is not at all the case with puppet.conf.

It's also something external tools could come to rely on.

Should it go into the statedir then in that case? That would make it even clearer that it's internal puppet data.

 

Given that, the client default environment would be hard coded as something like 'production' -- so if the file is missing we still know what to use on the very first connection -- and we write the file out as soon as we get something back from the server.

We could optionally add a connection to the server, where the client just asks the server for its own node information and uses that to set its environment.  Maybe it does this iff the environment file is missing?

++ This would be brilliant and is pretty much what I want.

What would make it perfect would be if any existing client facts were available to the server at this same point in order for the server to make an educated decision regarding the environment, and in a more transparent manner than examining the server side fact cache for that client.

Don't want much, do you? :/

Given this request, my tendency for now is to skip the extra step and rely on whatever env info comes back from the catalog.  We're already sending the facts along with that request, so it's not extra work.

sounds good!

 

-- 

One of the Ten Commandments for Technicians:
    (7) Work thou not on energized equipment, for if thou dost, thy
    fellow workers will surely buy beers for thy widow and
    console her in other ways.

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

--
nigel