The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2748

config file takes priority over external_nodes in 0.25.x

Added by Bart Verwilst over 4 years ago. Updated almost 4 years ago.

Status:DuplicateStart date:10/22/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Affected Puppet version:0.25.1 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

When using 0.24.8, we have a puppet.conf file for our clients that contained this amongst others ):

[main]

environment = production
environments = production, staging

This caused the default environment to be production, but we could force the staging environment by making the external_nodes output look like this:

parameters:

environment: staging

It would then execute everything from the staging tree, as expected.

Since we switched to 0.25, we noticed that this method no longer works. We always sync to production, no matter what is given in the external_nodes output. Apache logs say “GET /production/catalog/mail01.netnoc?facts=—…”, making it always fetch from production.

When changing puppet.conf on the client to read environment = staging, then it fetches “GET /staging/catalog/mail01.netnoc?facts=—…”, bringing in the right tree.

I guess i could make this work by changing the puppet.conf file to a template and have environment = <%= environment %> inthere, and making puppet restart itself when this file is changed ( we run puppet from a cron, not as a deamon ), but still it’s a nice piece of functionality that’s disappeared now :(


Related issues

Related to Puppet - Bug #2803: Issue with permissions with 0.25.1 -> 0.25.1 setup Duplicate 11/11/2009
Related to Puppet - Bug #3910: Server is not authoritative over client environment when ... Closed
Duplicates Puppet - Bug #2834: external node classifier should take client's idea of the... Closed 11/18/2009

History

#1 Updated by Bart Verwilst over 4 years ago

  • Subject changed from No more branches with 0.25.x to No more automatic environments with 0.25.x

#2 Updated by Markus Roberts over 4 years ago

  • Status changed from Unreviewed to Needs More Information

Is the real (or at least more fundamental) issue here that config file options are now taking precedent over external_node parameters, when in 0.24.x it was the other way around? Or am I misunderstanding the situation?

If this is the case, the next question would be: was that by design or an artifact of some other change?

#3 Updated by Bart Verwilst over 4 years ago

That’s correct, external_nodes used to override the config file, which is no longer the case in 0.25.. We’re relying on this to be the case so hopefully it’s just a bug :)

#4 Updated by Markus Roberts over 4 years ago

  • Status changed from Needs More Information to Needs Decision
  • Assignee set to Luke Kanies

So it’s a Luke question: was this by design or an accident?

#5 Updated by Markus Roberts over 4 years ago

  • Target version set to 0.25.1

I’m tentatively setting this to 0.25.1; if it was an accident Luke can accept & triage the bug, if it was by design reject the ticket as a bug and we can think about a workaround.

#6 Updated by Markus Roberts over 4 years ago

  • Subject changed from No more automatic environments with 0.25.x to config file takes priority over external_nodes in 0.25.x

#7 Updated by Luke Kanies over 4 years ago

  • Assignee deleted (Luke Kanies)

It’s a design decision, and I don’t see a way around it.

The client has to know its own environment from the first connection, because it retrieves files, and those files might be environment-specific (e.g., plugins). The only way to do this is to have the client own which environment its in.

If someone can see a way around this, I’m all for it, but I don’t see one.

#8 Updated by Markus Roberts over 4 years ago

Starting a discussion of potential workarounds on the dev list.

#9 Updated by James Turnbull over 4 years ago

  • Target version changed from 0.25.1 to 0.25.2

#10 Updated by Alan Barrett over 4 years ago

Luke Kanies wrote:

If someone can see a way around this, I’m all for it, but I don’t see one.

This issue is also biting me. Could you add a way for the client to ask the puppetmaster “I think my environment is FOO, what do you think my environment should be?” The client’s idea of its own environment should be one of the inputs to the node classifier script on the puppetmaster.

#11 Updated by Josh Endries over 4 years ago

  • Affected Puppet version changed from 0.25.1rc2 to 0.25.1

I think I just ran into this problem also. I didn’t have an environment set in my puppet.conf, I distribute a fact that sets the environment. I thought this set it on the client also, but apparently not? It pulled in “production” files instead of “testing” files, but the correct manifest was seemingly used. Explicitly settings the environment to “testing” in puppet.conf works, it causes the client to pull down the right files, so as a workaround I will distribute a puppet.conf template to my clients with the environment set. I’m a bit surprised the client doesn’t have access to (or realize) the facts that it sends to the master.

#12 Updated by Markus Roberts over 4 years ago

  • Assignee set to Markus Roberts

#13 Updated by Markus Roberts over 4 years ago

  • Status changed from Needs Decision to Accepted

After a long discussion on the dev list (http://groups.google.com/group/puppet-dev/browse_thread/thread/acc6f33e332cbfa0) the consensus seems to be Alan’s suggestion from #10 above—have the client provide it’s choice and allow the server to override it. This should be reasonably straight forward for most config settings except for the environment, which will require some attention to detail, as the client will make the initial request with respect to the environment which it believes it is in—and the server will have to be cognizant of this.

#14 Updated by Nigel Kersten over 4 years ago

I just had this bite me as well as I set the environment with a fact.

I swear this was working for us earlier in the 0.25.x rc/release process… or am I on crack?

This is pretty much a blocker for us to deploy 0.25.x clients with our 0.25.x servers. I take it we’re planning to fix this in 0.25.x and not rowlf?

#15 Updated by James Turnbull over 4 years ago

It’ll go into 0.25.2.

#16 Updated by Markus Roberts over 4 years ago

A partial attempt to implement the consensus solution uncovered several complications I hadn’t anticipated. The server and client need to agree on the environment before several things (authorization, custom fact code downloding, etc.)

Trying to do these in a single interaction gets rather messy, and may well not be doable at all.

After talking it over with Luke the revised plan is to move the environment negotiation to the very first step—the client should send it’s identity and what it thinks it’s environment is and the server returns it’s node information, excluding parameters (to prevent security leaks). The client would then cache this information to use as the default assumption in subsequent runs.

#17 Updated by Nigel Kersten over 4 years ago

Um isn’t that exactly what we had in 0.24.x ? and it was this that made load balancing difficult with environments?

#18 Updated by Markus Roberts over 4 years ago

You may note that I haven’t posted any brilliant code that closes this ticket in a way that makes everybody happy.

There’s a reason for that.

#19 Updated by Luke Kanies over 4 years ago

Nigel Kersten wrote:

Um isn’t that exactly what we had in 0.24.x ? and it was this that made load balancing difficult with environments?

How is that? Can you explain it further? I think this question/answer/cache thing is pretty different from 0.24.x, isn’t it? The client will still include its env in every request (including that first question) – the client caches the data, not the server.

#20 Updated by Nigel Kersten over 4 years ago

I obviously assumed incorrectly. I thought that with the problems with supplying all the facts in every request meant that this method was being abandoned in favour of an initial negotiation.

If the clients are still including their env in every request, then it’s not a problem.

#21 Updated by Luke Kanies over 4 years ago

Nigel Kersten wrote:

If the clients are still including their env in every request, then it’s not a problem.

That is indeed the case.

#22 Updated by Markus Roberts over 4 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee deleted (Markus Roberts)

I’m considering marking this a duplicate of #2834 (which is scheduled for Rolf), since that is what it’s becoming, due to the unavoidably invasive nature of all the implementations I’ve been able to devise.

#23 Updated by Markus Roberts over 4 years ago

  • Status changed from Needs Decision to Duplicate
  • Target version deleted (0.25.2)

Closing in favor of #2834 which has a clearer focus.

Also available in: Atom PDF