community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: was shutdown - can we remove links?
Date Wed, 14 Dec 2016 15:33:36 GMT
On Wed, Dec 14, 2016 at 9:44 AM, Rich Bowen <> 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 VM, so that no new VMs
>>> need to be spun up.
>> +1 all around.  I would love to see 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:  Only two parts are
relevant to the task at hand.  First, there is 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

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:
For additional commands, e-mail:

View raw message