----- Original Message ----- > From: "Tom Poulton" <poulton...@gmail.com> > To: puppet-users@googlegroups.com > Sent: Monday, May 13, 2013 3:38:34 PM > Subject: [Puppet Users] MCollective deployment pattern > > Hi all > > I have a scenario in mind for MCollective and I was looking for > some feedback > > The basic idea is this: > 1) A code push to Git triggers a Jenkins build > 2) A successful build triggers automatic deployment to an automated > functional test environment > 3) Functional tests run automatically and the results are reported etc > > This is just basic CI practice and 1) and 3) are sorted, the only issues > are with 2) and the trigger for 3). The deployment job in Jenkins just > copies files up to the Puppet master ready for deployment and service > restarts etc etc, however with a basic puppet setup one has to wait for the > clients to run to pickup the new changes and restart services etc and only > then can Jenkins run the automated tests. > > So the plan is for Jenkins to trigger a run on all the required Puppet > clients via MCollective (filtered by environment), synchronously wait for > the clients to finish and then run the tests. This has another advantage in > that we can back off the Puppet run interval (as important changes are > triggered by MCollective) which gives the Puppet master a bit of breathing > room, and the clients can just check-in every hour or so to check > everything is in order. > > This also extends to deployments to other environments that have manual > deployment triggers such as a QA environment. Even though the deployment is > triggered by the QA team, the upload of the artifacts, running of puppet > clients and notification of a successful deployment should all be automated. > > 1): Does this make sense as a pattern, if not what is the best practice for > implementing this part of the CI and CD pipeline with puppet / jenkins / > mcollective etc? > > 2): How would this work in practice. I can run "mco puppet runonce" which > is fine, but if I filter by environment "mco puppet runonce --environment > aft" I get the "Cannot specify any custom puppet options when the daemon is > running" error. I can workaround this by stopping the daemons on every box, > however this means that the clients no-longer check in periodically. Is > there a fix for this or would you recommend turning them off anyway when > using a tool such as MCollective and doing ALL configuration updates via > MCollective triggers?
--environment here is not a filter, you're asking it to do a one-off run against a different puppet environment. If you want to filter use -W environment=foo > 3) I need to do some more testing now, but just in case anyone knows off > the top of their heads, will an MCollective runonce call be synchronous, > i.e. will the mco call only finish once each client has reported that they > have finished their runs? If it's not, does anyone know of a good way to > check for a finished deployment (some command line wizardry with mco puppet > status / mco puppet summary, etc)? it is not, it triggers a run and returns - puppet runs can take any number of times and do any number of things including restart mcollective, so this makes doing a synch run a rather nasty prospect. We def need some better approach and have plans for that but right now you need to involve triggering runs and either inspecting them or querying your reporting infrastructure for status. I'd have loved to be able to influence the config version - or similar - so that you can tag a specific puppet run with some identifiable piece of information that you can later correlate against reporting for instance to be able to say all the nodes run configuration tagged foo, and periodically query the reporting infra for nodes successfully having run a configuration tagged foo but this is not posible today > > I have done my research with Google and read a fair amount about > MCollective from various sources during the investigation and > implementation, however if this is already documented or I'm missing > something stupid I apologise in advance > > Thanks > > -- > 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 post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
