Setting environments in 0.25
Markus Roberts
In 0.24.x, the environment specified in the client's configuration file could be overridden by the server using the external_nodes information.
In 0.25.x, all requests from the client contain the environment as part of the url, which means the environment needs to be established before the first request so this trick no longer works.
I've heard a number of ideas for dealing with this and would be interested in hearing others, and/or arguments for or against the ones already on the table. Ideas so far:
* Sites that need this functionality can set up a starting environment for nodes that only pushes the configuration file, and the configuration file can be a template filled in with the appropriate external_node parameters. This will require an extra cycle for new nodes and for existing nodes when their environment changes at such sites, but would not require any code changes or have any impact on sites that don't need it.
* Change puppet to request the node information from the server before anything else (e.g. before plugins). This would have a small overhead for all puppet runs and necessitate a moderately small code change.
* Change the default environment on the client to a special "ask the server" environment. Clients that specified an environment in their configuration or on the command line would use that environment. Clients that did not specify an environment would request it from the server, imposing a small overhead only for machines that needed it. This would require a somewhat larger code change.
So what is the sense of the community?
R.I.Pienaar
----- "Markus Roberts" <mar...@reductivelabs.com> wrote:
> * Sites that need this functionality can set up a starting environment
> for nodes that only pushes the configuration file, and the
> configuration file can be a template filled in with the appropriate
> external_node parameters. This will require an extra cycle for new
> nodes and for existing nodes when their environment changes at such
> sites, but would not require any code changes or have any impact on
> sites that don't need it.
I'd say this should be the last resort, I've seen several places that changes a machines environment fairly often, during maintenance periods for example.
Forcing the environment change to only happen after another run would be very bad for them.
> * Change puppet to request the node information from the server before
> anything else (e.g. before plugins). This would have a small overhead
> for all puppet runs and necessitate a moderately small code change.
nice.
> * Change the default environment on the client to a special "ask the
> server" environment. Clients that specified an environment in their
> configuration or on the command line would use that environment.
> Clients that did not specify an environment would request it from the
> server, imposing a small overhead only for machines that needed it.
> This would require a somewhat larger code change.
Even nicer. I assume we can then specify on the server the default environment that all unconfigured nodes would end up in? This would be very nice indeed.
Keeping in mind that it is also very desirable to be able to set the environment via a fact.
--
R.I.Pienaar
Luke Kanies
Yes. The "somewhat larger" code change part, though, is both more
code and decent bit more complexity - having values vary based on
client vs. server is annoyingly complicated.
> Keeping in mind that it is also very desirable to be able to set the
> environment via a fact.
Hmm. Using facts complicates things even further, because it's
another way for the client to specify the environment. Why do you
want to be able to do that?
The next question becomes, do we need to do this for 0.25.1? I would
tend to say no, we ship 0.25.1 nowish (because it's ready), and only
do this for either a 0.25.2 if we produce one, or rowlf.
--
I worry that the person who thought up Muzak may be thinking up
something else. -- Lily Tomlin
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
R.I.Pienaar
But it isn't really different behavior from what we had in 0.24.x so I think there's an expectation. I can see how it's a pain code wise though.
>
> > Keeping in mind that it is also very desirable to be able to set the
> > environment via a fact.
>
> Hmm. Using facts complicates things even further, because it's
> another way for the client to specify the environment. Why do you
> want to be able to do that?
machines know where they are and in what environment they are, it seems a logical extension. I've never seen this documented as something that should work, but always been glad it does :)
I think Nigel use this method extensively as well, and it does work with 0.25.1rc2
> The next question becomes, do we need to do this for 0.25.1? I would
> tend to say no, we ship 0.25.1 nowish (because it's ready), and only
> do this for either a 0.25.2 if we produce one, or rowlf.
I think 0.25.1 should get out there quick as we can really, and if we go for the above there'll be a lot of code changes, not the kind of thing to do at rc2 stage imho.
--
R.I.Pienaar
Nigel Kersten
Setting it via a fact allows users to switch their machine from the
"stable" environment to the "testing" or "unstable" environments. We
allow users to set this value on the machine as either a debconf value
or a plist key.
We asked for this feature quite a way back, around 0.22.x I think? I'd
hate to see this go away....
>
> I think Nigel use this method extensively as well, and it does work with 0.25.1rc2
>
>> The next question becomes, do we need to do this for 0.25.1? I would
>> tend to say no, we ship 0.25.1 nowish (because it's ready), and only
>> do this for either a 0.25.2 if we produce one, or rowlf.
>
> I think 0.25.1 should get out there quick as we can really, and if we go for the above there'll be a lot of code changes, not the kind of thing to do at rc2 stage imho.
>
>
> --
> R.I.Pienaar
>
> >
>
nigel
Markus Roberts
-- Markus
Nigel Kersten
that provides "environment"
Facter.add("environment") do
setcode do
"foobar"
end
end
>
> -- Markus
>
>
> >
>
--
nigel
Paul Lathrop
<mar...@reductivelabs.com> wrote:
> We have a ticket open (#2748) over a change in behaviour between 0.24.x and
> 0.25.x.
>
> In 0.24.x, the environment specified in the client's configuration file
> could be overridden by the server using the external_nodes information.
>
> In 0.25.x, all requests from the client contain the environment as part of
> the url, which means the environment needs to be established before the
> first request so this trick no longer works.
The server *absolutely* needs to be able to "force" an environment on
the client. While I understand the use case for the other way around,
we treat the master as our source of truth and while we allow clients
to "suggest" things, we need to be able to over-ride that.
> I've heard a number of ideas for dealing with this and would be interested
> in hearing others, and/or arguments for or against the ones already on the
> table. Ideas so far:
>
> * Sites that need this functionality can set up a starting environment for
> nodes that only pushes the configuration file, and the configuration file
> can be a template filled in with the appropriate external_node parameters.
> This will require an extra cycle for new nodes and for existing nodes when
> their environment changes at such sites, but would not require any code
> changes or have any impact on sites that don't need it.
This kinda sucks.
> * Change puppet to request the node information from the server before
> anything else (e.g. before plugins). This would have a small overhead for
> all puppet runs and necessitate a moderately small code change.
This seems like a reasonable compromise.
> * Change the default environment on the client to a special "ask the server"
> environment. Clients that specified an environment in their configuration
> or on the command line would use that environment. Clients that did not
> specify an environment would request it from the server, imposing a small
> overhead only for machines that needed it. This would require a somewhat
> larger code change.
This seems the optimal solution, but I am not volunteering to write
the code, so I'd understand it not happening soonish.
> So what is the sense of the community?
This shouldn't hold up 0.25.1. I think it is worthwhile to support
both use cases i.e. client can request a certain environment, and
server can optionally force the client into another environment.
--Paul
Luke Kanies
I'ts more of a pain data-flow-wise than code, I think. In talking it
over with Markus today it became clear how, um, unclear the whole "who
owns the environment" thing really is.
0.24 was relatively straightforward in this area if you only did
simple things, but it was complicated enough that if you did anything
weird than I think it quickly turned into craziness.
>>> Keeping in mind that it is also very desirable to be able to set the
>>> environment via a fact.
>>
>> Hmm. Using facts complicates things even further, because it's
>> another way for the client to specify the environment. Why do you
>> want to be able to do that?
>
> machines know where they are and in what environment they are, it
> seems a logical extension. I've never seen this documented as
> something that should work, but always been glad it does :)
>
> I think Nigel use this method extensively as well, and it does work
> with 0.25.1rc2
Who should win between facts and external nodes?
>> The next question becomes, do we need to do this for 0.25.1? I would
>> tend to say no, we ship 0.25.1 nowish (because it's ready), and only
>> do this for either a 0.25.2 if we produce one, or rowlf.
>
> I think 0.25.1 should get out there quick as we can really, and if
> we go for the above there'll be a lot of code changes, not the kind
> of thing to do at rc2 stage imho.
Ok.
--
Always behave like a duck - keep calm and unruffled on the surface but
paddle like the devil underneath. -- Jacob Braude
Luke Kanies
Seems like we have a reasonable agreement: This shouldn't hold up
0.25.1, and we'll probably take the easy way out once that's released
-- add the 'collect env at beginning' step, and if it gets to be
painful, we can optimize it away later.
--
The brain is a wonderful organ. It starts working the moment you get
up in the morning and does not stop until you get into the office.
--Robert Frost
R.I.Pienaar
How was it in 0.24? I think the most sane priority order is:
- external nodes
- facts
- config file
--
R.I.Pienaar
Ohad Levy
How was it in 0.24? I think the most sane priority order is:
- external nodes
- facts
- config file
Nigel Kersten
So this all seems related to this bug of mine:
http://projects.reductivelabs.com/issues/2322
and I had the same impression Luke had in that bug, that we can't
currently tell whether a given config setting was arrived at via a
fact, a config file, or a default value?
That being said, I agree with the priority list above.
--
nigel
Luke Kanies
How would the command line work relative to external nodes?
1) command line
2) external nodes
3) facts
4) config file
5) server-side default
?
This is, um, heinous and hideous. Do we really need that much
flexibility in how people use environments? Is there some way we can
rethink the problem a bit and come up with something cleaner?
--
Venter's First Law:
Discoveries made in a field by some one from another discipline
will
always be upsetting to the majority of those inside.
Peter Meier
as Paul outlined, we might want to force environments, as clients
shouldn't be able to switch into a different environment and we don't
have any possiblility to restrict access to environment.
So I think it should rather be this way:
1) external nodes
2) command line
3) facts
4) config file
5) server-side default
or
1) external nodes
2) facts
3) command line
4) config file
5) server-side default
hmmm, this will mean the only way a server can force an environment is
via external nodes. Maybe sufficient, maybe we should think about a way
to disable environment selection by clients.
cheers pete
R.I.Pienaar
> How would the command line work relative to external nodes?
>
> 1) command line
> 2) external nodes
> 3) facts
> 4) config file
> 5) server-side default
>
> ?
>
> This is, um, heinous and hideous. Do we really need that much
> flexibility in how people use environments? Is there some way we can
I currently use environments like this spread over various clients:
- command line, yes cos there's no other way to do 'do this stuff first' than with an environment, or developers want to just test something on a box and add --environment to the command line, very helpful, I sometimes also just do export FACTER_environment=foo first
- external nodes, we all know why
- facts, very useful, I have machines determining their environment based on their ip address
- config file, i dont really use it except to put my nodes in my bootstrap node at kickstart time - see cli usage
- server-side default I'd consider this a nice to have, because i wouldnt bother with the config file for my bootstrapping I'd just put everything that isnt otherwise configured into a server controlled default
> rethink the problem a bit and come up with something cleaner?
so towards this, I listed my use cases for all of the above, maybe it will help someone think of a less insane solution :)
--
R.I.Pienaar
Markus Roberts
That gets rid of the whole issue of what-trumps-what, or at least sidelines it; we may still want some sources (e.g. the command line) to take precedence but we don't have to sort a long list of sources based on a whole slew of use cases.
* Does that sound reasonable?
* Where should the one-true-place be?
* Is the command line (for interactive use) the only thing that should best it?
* Are there any use cases that this wouldn't handle?
-- Markus
R.I.Pienaar
----- "Markus Roberts" <mar...@reductivelabs.com> wrote:
sounds plausible but abstract, can you show some kind of potential use case or something so we can have an idea of what you're thinking?
--
R.I.Pienaar
Markus Roberts
*laugh* It was intentionally abstract, because I wanted to know what _you_ were thinking. But since you asked, here are two concrete strawman examples:
1. The environment comes from the client's conf file, unless overridden by the command line. Normally, this is a literal string value, but it could be one of several special values such as "!!FACT[fact name]" or "!!NODE_TOOL" or some such. If one of these is used the appropriate action is taken to resolve the host name.
2. The environment is always determined by facter. Facter has the ability to get the information from various places, such as the client config, the node manager (by templating the fact or some other such ruse), and so forth.
Pretty much any of the sources could be used in this way, though the dynamics of how things would play out--and the complexity of implementing it--would vary considerably. I'm not proposing any of them specifically, just exploring ways we could trim the growing list of places the environment could come from (there are presently six on the table by my count).
-- Markus
R.I.Pienaar
----- "Markus Roberts" <mar...@reductivelabs.com> wrote:
ok, i can dig that
> 2. The environment is always determined by facter. Facter has the
> ability to get the information from various places, such as the client
> config, the node manager (by templating the fact or some other such
> ruse), and so forth.
not a fan of this, not cos its bad, but because the barrier to entry is huge - people need to learn a whole lot of rather arcane stuff about facts and pluginsync and ruby and so forth and so on to unlock environments
--
R.I.Pienaar
Luke Kanies
IMO, that's not really a great idea, because you then have to have
quite a bit of ugly code that knows how to interpret that token, and
you've really just punted + invented a new templating system.
Given the current state of affairs in Puppet:
We know that external nodes needs to be able to set it, which means we
need the client to be able to query its environment from the server.
That's a chunk of work we can be sure we'll have to do.
We also know that the client needs to be able override values, both
permanently and temporarily, which, at the least, means it needs to be
tunable whether we pull that env info from the server.
My first question is, is there a design flaw somewhere else that's
forcing either of these requirements?
For instance, I know Volcane has mentioned that the reason he
overrides environments on clients is because it's the only way he can
force ordering. Maybe to fix the environment mess we have to fix this
problem? Are there other reasons people override the environment on
the client?
Nigel, I know you want this client-side override; what do you use it
for?
I think that, organizationally, it makes a lot more sense for the
central location to own which environment a given host is in. I'd
like to see us provide the functionality necessary to completely
remote the need for client-side overrides, but I'm not yet convinced
that's possible.
--
You wake me up early in the morning to tell me I am right? Please
wait until I am wrong. -- Johann von Neumann
Markus Roberts
ok, i can dig that> overridden by the command line. Normally, this is a literal string
> value, but it could be one of several special values such as
> "!!FACT[fact name]" or "!!NODE_TOOL" or some such. If one of these is
> used the appropriate action is taken to resolve the host name.
It's definitely better than the facter version, but not without flaws. One interesting aspect is that the client could resolve any that it understood locally and just any others literally, giving the client the opportunity to resolve them client side.
What about the other permutations? E.g., environment is always determined by the server unless it's given a special "let the client decide" value--problematic for client side command-line override but nice in some other regards.
-- Markus
Markus Roberts
> overrides environments on clients is because it's the only way he
> can force ordering.
-- Markus
Luke Kanies
More like "I know X has to be done before my main configuration works,
so I put X in a special 'setup' environment and run it once".
I.e., exactly what I desperately want to avoid and am embarrassed is
necessary. I think fixing this is probably the real goal here.
--
You've got to take the bitter with the sour.
-- Samuel Goldwyn
Markus Roberts
Nigel Kersten
able to centrally define this.
We have environments like:
hardy_desktop_{unstable, testing, stable}
hardy_laptop_{unstable, testing, stable}
mac_laptop_{unstable, testing, stable}
and we follow the unstable -> testing -> stable release process. We
need individual machines to be able to flip between
unstable/testing/stable versions of their environment without having
to centrally define them.
If the server was capable of setting the client environment based upon
a composite of other fact values, then that would essentially give me
the same functionality and I wouldn't have a need for this anymore,
but I'm unsure how the chicken/egg problem would get resolved.
Currently we work around the problem of initial distribution of the
fact by running the clients with a --factsync and a tag that is pretty
much a noop, so the client gets facts from the default location, then
the environment fact is available on the "real" puppet run that
happens next.
This is on 0.24.x of course. I haven't yet worked out how I'll deal
with this with 0.25 clients when I turn off factsync and move all of
this to plugins in modules.
Does that make things clearer?
>
> I think that, organizationally, it makes a lot more sense for the
> central location to own which environment a given host is in. I'd
> like to see us provide the functionality necessary to completely
> remote the need for client-side overrides, but I'm not yet convinced
> that's possible.
>
> --
> You wake me up early in the morning to tell me I am right? Please
> wait until I am wrong. -- Johann von Neumann
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
nigel
R.I.Pienaar
----- "Luke Kanies" <lu...@madstop.com> wrote:
> On Oct 27, 2009, at 4:37 PM, Markus Roberts wrote:
>
> > > For instance, I know Volcane has mentioned that the reason he
> > > overrides environments on clients is because it's the only way he
> > > can force ordering.
> >
> > As in having proto-environments that you sequentially pass through
> > on the way to the final environment (no skipping stages!) or am I
> > missing the point here?
>
> More like "I know X has to be done before my main configuration works,
> so I put X in a special 'setup' environment and run it once".
> I.e., exactly what I desperately want to avoid and am embarrassed is
> necessary. I think fixing this is probably the real goal here.
We've often discussed 'anchor' classes on the graph.
So there might be a class beforehook and afterhook that if nothing gets done simply ends up before and after all classes.
But if I now do:
file{"/foo":
require => Class["afterhook"]
}
or
file{"/foo":
before => Class["beforehook"]
}
I would basically ensure these things happen first or last, and if i had 10 things to happen first - configure yum, create repos, make cache - I'd just make them all happen before beforehook.
I'd hate to imagine the hell of coding this behavior though
--
R.I.Pienaar
Luke Kanies
into testing temporarily, and then when it works move it back into
stable, do you have a pool of machines that slowly migrate to stable,
or what? I can see how you'd want to change it sometimes, but with
the above arrows, I see two transitions at most, since they're one-way.
> If the server was capable of setting the client environment based upon
> a composite of other fact values, then that would essentially give me
> the same functionality and I wouldn't have a need for this anymore,
> but I'm unsure how the chicken/egg problem would get resolved.
> Currently we work around the problem of initial distribution of the
> fact by running the clients with a --factsync and a tag that is pretty
> much a noop, so the client gets facts from the default location, then
> the environment fact is available on the "real" puppet run that
> happens next.
>
> This is on 0.24.x of course. I haven't yet worked out how I'll deal
> with this with 0.25 clients when I turn off factsync and move all of
> this to plugins in modules.
>
> Does that make things clearer?
>> I think that, organizationally, it makes a lot more sense for the
>> central location to own which environment a given host is in. I'd
>> like to see us provide the functionality necessary to completely
>> remote the need for client-side overrides, but I'm not yet convinced
>> that's possible.
>>
>> --
>> You wake me up early in the morning to tell me I am right? Please
>> wait until I am wrong. -- Johann von Neumann
>> ---------------------------------------------------------------------
>> Luke Kanies | http://reductivelabs.com | http://madstop.com
>>
>>
>>>
>>
>
>
>
> --
> nigel
>
> >
Basic research is what I am doing when I don't know what I am doing.
--Wernher von Braun
Luke Kanies
My guess is that someone well-versed in graphs could knock this out
pretty quickly, but that someone isn't me. :/
Solving this just got bumped up pretty heavily on my priority list, so
you should probably expect a solution in rowlf. I've just no idea wtf
it'll be. :)
--
Normal is getting dressed in clothes that you buy for work and driving
through traffic in a car that you are still paying for - in order to
get to the job you need to pay for the clothes and the car, and the
house you leave vacant all day so you can afford to live in it.
-- Ellen DeGeneres
Nigel Kersten
The people responsible for a given platform will live on the relevant
unstable environment.
The people responsible for first/second level support of a platform
will generally live on the relevant testing environment.
The rest of the fleet generally lives on stable.
Other teams may have one of their group of servers live on a testing
environment, whereas the rest live in a stable environment.
>
>> If the server was capable of setting the client environment based upon
>> a composite of other fact values, then that would essentially give me
>> the same functionality and I wouldn't have a need for this anymore,
>> but I'm unsure how the chicken/egg problem would get resolved.
>
> Can you explain this more?
facts distributed as plugins in environments... you have an issue with
bootstrapping and getting the fact onto the client in the first place.
The same would hold for any other facts that were used to compose an
environment.
>
>> Currently we work around the problem of initial distribution of the
>> fact by running the clients with a --factsync and a tag that is pretty
>> much a noop, so the client gets facts from the default location, then
>> the environment fact is available on the "real" puppet run that
>> happens next.
>>
>> This is on 0.24.x of course. I haven't yet worked out how I'll deal
>> with this with 0.25 clients when I turn off factsync and move all of
>> this to plugins in modules.
>>
>> Does that make things clearer?
>
> Nope. :)
>
>>> I think that, organizationally, it makes a lot more sense for the
>>> central location to own which environment a given host is in. I'd
>>> like to see us provide the functionality necessary to completely
>>> remote the need for client-side overrides, but I'm not yet convinced
>>> that's possible.
>>>
>>> --
>>> You wake me up early in the morning to tell me I am right? Please
>>> wait until I am wrong. -- Johann von Neumann
>>> ---------------------------------------------------------------------
>>> Luke Kanies | http://reductivelabs.com | http://madstop.com
>>>
>>>
>>>>
>>>
>>
>>
>>
>> --
>> nigel
>>
>> >
>
>
> --
> Basic research is what I am doing when I don't know what I am doing.
> --Wernher von Braun
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
nigel
Luke Kanies
But how/why do hosts flip between environments? That's the part I
don't understand. How is it dynamic?
>>> If the server was capable of setting the client environment based
>>> upon
>>> a composite of other fact values, then that would essentially give
>>> me
>>> the same functionality and I wouldn't have a need for this anymore,
>>> but I'm unsure how the chicken/egg problem would get resolved.
>>
>> Can you explain this more?
>
> Well if the environment is determined by a fact, and you have all your
> facts distributed as plugins in environments... you have an issue with
> bootstrapping and getting the fact onto the client in the first place.
> The same would hold for any other facts that were used to compose an
> environment.
That I see. If you're just downloading facts from the server to set
the environment, though, how is that fundamentally different from the
server owning what environment the client belongs to? Are your facts
just simple strings, or are they making complicated calculations based
on something on the client?
Someone just proposed a good solution on the ticket: Telling the
server what the client thinks its environment should be, and giving
the server the ability to override it either way. So the server is
always authoritative, but it can choose to let the client decide.
That seems like the best overall approach, but it still leaves
unsolved the overall complexity.
--
While one person hesitates because he feels inferior, the other is
busy making mistakes and becoming superior. -- Henry C. Link
Nigel Kersten
debconf datastore or a property list.
> Are your facts
> just simple strings, or are they making complicated calculations based
> on something on the client?
It works out whether it's a Mac, Linux or Solaris box.
It works out whether it's a desktop, laptop or server
It works out whether the owner of the machine has decided to configure
this machine to use unstable or testing.
>
> Someone just proposed a good solution on the ticket: Telling the
> server what the client thinks its environment should be, and giving
> the server the ability to override it either way. So the server is
> always authoritative, but it can choose to let the client decide.
> That seems like the best overall approach, but it still leaves
> unsolved the overall complexity.
>
> --
> While one person hesitates because he feels inferior, the other is
> busy making mistakes and becoming superior. -- Henry C. Link
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
nigel
Luke Kanies
[...]
>> That I see. If you're just downloading facts from the server to set
>> the environment, though, how is that fundamentally different from the
>> server owning what environment the client belongs to?
>
> The facts look at local configuration on the client such as the
> debconf datastore or a property list.
>
>> Are your facts
>> just simple strings, or are they making complicated calculations
>> based
>> on something on the client?
>
> It's not particularly complicated.
>
> It works out whether it's a Mac, Linux or Solaris box.
> It works out whether it's a desktop, laptop or server
> It works out whether the owner of the machine has decided to configure
> this machine to use unstable or testing.
So you've got different environments for different platforms, then?
Did you do that for scaling reasons, or just because the code for them
is that different, or what?
There's definitely some critical concept missing here...
--
Football is a mistake. It combines the two worst elements of American
life. Violence and committee meetings. -- George F. Will
Nigel Kersten
>
> On Oct 28, 2009, at 11:31 AM, Nigel Kersten wrote:
> [...]
>>> That I see. If you're just downloading facts from the server to set
>>> the environment, though, how is that fundamentally different from the
>>> server owning what environment the client belongs to?
>>
>> The facts look at local configuration on the client such as the
>> debconf datastore or a property list.
>>
>>> Are your facts
>>> just simple strings, or are they making complicated calculations
>>> based
>>> on something on the client?
>>
>> It's not particularly complicated.
>>
>> It works out whether it's a Mac, Linux or Solaris box.
>> It works out whether it's a desktop, laptop or server
>> It works out whether the owner of the machine has decided to configure
>> this machine to use unstable or testing.
>
>
> So you've got different environments for different platforms, then?
> Did you do that for scaling reasons, or just because the code for them
> is that different, or what?
and follow their own schedule.
We all commit to a common development "environment" that is only used
for the most close to the metal development testing.
Then each team chooses to integrate from the common development
environment to their own unstable environment on their own schedule.
They then control the integration from unstable->testing and
testing->stable.
We only commit to the common dev environment.
>
> There's definitely some critical concept missing here...
phone or do it in IRC if we need more of a back and forth conversation
about this.
>
> --
> Football is a mistake. It combines the two worst elements of American
> life. Violence and committee meetings. -- George F. Will
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
nigel
Ian Ward Comfort
> Someone just proposed a good solution on the ticket: Telling the
> server what the client thinks its environment should be, and giving
> the server the ability to override it either way. So the server is
> always authoritative, but it can choose to let the client decide.
> That seems like the best overall approach, but it still leaves
> unsolved the overall complexity.
I'll second (or third) this suggestion -- it's exactly how I use
environments in 0.24.8 today.
--
Ian Ward Comfort <icom...@rescomp.stanford.edu>
Systems Team Lead, Student Computing, Stanford University
Luke Kanies
That all seems great. I just don't get where it changes on a given
host.
>> There's definitely some critical concept missing here...
>
> was that it ? :) I'm a bit flat out today, but happy to jump on a
> phone or do it in IRC if we need more of a back and forth conversation
> about this.
A call might be helpful. Ping me on IRC?
--
Humphrey's Law of the Efficacy of Prayer:
In a dangerous world there will always be more people around whose
prayers for their own safety have been answered than those whose
prayers have not.
Nigel Kersten
determined by local configuration files on the client. debconf for
linux, plists for Mac.
>
>>> There's definitely some critical concept missing here...
>>
>> was that it ? :) I'm a bit flat out today, but happy to jump on a
>> phone or do it in IRC if we need more of a back and forth conversation
>> about this.
>
> A call might be helpful. Ping me on IRC?
>
> --
> Humphrey's Law of the Efficacy of Prayer:
> In a dangerous world there will always be more people around whose
> prayers for their own safety have been answered than those whose
> prayers have not.
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
nigel
Luke Kanies
Sorry - what I mean is, does the environment for a given host need to
change frequently from one value to another? E.g., do hosts pop in
and out of testing?
--
I can win an argument on any topic, against any opponent. People know
this, and steer clear of me at parties. Often, as a sign of their
great respect, they don't even invite me. -- Dave Barry
Ohad Levy
Sorry - what I mean is, does the environment for a given host need to
change frequently from one value to another? E.g., do hosts pop in
and out of testing?
the reason for that is that some changes in dev are reverted, but if they were configuring a machine in prod mode, that change might still be there (unless you start writing anti classes which is a whole different discussion).
In the context of testing, I would argue that its a wrong way to test, as you never test the same conditions (unless you reset - reinstall).
Ohad
Thomas Bellman
> On Thu, Oct 29, 2009 at 8:17 AM, Luke Kanies <lu...@madstop.com
> <mailto:lu...@madstop.com>> wrote:
>
> Sorry - what I mean is, does the environment for a given host need to
> change frequently from one value to another? E.g., do hosts pop in
> and out of testing?
>
> I'm not sure how other people are handing it, but when we follow
> dev-->test-->production cycles, you can only go from right to left,
> anything else usually mean re installation.
On the other hand, the way we do it at my workplace, is that we have
one environment "production", which machines normally use. When we
want to change something, we use a separate testing environment where
we edit the manifests, and run 'puppetd --onetime --environment=test'.
If the changes work correctly, we do 'git commit' and 'git push', and
then 'git pull' in production. The normal Puppet run some time later
(we only run every 4th hour, not every 30 minutes) will of course run
from the production environment.
If our edits break things, we have to revert. Depending on how the
things broke, we may either just rely on doing 'puppetd --onetime
--environment=production', or we may need to do manual revert of
what happened.
Depending on how invasive our changes are, we may also try them on
one or several more machines (machines with different roles) before
pushing to production.
Occasionally, we may move a machine to the test environment for a
a day or a few days before we are satisfied with our changes and
push them to production. We then of course have to manually remember
to move the machine back to the production environment.
And we actually don't have just one test environment; each sysadmin
has their own, and sometimes I have several so I can develop multiple
new features in parallel.
We don't have the luxury of having spare machines for testing out
changes, so we have to do much of it on live systems. And it seems
that in practice we don't break things often and hard enough to
warrant having spare testing systems.
So, for us a machine may change its environment many times a day,
back and forth between production and one of several testing
environments. We rely heavily on being able to specify the
environment using --environment.
/Bellman
Luke Kanies
This is a different enough use of environments that it almost
qualifies for a different term. Markus has been talking of this as a
branch - you're basically branching a given environment, making some
changes, testing on a few nodes, and when you're happy with the
configuration you're merging the branch.
Interesting usage, and we certainly need some means of supporting that
ability.
--
Meeting, n.:
An assembly of people coming together to decide what person or
department not represented in the room must solve a problem.