Some links that might be helpful: https://docs.puppet.com/puppet/latest/lang_classes.html https://docs.puppet.com/puppet/latest/type.html
- Sam Ruby On Wed, Dec 14, 2016 at 10:33 AM, Sam Ruby <ru...@intertwingly.net> wrote: > On Wed, Dec 14, 2016 at 9:44 AM, Rich Bowen <rbo...@rcbowen.com> wrote: >> >> On 12/14/2016 09:41 AM, Shane Curcuru wrote: >>> Rich Bowen wrote on 12/14/16 8:45 AM: >>> ...snip... >>>> Yeah, there's no absolutely reason for this to have SLA uptime guarantees. >>>> >>>> Also, it seems like something that ComDev should care about. In >>>> particular, I would be glad to be responsible for the service. And we >>>> could even put it on the feathercast.apache.org VM, so that no new VMs >>>> need to be spun up. >>> >>> +1 all around. I would love to see planet.apache.org doing the >>> auto-aggregation for any committers who opt-in, and to let committers >>> know about it. >>> >>>> So far as puppet, I know absolutely zero, but am willing to learn and/or >>>> get out of the way, as necessary. I'd really like to resurrect this >>>> service, if we can. I don't have a *lot* of extra time right now, but I >>>> think I have enough time to poke at Venus every few weeks and encourage >>>> committers and members to update their entries in the config file. >>> >>> After the holidays I'm done giving new talks at conferences, so I hope >>> to be able to at least help document these kinds of setups, so that >>> ComDev can do a better job of maintaining them. >> >> This particular one is already VERY well documented - see Sam's earlier >> note. And Venus itself is very much set-and-forget. Spinning up a Venus >> instance takes a couple minutes, by hand. It's the Puppet part of it >> that I don't know. > > Thank you (I'm the one who documented it :-)). > > As to the puppet part that you don't know, that's what I want to fix. > I think you will find for the tasks that are needed to get a planet > instance up and running are easy-peasy. > >>> It sounds like if Sam can draft the code for puppet/original setup of >>> Venus on a ComDev VM (same as feathercast seems fine, unless I'm missing >>> something about VM performance) I can assist Rich in finishing app >>> configuration and bringing over any still-live blog entries, etc. > > I will learn nothing by doing that, and by experience know that when > things go wrong (I agree with Rich that Venus is pretty much set and > forget, except when it is not, and by that point the forget part has > already been done) that people will expect me to fix it. > >>> Serious Puppet skills are likely to remain rare outside of infra, but >>> once something is running with a default config - and we have a >>> consistent place to document ComDev tools - it feels like we'll succeed >>> now with our new energy. > > It doesn't take serious puppet skills to do this. But in any case, I > more than have enough - I run puppet to configure my home machines and > even laptop. We can leave the serious stuff to the infra folks, but > having enough puppet skills to be able to configure a VM to run Venus > is something that more people should have. > > So let's get started. There is no deadline. Setting up Venus is only > a few steps, and if we were to do one step a day, it will be up and > running before you know it. > > To start with, all of the puppet configuration is here: > https://github.com/apache/infrastructure-puppet. Only two parts are > relevant to the task at hand. First, there is modules: > > https://github.com/apache/infrastructure-puppet/tree/deployment/modules > > We are going to need to create a planet_apache module. That basically > means that we are going to need to create a file named > modules/planet_apache/manifests/init.pp file. The syntax is > relatively straightforward. At first, it seems strange that it > generally takes about five lines to do anything (create a file, > directory, or user, start a service, create a cron job), but once you > get over that, everything is straightforward. > > The way to create the init.pp file is via a GitHub pull request. If > somebody were to take that first step, I will review it, test it > locally and provide feedback. Once it is ready, I will deploy the > change. Don't be afraid to make mistakes, the goal of this exercise > is to learn. > > The name 'init.pp' is just a default. Should your module get big > enough, you can split things into multiple files. Take a look at the > whimsy_server module for an example. Setting up a Venus instance will > require considerably fewer steps, but examples of each of the steps > can be found there. > > The thing to be aware of is that with puppet you describe the machine > as how you would like it to be configured, NOT by the steps it would > take to make that happen. Every half hour puppet will run and make > sure that the configuration is in place. If, for example, you say > that a file needs to be present, puppet will create it once and then > check to make sure that it is still there. If not, it will recreate > it. > > The second part that is relevant is the files in the data/nodes > directory. As there already is a comdev-vm, my suggestion would be to > use it. (I'm not sure whether or not feathercast is puppetized). > Adding a module to a VM is a matter of adding one line to the list of > classes at the top of the file. I already have a login to > comdev-vm... this isn't actually required, but will enable me to > verify that the steps that have been deployed so far are working. > > - Sam Ruby --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
