> Sorry it's taken so long to have a look at your plugin, firstly it works
> and was ridiculously easy to get going (which is always awesome!), I
> ignored the message about the "unknown template type 'iPXE'" as I saw Dom's
> Pull Request comments. As the plugin is already so useful in its current
> form we will start adapting our processes to run it in production (gulp).
>
Glad to hear it - your timing is perfect as the latest version was only
released last week 
> The one thing that is missing, which I'd argue is even more important than
> the button in UI, is rather than using the cron idea you suggested above,
> is using the rake task to sync tags as well as specific branches via git
> hooks on commits. I could add the basic functionality myself and send it
> back to you in a PR pretty quickly, but I realised it probably needs a bit
> of thought around error handling to stop someone trying to sync a branch
> and a tag in the same command. Unfortunately I'm the worst ruby coder in
> the world and for now I am comfortable just letting it sync to the master
> branch (which in our setup tracks the latest tag).
>
To the best of my knowledge, it should work fine with a tag - the code just
calls "git clone -b $branch" but $branch works equally well as a tag. Git
doesn't differentiate between a tag or a branch (at least, not since quite
an old version number). For example:
[greg:/tmp]$ git clone
https://github.com/GregSutcliffe/community-templates-b this_tag
Cloning into 'community-templates'…
remote: Counting objects: 380, done.
remote: Compressing objects: 100% (253/253), done.
remote: Total 380 (delta 142), reused 302 (delta 88)
Receiving objects: 100% (380/380), 50.28 KiB | 0 bytes/s, done.
Resolving deltas: 100% (142/142), done.
Checking connectivity… done.
Note: checking out 'f2debb0691b2bc8ae88c4897835139743c2ad341'.
Give it a try and see if it works as is?
The elephant in the room though is whether or not provisioning scripts
> should follow the same "dev > test > production" environment workflow that
> the puppet modules go through; possibly even living within the same
> repository as the puppet modules(using your dirname option would enable
> that, but running a full-blown git clone on every update promotes keeping
> the provisioning repo as small as possible). Aligning the
> workflows/repositories feels like the right thing to do to, in effect,
> create a genuinely complete infrastructure code repository with foreman
> managing the data and pulling the strings.
>
> The main blocker is Foreman isn't really designed to handle provisioning
> in this way. While some files can be explicitly tied to an environment they
> all need unique names and snippets currently have no concept of an
> environment at all.
>
> I've managed to get round this by using your prefix option to denote the
> environment that the scripts and snippets belong to then using things like
> <%= snippet "#{@host.environment} puppet.conf" %> in my provisioning
> templates to dynamically load the right one, but it does feel a little bit
> hacky.
>
This is great feedback - do open issues at [1] where you feel we can make
this better.
With your plugin the only thing that I think you could do to help is to
> add automatic environment association as a template:sync option (rather
> than in the metadata). Either that or the core product could port some of
> the "checkbox -> select action -> change environment" goodness from the
> hosts page onto the provisioning templates page.
>
I think both are valid - do raise feature requests for these. I think it
would be pretty trivial to have the plugin override the metadata when it's
specified on the cmdline.
> I also think it would be worthwhile for someone to think about how you can
> support the interactions with SCM in a less hands-on way for end users,
> almost as if you could point foreman at a remote repo and it will parse
> your branches and tags to particular defined environments (for puppet
> modules, provisioning templates or anything else). With all the talk in the
> dev channel about using Git to drive Katello it feels like everybody is
> moving in the same direction.
>
So if I'm reading you aright, if we detect a branch structure like
'environments/foo' then we would automatically assign all the templates in
that branch to env 'foo'? That's a really interesting idea… feature
request at [2] please
tl;dr - Awesome plugin - Could you add tag support and
> automatic environment association in the template:sync command? Foreman
> core needs some work.
>
Yep, just raise the issues
Thanks for the feedback!
Greg
[1] Foreman
[2] Foreman
···
On 9 December 2013 04:25, Charlie Derwent wrote:
