The kind of thing I was thinking of was selecting where to run jobs by puppet class, or even requiring that certain classes are assigned to certain nodes (requiring a pre-req class before you actually send over a job to build). In my mind I envisioned extensions to something like Foreman where you can get a list of jobs that are valid for each node by clicking the node (in a job you could apply constraints like only boxes with mysql::server and > 4G of ram).
Another example of the kinds of terrible stuff I engineer when left to my own devices is I wrote a job in rundeck that at the end wrote a .pp to /tmp/ and called it so that I could use templates in Puppet to build the configuration file to distribute. Basically a lot of the time I just need a way to trigger one time puppet manifests with a gui of some kind I can give to developers. I could very easily just spit a few scripts onto the boxes and call those for the build, I just want a way to enable/disable the jobs. I can't think of any other good way to say "do a one time run of project::build_core on the following matching nodes: x, y, z". I am really just using rundeck for the equivalent of that. Other things I would think of using this for is handling deploying a bunch of servers where server 1 has to be fully provisioned before 2 and on 2 at least one service has to be up before 3 can do its thing. It's something that's still a hassle to do well within Puppet. On Tue, Sep 13, 2011 at 4:07 PM, Brian Gupta <brian.gu...@brandorr.com>wrote: > If you want something simple and don't need a GUI, many folks are using > either Capistrano (Ruby) or the very similar Fabric (Python) for deployment. > You can populate hostlists via Foreman queries. That said, I am not sure > what sort of integration with Puppet/Foreman you are looking for. > > Cheers, > Brian > > On Tue, Sep 13, 2011 at 3:53 PM, Ashley Penney <apen...@gmail.com> wrote: > >> I know this has come up on the list numerous times before but I >> thought it would be a good time to see if the state of the art has >> advanced for this kind of thing. I wanted to know how people are >> handling higher level deployment of applications - things that have to >> be done repeatedly but not all the time. An example of this is >> checking an application out of svn, building it, creating a package >> and then moving it off to a repo. Or even just building/installing >> locally for developers. >> >> It never seems to fit well into Puppet for me and I end up with crazy >> complicated manifests to deal with this kind of thing. I recently >> moved these jobs into Rundeck (www.rundeck.org) which works pretty >> well but doesn't really leverage any of the stuff I have within >> Foreman/Puppet. I've seen suggestions to use mcollective but this >> doesn't easily integrate our existing scripts (written in many >> languages) or processes and would require me to force a lot of >> developers to work differently. I could just have classes that >> trigger scripts only when some condition is met (like /.buildapp >> files) or something along those lines but nothing seems elegant. >> >> What I'm trying to find out is what other people did to handle this? >> I want something I can build up over time and slowly migrate legacy >> apps and processes into without having to do a massive up front >> development. It should also be relatively simple and not require me >> to code anything as anyone on the list who knows me can tell you that >> I am absolutely awful at coding. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > -- > <http://aws.amazon.com/solutions/solution-providers/brandorr/> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
