community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: planet.apache.org was shutdown - can we remove links?
Date Thu, 15 Dec 2016 00:46:11 GMT
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 <rubys@intertwingly.net> wrote:
> On Wed, Dec 14, 2016 at 9:44 AM, Rich Bowen <rbowen@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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message