The number of branches you have has almost nothing to do with how fast your
nodes converge to a new desired state. If you want them to check in on
command, use mcollective or another orchestration engine to make that
happen.
On Thursday, August 18, 2016, Alex Samad <a...@samad.com.au> wrote:
> Hi
>
> I have recently gone through this problem.
>
> I had initial thought to you different branches for the different
> environments.
> say
> prod
> uat
> sim
> inf
> dev
>
> But was advised best to go with production and testing.
>
>
> so I have and I have used a grouping in my ENC to put machines into the
> above groups. But I am about ready to go back to more branches again. Why
>
> I have setup my profiles
>
> my_ssh profile this handles all the general setup of ssh server and client
> - standard across all machines
>
>
> so my roles just include profile::my_ssh
>
> My issue with this is if I want to now role out a change to my ssh setup I
> can't isolate which box gets its, pot luck, wait long enough and they all
> get it.
>
> I am not sure its the best to go to each dev/uat machine and run puppet
> --environment <mytest> is the best solution plus my ENC sets the
> environment .. don't want pesky dev guys change environments on me.
>
> I don't want to have to create a new profile and attach it to the roles I
> want to test on.
>
> So I am thinking ... multiple branches is sounding good.
>
> But im keen to see what comes out of this.
>
>
> On Friday, 19 August 2016 02:24:58 UTC+10, Rob Nelson wrote:
>>
>> The term 'environment' is overloaded. In the context of puppet, I prefer
>> to think of it as "a set of puppet code/data representing a branch of the
>> controlrepo' (puppet environment), rather than 'an environment that nodes
>> run in' (dev/qa/prod/etc) (node environment). Since you can make the latter
>> part of your hiera hierarchy, the only puppet environment that needs to
>> live forever is 'production'. Inside it, the hieradata has ALL the data for
>> all of the node environments, so they actually all check into 'production'.
>> The hierarchy value for the node environment can be a custom fact,
>> calculated or a file on disk, so nodes can get the right node environment
>> data from the puppet environment 'production'.
>>
>> :hierarchy:
>> - "nodes/%{::trusted.certname}"
>> - "node_env/%{node_env}"
>> - "common"
>>
>> By differenting the various uses of the overloaded term 'environment' a
>> bit, you can actually streamline your workflow quite a bit. Now all your
>> data is in one place. When you create a feature branch for testing, you can
>> then point the canary nodes to that branch (`puppet agent -t --environment
>> ticket1234`, or putting `environment = ticket1234` in puppet.conf). Whether
>> you're changing roles and profiles, hiera data, or the Puppetfile, it's
>> contained in that branch, but you can actually have production, dev, qa
>> nodes check into it and get the new results, so you aren't surprised when a
>> Puppetfile change in dev trickles up to prod and suddenly things blow up.
>> Of course, you need to have some canary nodes in each node environment (or
>> place a LOT of trust in --noop mode) to get there, but I think that's a
>> reasonable goal to work toward.
>>
>>
>>
>> Aside: I know we have discussed workflows and the various types of
>> environments on this list quite a bit this Spring/Summer. Does anyone have
>> a good reference article for this already, or do we need to come up with
>> one? I think this is an important gap to fill.
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Thu, Aug 18, 2016 at 12:07 PM, Mike Sharpton <shar...@gmail.com>
>> wrote:
>>
>>> The static branches are basically Puppet environments in which nodes are
>>> bound/pointed to them in their puppet.conf. This way we can open CR's per
>>> set of nodes and move up the chain. Also, I may have found another option
>>> on Gary's site. We could r10k our hiera data and split it from our control
>>> repo. More to come. Thanks again for thoughts.
>>>
>>>
>>> On Thursday, August 18, 2016 at 10:00:01 AM UTC-5, Christopher Wood
>>> wrote:
>>>
>>>> I'm missing why you need static branches. I'm picturing something more
>>>> like:
>>>>
>>>> git checkout production
>>>> git checkout -b ticket1234
>>>> # make changes, commit, push, test, repeat
>>>> git merge production # catch up on any prod changes, retest
>>>> git tag ticket.1234
>>>> git checkout production
>>>> git merge ticket1234
>>>> git branch -d ticket1234
>>>>
>>>> That way everybody's changes are working pretty close to what
>>>> production is right now.
>>>>
>>>> The alternatives are curating your branches, periodically re-branching
>>>> from production, or just accepting the current state, as near as I can tell
>>>> off the cuff. If you want to maintain something it requires maintenance
>>>> work no matter the tool you pick.
>>>>
>>>>
>>>> On Thu, Aug 18, 2016 at 05:27:40AM -0700, Mike Sharpton wrote:
>>>> > Thanks for your reply. We based our initial design on shit Gary
>>>> says.
>>>> > This may be our only option as you say, to have hiera data
>>>> changes made
>>>> > to each static branch/puppet environment by hand and not merge.
>>>> We need
>>>> > the static branches for separation of Puppet environments.
>>>> Problem with
>>>> > this approach is humans will make errors between each branch
>>>> sometimes or
>>>> > always. The branches/environments will eventually become snow
>>>> flakes over
>>>> > time as far as Hieradata. Perhaps we can possibly merge them
>>>> weekly to
>>>> > lower this risk. Assuming no code changes are in flight, which
>>>> there most
>>>> > likely always will be. The search continues. Thanks again,
>>>> > Mike
>>>> >
>>>> > On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher
>>>> Wood wrote:
>>>> >
>>>> > It sounds like these might help:
>>>> >
>>>> > [1]https://puppet.com/blog/git-workflows-puppet-and-r10k
>>>> >
>>>> > [2]http://garylarizza.com/blog/categories/r10k/
>>>> >
>>>> > Seems like you would benefit from having all teams work from
>>>> branches of
>>>> > current production and merge back, rather than maintaining a
>>>> > semi-permanent dev branch shared by everybody. This is usually
>>>> where I
>>>> > suggest that people review commits and talk to each other and
>>>> figure out
>>>> > what's good, but sometimes that's like pulling teeth.
>>>> >
>>>> > On Wed, Aug 17, 2016 at 01:21:45PM -0700, Mike Sharpton wrote:
>>>> > > Hey all,
>>>> > > We are coming up on an issue in our environment in where we
>>>> have
>>>> > multiple
>>>> > > Puppet environments that are backed by git branches in a
>>>> puppet
>>>> > control
>>>> > > repo. Our Hiera data is stored inside these branches and
>>>> changed
>>>> > > frequently by our Operations teams. Of which we then have
>>>> them
>>>> > merge
>>>> > > changes up the environment chain and r10k through our
>>>> Puppet
>>>> > environments.
>>>> > > This is all fine.
>>>> > > Ex, dev -> test -> production, hiera data changes are moved
>>>> up and
>>>> > tested
>>>> > > each step of the way.
>>>> > > When things aren't fine is when we are testing code in our
>>>> dev or
>>>> > test
>>>> > > branch and we have changed the tags for modules/repos
>>>> inside the
>>>> > > Puppetfile of those branches that we don't want in
>>>> production right
>>>> > away
>>>> > > (dev/test). This code only applies to dev environment, on
>>>> purpose.
>>>> >
>>>> > > Our operations team then comes along with their hiera
>>>> changes and
>>>> > merges
>>>> > > the puppetfile module/repo changes up the chain along with
>>>> the
>>>> > hiera data.
>>>> > > Effectively moving our Puppetfile changes up the chain
>>>> when we
>>>> > don't want
>>>> > > to. We have thought about splitting hiera data out our
>>>> puppet
>>>> > control
>>>> > > module like it was before Puppet 4, but this leaves us no
>>>> room to
>>>> > test
>>>> > > hiera data up our environment chain and also leaves us with
>>>> some CI
>>>> > work
>>>> > > to make this feasible. Having the hieradata in each
>>>> environment is
>>>> > too
>>>> > > nice. We also attempted to monkey with .gitignore, but
>>>> this is not
>>>> > meant
>>>> > > to do what we are trying to do. Don't merge Puppetfile
>>>> unless I
>>>> > want to.
>>>> > > Has anyone ran into this and found a somewhat elegant
>>>> solution?
>>>> > > Everything we are coming up with is either not easy to
>>>> manage, or
>>>> > just
>>>> > > doesn't make sense to do. Perhaps we are missing something
>>>> simple
>>>> > and are
>>>> > > over thinking things. Thanks in advance.
>>>> > > Mike
>>>> > >
>>>> > > --
>>>> > > You received this message because you are subscribed to the
>>>> Google
>>>> > Groups
>>>> > > "Puppet Users" group.
>>>> > > To unsubscribe from this group and stop receiving emails
>>>> from it,
>>>> > send an
>>>> > > email to [1][3]puppet-users...@googlegroups.com.
>>>> > > To view this discussion on the web visit
>>>> > >
>>>> > [2][4]https://groups.google.com/d/msgid/puppet-users/9d9e1
>>>> 8a4-a6e4-4d04-b0b3-377b848a8504%40googlegroups.com.
>>>> > > For more options, visit [3][5]https://groups.google.co
>>>> m/d/optout.
>>>> > >
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> Groups
>>>> > "Puppet Users" group.
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> > email to [6]puppet-users...@googlegroups.com.
>>>> > To view this discussion on the web visit
>>>> > [7]https://groups.google.com/d/msgid/puppet-users/cfcde2dc-
>>>> 2904-4286-bd01-c934857c0ee5%40googlegroups.com.
>>>> > For more options, visit [8]https://groups.google.com/d/optout.
>>>> >
>>>> > References
>>>> >
>>>> > Visible links
>>>> > 1. https://puppet.com/blog/git-workflows-puppet-and-r10k
>>>> > 2. http://garylarizza.com/blog/categories/r10k/
>>>> > 3. javascript:
>>>> > 4. https://groups.google.com/d/msgid/puppet-users/9d9e18a4-a6e4
>>>> -4d04-b0b3-377b848a8504%40googlegroups.com
>>>> > 5. https://groups.google.com/d/optout
>>>> > 6. mailto:puppet-users+unsubscr...@googlegroups.com
>>>> > 7. https://groups.google.com/d/msgid/puppet-users/cfcde2dc-2904
>>>> -4286-bd01-c934857c0ee5%40googlegroups.com?utm_medium=email&
>>>> utm_source=footer
>>>> > 8. https://groups.google.com/d/optout
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-users...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-users%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/1527405f-dda2-4a6b-b35a-70cea5618021%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/1527405f-dda2-4a6b-b35a-70cea5618021%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Rob Nelson
rnels...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAC76iT9QTAK%2B_FBC%3D8_QtYm8C_vHWQTq9XkQBccJC9JHSsWc0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
