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

Feature #7497

Allow different database configurations per environment

Added by Nick Moffitt over 3 years ago. Updated 10 months ago.

Status:AcceptedStart date:05/12/2011
Priority:HighDue date:
Assignee:-% Done:

0%

Category:stored configuration
Target version:3.x
Affected Puppet version:2.6.4 Branch:
Keywords:

We've Moved!

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

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1377


Description

I have a database for stored configurations, and all my puppeteers (puppetmasters local to a network segment) have access to speak to that database. When I do my staging runs —noop, however, resources are exported that get collected by production runs.

This kind of pollution is extremely dangerous, as stored configurations are the only mechanism we currently have for nodes to communicate configuration status to other nodes. It is highly terrifying to see a front-end server start serving requests to a back-end server that only ever went through a —noop configuration run.

I tried putting a “dbname = staging” in my [staging] stanza, but it appears that I can’t have different environments speaking to different databases (even on the same server!). It would be extremely helpful if this were possible.

History

#1 Updated by Anonymous over 3 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Nigel Kersten

I think this is a bigger issue, actually: we probably also want to support different inventory services, and generally speaking, complete isolation of generated data by environment. Regardless, I think this specific issue deserves to be addressed.

Nigel, want to make a call on that, and when it flows into the schedule?

#2 Updated by Nigel Kersten over 3 years ago

I’m actually rather concerned we export resources on noop runs.

Nick, do you actually want them exported?

#3 Updated by Nigel Kersten over 3 years ago

  • Status changed from Needs Decision to Needs More Information
  • Priority changed from Normal to High

#4 Updated by Nick Moffitt over 3 years ago

Nigel Kersten wrote:

I’m actually rather concerned we export resources on noop runs.

Nick, do you actually want them exported?

I do, because I want to be able to watch the collections happen on the --noop runs as well. When I make a change in my staging manifests, I want to be able to do --noop -t on all machines and actually watch all dominoes fall. I need to be able to verify that resources would be correctly exported, essentially. I just want that to happen in a separate database (even one on the same server with the same user is fine with me right now!).

My staging --noop runs are a critical mechanism for reviewing diffs before pushing changes live. The closer I can get them to a separate but accurate mimicry of production, the better!

#5 Updated by Nigel Kersten over 3 years ago

We really do need to rename —noop to something more appropriate.

If I’m understanding this correctly, noop isn’t necessary for this feature request, it’s really just about allowing different storeconfigs settings per environment?

#6 Updated by Nick Moffitt over 3 years ago

Nigel Kersten wrote:

We really do need to rename —noop to something more appropriate.

This has me worried. Are you suggesting that I’m using it for something that is against its design, or simply that it doesn’t actually perform “no operations” as a CPU NOP instruction would?

If I’m understanding this correctly, noop isn’t necessary for this feature request, it’s really just about allowing different storeconfigs settings per environment?

That’s a fair assessment of the scope of this, yes.

#7 Updated by Nigel Kersten over 3 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from I would like separate dbnames for staging and production runs. to Allow different database configurations per environment
  • Status changed from Needs More Information to Accepted
  • Assignee deleted (Nigel Kersten)
  • Target version set to 3.x

Nick Moffitt wrote:

Nigel Kersten wrote:

We really do need to rename —noop to something more appropriate.

This has me worried. Are you suggesting that I’m using it for something that is against its design, or simply that it doesn’t actually perform “no operations” as a CPU NOP instruction would?

Totally the latter. It’s not accurate to describe it as “no operations”, as some operations do occur.

It’s much more a simulation of catalog application than it is “no operations”.

If I’m understanding this correctly, noop isn’t necessary for this feature request, it’s really just about allowing different storeconfigs settings per environment?

That’s a fair assessment of the scope of this, yes.

Excellent.

#8 Updated by Anonymous 10 months ago

Redmine Issue #7497 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1377

Also available in: Atom PDF