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
