Puppet environment name / branch name

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 21, 2013 at 04:27:47PM +0100, David Caro wrote:
> On Thu 21 Nov 2013 03:57:27 PM CET, Itamar Heim wrote:
> > On 11/21/2013 04:46 PM, David Caro wrote:
> >> On Thu 21 Nov 2013 03:03:00 PM CET, Itamar Heim wrote:
> >>> On 11/21/2013 03:29 PM, Ohad Basan wrote:
> >>>> +1
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> >>>>> To: infra at ovirt.org
> >>>>> Sent: Wednesday, November 20, 2013 8:27:39 PM
> >>>>> Subject: Puppet environment name / branch name
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I just deployed r10k to be the deployment method and it works generally
> >>>>> well. One problem is that it maps branches one to one. Currently I
> >>>>> worked around this by making a symlink, but I think we should rename our
> >>>>> master branch to production. Opinions?
> >>>
> >>> is that common? usually master is named master.
> >>
> >> Maybe it's better to change puppet config to use master as the
> >> 'production' environment source of manifests. I say that because it's
> >> usually a mess to have a branch that it's not the master as master...
> >> (@work we use development as master in one of the repos, and I always
> >> submit a patch or two a month to master instead xd)
> >
> > well, one other though is that if you ever intend to have more than a single
> > branch, master is usually not the stable production one...
> >
> 
> I suppose that it depends on the flow the company/project uses, in my 
> last job we used master as the stable branch, and we had devel as the 
> non-stable branch and one branch for each major version we supported, 
> but master was always the latest major version production-ready code. 
> Then on master we had  tags for each release and so on. I suppose they 
> get the idea from gitflow 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> But yes, bad habits are hard to get rid of. Any way is fine for me, but 
> if no one has any reason for the other way, I vote for using master 
> instead of production.

I think r10k doesn't care about branches, it just maps them 1-to-1 to
puppet environments. That means we can also move all our puppet clients
to master if you think that's better. We could also add a testing branch
to create a testing environment for example.

My suggestion to make it production is that even when you're writing
patches, you know it's for production.

My experience with working on non-master is that it's trivial for new
clones (assuming you change HEAD on the remote server) and some effort
for every existing clone.