>>> So for now our status means trying to do this in the language without
>>> an actual change to Puppet is becoming hard. This is entirely
>>> possible, but we'll have to ship with environment support without
>>> constraint capability today most probably.
>>>
>>> The only other 'quick and dirty' o
>> So for now our status means trying to do this in the language without
>> an actual change to Puppet is becoming hard. This is entirely
>> possible, but we'll have to ship with environment support without
>> constraint capability today most probably.
>>
>> The only other 'quick and dirty' option
On 2014-11-04 17:59, Ken Barber wrote:
So for now our status means trying to do this in the language without
an actual change to Puppet is becoming hard. This is entirely
possible, but we'll have to ship with environment support without
constraint capability today most probably.
The only other '
So for now our status means trying to do this in the language without
an actual change to Puppet is becoming hard. This is entirely
possible, but we'll have to ship with environment support without
constraint capability today most probably.
The only other 'quick and dirty' option I can think of is
> The 3x/current parser is very picky what it allows in the query. The only
> chance of doing someting special, is to reserve some particular expressions
> that would otherwise be interpreted as a regular query - i.e. checking
> equality on a virtual parameter name or something like that. This is b
On 2014-10-04 23:19, Ken Barber wrote:
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $::environment |>>#
dalen's suggestion
Nah, that goes down the path of using different syntax and even terminals in
queri
>> Hmm. Lots of things are possible, just need to avoid collision with
>> the parameter naming.
>>
>> Myresource <<| .environment == $::environment |>>#
>> dalen's suggestion
>
>
> Nah, that goes down the path of using different syntax and even terminals in
> queries.
>
>
>> Myresource
On Mon, Apr 7, 2014 at 8:04 AM, Ken Barber wrote:
> Hmm. Lots of things are possible, just need to avoid collision with
> the parameter naming.
>
> Myresource <<| .environment == $$::environment |>>#
> dalen's suggestion
> Myresource <<| _environment == $$::environment |>> #
On 2014-07-04 17:04, Ken Barber wrote:
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $$::environment |>>#
dalen's suggestion
Nah, that goes down the path of using different syntax and even
terminals in quer
I like this one:
Myresource <<| Environment == $$::environment |>> # ye old
capitalization like other parts of puppet
It's easy to read and makes me think "a think that's defined somewhere
else".
Trevor
On Mon, Apr 7, 2014 at 11:04 AM, Ken Barber wrote:
> Hmm. Lots of things are
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $$::environment |>>#
dalen's suggestion
Myresource <<| _environment == $$::environment |>> #
alternate to dalen's suggestion
Myresource <<| catalog.environ
I always found it surprising and slightly confusing that exec has an
'environment' attribute, I expected that to be a metaparam that could be
applied to any resource to indicate what environment it should belong to
(defaulting to the current one). Would get freaky as you could then export
resou
On 2 April 2014 16:40, Ken Barber wrote:
> > I quite like the idea of allowing people to restrict collection based
> > on environment. That requires a slight tweak to the puppetdb terminus
> > code, but I don't think it'll be too bad. Erik is correct, though,
> > that we can't really use "environ
> I quite like the idea of allowing people to restrict collection based
> on environment. That requires a slight tweak to the puppetdb terminus
> code, but I don't think it'll be too bad. Erik is correct, though,
> that we can't really use "environment" as the search term there
> because there are
On Tuesday, April 1, 2014 11:09:23 AM UTC-5, Ken Barber wrote:
>
> >> Isn't that the opposite of what you've been asking for as the default,
> >> do you mean "environment = $::environment" here or have you changed
> >> your mind about the default?
> >>
> >
> > I think the default when you le
On Tue, Apr 01, 2014 at 05:09:23PM +0100, Ken Barber
wrote:
Isn't that the opposite of what you've been asking for as the default,
do you mean "environment = $::environment" here or have you changed
your mind about the default?
I think the default when you leave out a parameter from a query
On 1 April 2014 17:52, Ken Barber wrote:
> >> >> This seems a bit backwards to me, for all other parts of the query
> you
> >> >> just leave it out if you don't want to match on it. There's no need
> for
> >> >> a
> >> >> explicit tags=='*' if you want to match on all tags for example. So I
> >>
>> Isn't that the opposite of what you've been asking for as the default,
>> do you mean "environment = $::environment" here or have you changed
>> your mind about the default?
>>
>
> I think the default when you leave out a parameter from a query should be to
> not match on that parameter, like it
>> >> This seems a bit backwards to me, for all other parts of the query you
>> >> just leave it out if you don't want to match on it. There's no need for
>> >> a
>> >> explicit tags=='*' if you want to match on all tags for example. So I
>> >> don't
>> >> see why environment matching would work th
On Mon, Mar 31, 2014 at 1:47 PM, Ken Barber wrote:
> > Coarser grained too, perhaps? That is, for the case where puppetdb is
> > configured with collection_environments = 'same', does it not make sense
> to
> > support, say,
> >
> > Nagios_host<<| environment == * |>>
> >
> > to collect reso
On 1 April 2014 15:59, Ken Barber wrote:
> > I... kinda like that suggestion. I would keep current behaviour intact,
> so
> > collection would work 'as expected though weirdly' and not break current
> > manifests. People who are up to date on this can explicitly select an
> > environment to colle
On 2014-04-01 15:59, Ken Barber wrote:
I... kinda like that suggestion. I would keep current behaviour
intact, so
collection would work 'as expected though weirdly' and not break
current
manifests. People who are up to date on this can explicitly select
an
environment to collect.
I also think
On 2014-01-04 11:11, Erik Dalén wrote:
On 1 April 2014 03:43, Ken Barber mailto:k...@puppetlabs.com>> wrote:
>> Upon reflection, I think it would be wise to control which
resources are
>> collected strictly via search expressions. I disfavor a
configuration
>> setting aff
> I... kinda like that suggestion. I would keep current behaviour intact, so
> collection would work 'as expected though weirdly' and not break current
> manifests. People who are up to date on this can explicitly select an
> environment to collect.
>
> I also think that this approach works better
I... kinda like that suggestion. I would keep current behaviour intact, so
collection would work 'as expected though weirdly' and not break current
manifests. People who are up to date on this can explicitly select an
environment to collect.
I also think that this approach works better for comm
On 1 April 2014 03:43, Ken Barber wrote:
> >> Upon reflection, I think it would be wise to control which resources are
> >> collected strictly via search expressions. I disfavor a configuration
> >> setting affecting that, because if there were one then it would be
> likely
> >> that different m
On 2014-04-01 03:43, Ken Barber wrote:
Upon reflection, I think it would be wise to control which
resources are
collected strictly via search expressions. I disfavor a
configuration
setting affecting that, because if there were one then it would be
likely
that different modules would be develo
On 31.03.2014 21:43, Ken Barber wrote:
Upon reflection, I think it would be wise to control which
resources are
collected strictly via search expressions. I disfavor a
configuration
setting affecting that, because if there were one then it would be
likely
that different modules would be develo
Works for me.
On Mon, Mar 31, 2014 at 6:43 PM, Ken Barber wrote:
> >> Upon reflection, I think it would be wise to control which resources are
> >> collected strictly via search expressions. I disfavor a configuration
> >> setting affecting that, because if there were one then it would be
> li
>> Upon reflection, I think it would be wise to control which resources are
>> collected strictly via search expressions. I disfavor a configuration
>> setting affecting that, because if there were one then it would be likely
>> that different modules would be developed with different assumptions
> Coarser grained too, perhaps? That is, for the case where puppetdb is
> configured with collection_environments = 'same', does it not make sense to
> support, say,
>
> Nagios_host<<| environment == * |>>
>
> to collect resources from all environments? Or maybe the smoothest path
> would be
On Sunday, March 30, 2014 9:53:39 PM UTC-5, Ken Barber wrote:
>
> >> I'm all for only collection from the environment you're from but there
> needs
> >> to be a way to override this. No matter the environment I still want
> all my
> >> machines monitored by my Nagios instance which happens to
>> > I'm all for only collection from the environment you're from but there
>> > needs
>> > to be a way to override this. No matter the environment I still want all
>> > my
>> > machines monitored by my Nagios instance which happens to be running on
>> > the
>> > production environment.
>>
>> I con
On Sun, Mar 30, 2014 at 7:49 PM, Ken Barber wrote:
>
> > I'm all for only collection from the environment you're from but there
> needs
> > to be a way to override this. No matter the environment I still want all
> my
> > machines monitored by my Nagios instance which happens to be running on
> th
>> I'm all for only collection from the environment you're from but there needs
>> to be a way to override this. No matter the environment I still want all my
>> machines monitored by my Nagios instance which happens to be running on the
>> production environment.
>
> I concur with the sentiments a
>> This is the world I see, it won't affect everyone though and
>> theoretically with 1 hour check-ins it will be solved next run. My
>> fear is more around those that don't run puppet as often.
>
> Oh. I was under the impression most people run Puppet at least every half
> hour, if not even more o
> This is the world I see, it won't affect everyone though and
> theoretically with 1 hour check-ins it will be solved next run. My
> fear is more around those that don't run puppet as often.
Oh. I was under the impression most people run Puppet at least every half
hour, if not even more often
> The one issue I see with that approach is what happens when your monitoring
> system, *choke* nagios *choke* is dependant on said exported resources.
> Wiping the database clean isn't really an option in that case or you'd need
> to temporarily disable reloading your monitoring until everyone's c
The one issue I see with that approach is what happens when your monitoring
system, *choke* nagios *choke* is dependant on said exported resources.
Wiping the database clean isn't really an option in that case or you'd need
to temporarily disable reloading your monitoring until everyone's checke
Interesting perspective, thanks Spencer.
On Sat, Mar 29, 2014 at 2:02 AM, Spencer Krum wrote:
> To be honest, I'm not sure it's a big deal. I'm okay with just
> re-initializing the database and pushing new puppetdb and modified code on
> the same day. The use here is to keep test stuff out of pro
To be honest, I'm not sure it's a big deal. I'm okay with just
re-initializing the database and pushing new puppetdb and modified code on
the same day. The use here is to keep test stuff out of production only,
not anything more complicated.
On Fri, Mar 28, 2014 at 6:52 PM, Ken Barber wrote:
>
> We've been simply tagging resources with env_${environment} both on export
> and collect.
Which sounds like a reasonable work-around. In this case only option 2
would guarantee uninterrupted service for you correct?
ken.
--
You received this message because you are subscribed to the Google Gr
We've been simply tagging resources with env_${environment} both on export
and collect.
On Fri, Mar 28, 2014 at 1:05 PM, Ken Barber wrote:
> Thanks for your perspective John, much appreciated.
>
> On Fri, Mar 28, 2014 at 7:15 PM, John Bollinger
> wrote:
> >
> >
> > On Friday, March 28, 2014 12
Thanks for your perspective John, much appreciated.
On Fri, Mar 28, 2014 at 7:15 PM, John Bollinger
wrote:
>
>
> On Friday, March 28, 2014 12:46:41 PM UTC-5, Ken Barber wrote:
>>
>> Hey all,
>>
>> TL;DR: We're adding support to environments to PuppetDB but have a
>> small migration hassle we want
On Friday, March 28, 2014 12:46:41 PM UTC-5, Ken Barber wrote:
>
> Hey all,
>
> TL;DR: We're adding support to environments to PuppetDB but have a
> small migration hassle we wanted some community opinion on. If you're
> interested in PuppetDB and environments read on.
>
> [...]
>
> Anyway -
45 matches
Mail list logo
