Multiple apps with same branch names

[Finchster]

It appears that if you have multiple sources/apps defined and a branch has the same name in both sources then it tries to merge the two branches together under one environment which gets messy. After a few tests it does not create two separate environments.

The preferred method for handling this would be to append the repo's name to the branch name and name the environment $repo_$branch. This way dynamic environments can be created by separate application owners without worrying about not re-using a branch name.

[adam-vessey]

This is pretty much implemented in #53.

[Ancillas]

Ah, nm. I get it now.

On Thursday, August 1, 2013, Adam wrote:

This is pretty much implemented in #53#53
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-21978868
.

[glarizza]

I'm hitting this same issue in 1.0.0 too --> https://gist.github.com/glarizza/5a81e45f2f489d87d464 and the prefixing should alleviate it...

[adrienthebo]

This should be fixed by GH-53, so I'm targeting this at 1.1.0.

[binford2k]

IMHO, the prefix solution is kind of hackyugly. It means that my modulepath of:

/etc/puppetlabs/puppet/environments/$environment/modules

Doesn't work. Instead I need to use:

/etc/puppetlabs/puppet/environments/puppet_$environment/modules

and something similar for hiera. It works, but I don't think it should be necessary.

[adam-vessey]

@binford2k Use the Puppetfile to grab the modules on which each environment is dependent? Your modpath can include multiple paths...

[glarizza]

The bigger deal is that this is going to be a backwards-incompatible change in the middle of a series...the environment folders that are created aren't going to match your existing $modulepath setting in puppet.conf. While I think the prefixing is necessary and fixes some big R10k bugs, actually prefixing the FILENAME on disk should be kept for a major release.

Is there a way internally to track the branch as "puppet_#{branchname}" but only create the folder name on-disk as "#{branchname}"? Within a single repo/source, you're not going to have conflicting branch names, so I don't think we'd have any clashes here. Thoughts?

[adam-vessey]

If I'm understanding correctly, what would address your concerns is to only default to using prefixes when there are multiple repos under the same basedir, and only in those basedirs where there are multiple repos being cloned?

[adrienthebo]

It was an oversight that I released the behavior as-is, because it was backwards incompatible. (To be honest I didn't realize how many users were using multiple repositories successfully.) I think that in the short run we need to revert the default case to never prefix, and in the longer run have better detection of when prefixing is needed.

[adrienthebo]

@adam-vessey for the short term, do you think that 8cb2209 would be adequate to address this problem? I think that we can just roll back this behavior change in 1.1.1 and consider adding better detection in either 1.2 or 2.

[adam-vessey]

@adrienthebo Looks like that should do it.

If it seems like it would be useful, I'll try to get some code together to do the actual counting (should be fairly quick), so we can default to prefixing where it seems to be required.

[adrienthebo]

In the long run I think we'll need to build a full directory structure of what files are going to go where, so we can do smarter things with prefixing and purging and whatnot. If we have that, a lot of things get much simpler.

(Also, thanks for the really fast response. Holy responding to notifications batman!)

[adrienthebo]

Notes for updating to 1.1.1

If you are putting multiple sources in a single directory, do this:

sources:
  first:
    remote: 'git://something.com/repo.git'
    prefix: true
    basedir: '/shared/basedir'
  second:
    remote: 'git://somethingother.com/repo.git'
    prefix: true
    basedir: '/shared/basedir'

This is equivalent to the automatic behavior introduced in 1.1.0.

If you're using multiple sources in different directories you can omit the prefix section:

sources:
  first:
    remote: 'git://something.com/repo.git'
    basedir: '/first/basedir'
  second:
    remote: 'git://somethingother.com/repo.git'
    basedir: '/second/basedir'

If you modified your modulepath to something like this:

[master]
modulepath = /etc/puppetlabs/puppet/environments/first_${environment}

You can omit the first_ prefixing.

[njam]

Isn't the prefixing making usage a bit too complicated? IMO it would be nice if puppet wouldn't need to know anything about my different r10k-sources, i.e. I shouldn't be required to adjust the modulepath when changing the sources. (Maybe the same @binford2k was saying.)
How about that r10k would merge the modules from multiple sources into one directory for each environment?

[adrienthebo]

@njam The prefixing is a solution to one set of problems, but it isn't applicable to all solutions. If you're in a situation where you have a multi-tenant puppetmaster and you want each group to have an isolated set of modules, like qa_production, qa_featurebranch, ops_production, and so forth, prefixing is great. However if you have multiple repositories that are being blended into a single environment it gets more complex. It's not strictly possible to just mix the modules directories together since there might be conflicts in the Puppetfiles and there might be files committed in both repositories, so I don't think that there's a really simple answer to this.

Since the original problem described in this issue is resolved I'm going to close this issue. @njam if you think that there are better ways of handling this I would love your input; just file an issue on this project and we can go from there. :)

Thanks to everybody for contributing to the reporting on this issue!