On 05/18/2014 07:47 AM, David Schmitt wrote:
> Hi,
>
> thank you Jeremy for sharing your setup. That looks very nice indeed!
>
> I do have a few questions, which might help further the understanding of
> r10k deployments.
>
> * How is r10k used with local vagrant development?
>
I guess I would have to better understand in what capacity you are
thinking with local vagrant development. All r10k is doing is checking
out the repo to a cached directory then deploying the branches out as
environment directories under the specified basedir. Likewise the
Puppetfile itself is also understood by librarian-puppet which can
install the modules specified into a modules/ sub-directory and is
actually part of my local workflow to test and ensure I have
dependencies met when including a new module since r10k doesn't do the
dependency check itself and simply installs only what's specified in the
Puppetfile.
> * How do you manage local patches to puppet-forge modules?
>
I approach modifications as I do as a Debian Developer, and if I need
to patch a forge module I've forked it, fixed it and submitted a pull
request back to the author. The Puppetfile format allows for both
specifying the forge module or a git repo and with r10k > 1.1.3 it
handles switching between a forge module declaration and a git repo so
until the patch is accepted I can point the module at the modified git repo.
>
> Some notes from my side:
>
> * jenkins with multiple branches: depending on the complexity of your
> jobs, and non-functional requirements, you might consider using
> jenkins-job-builder to create separate jobs for each branch, or use
> one of the more built-in mechnisms like the GIT_BRANCH environment
> variable or job parameters (when triggering externally).
>
I'll have to take a look at jenkins-job-builder and see if it can't
provide the solution I'm looking for. My job that triggers the r10k
deployment is using GIT_BRANCH to decide which environment to update.
The trick is in the promotion trigger as I currently have to pass the
next branch to promote to and the actual job itself for development &
staging which have this promotion trigger are locked by specifying the
"Branches to build" within the job. The production branch deploy job is
almost identical with the exception it uses the git publisher to tag the
run on success and it doesn't have the promotions.
> * For bootstrapping, you might want to look into the kafo tool
> https://github.com/theforeman/kafo
> That is being developed by the foreman guis and can use puppet
> modules and manifests to bootstrap/install systems.
>
As I haven't used theforeman I haven't looked much at the other
projects coming out of it. I'll have to take a look at this and see.
>
> Regards, David
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5378CE50.7010407%40UnderGrid.net.
For more options, visit https://groups.google.com/d/optout.
