Some new tools from PuppetConf

[Michael Stahnke]

A couple of tooling announcements (or maybe just things that happened) during the week of PuppetConf. 

1. Our tool to build our clojure services and packages was open sourced. It's called ezbake[1] (like the oven). It uses our packaging[2] repo as well.  The way our services are managed in terms of init scripts, defaults and the like are all contained within ezbake.

2. Our tool build out AIO packages (for agent or other items) was also open sourced. It's called vanagon[3]. Of note, the actual repo with puppet-agent is not yet open as there is still a bit of cleanup required. It's going to happen soon. (Weeks not months). 

Vanagon was designed to be a build system that worked on any environment that can run rsync and has a libc. It doesn't require ruby on the target, or need vagrant. It can build on physical or virtual targets (and has a docker engine). It was about minimal dependencies. Vanagon operates with a control node talking to the target host. It also integrates very nicely with our vmpooler[4] which is used in our testing system. Issues with this project can filed in the CPR[5] project on our jira. API doc[6] is available on my fork, since we haven't gotten all of that integrated into CI yet. 

I realize this intro is a little sparse, we'll have more information soon. We wanted to get these out though. 

[1] https://github.com/puppetlabs/ezbake

[2] https://github.com/puppetlabs/packaging

[3] https://github.com/puppetlabs/vanagon.

[4] https://github.com/puppetlabs/vmpooler

[5] https://tickets.puppetlabs.com/browse/CPR

[6] http://stahnma.github.io/vanagon/doc/

[Trevor Vaughan]

Hi Michael,

Thanks for getting these released to the public, it's always good to have new workflow tools!

Could you explain the benefits of Vanagon over the Open Build Service? http://openbuildservice.org/help/manuals/obs-reference-guide/

Right now, I'm using Mock for maximum portability in isolated environments but I'm always looking at ways to potentially speed things up.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

[Michael Stahnke]

On Tue, Oct 13, 2015 at 6:04 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

Hi Michael,

Thanks for getting these released to the public, it's always good to have new workflow tools!

Could you explain the benefits of Vanagon over the Open Build Service? http://openbuildservice.org/help/manuals/obs-reference-guide/

Sorry for the late reply.  

Basically, vanagon is much simpler. We've looked at OBS a few times and been unable to make it do what we needed. We might be not very good at it though. When we met with some folks doing OBS in Intel/Yocto a while back, it sounded like they basically needed somebody dedicated 100% to OBS and were submitting patches/fixes to it all the time. The documentation is also sparse, from what we saw.  It might be very good, and honestly we're trying to compete with it. It has much more workflow built in than Vanagon does. 

Vanagon has a few things I really like, but YMMV

1. It's really easy to extend. I find the code very readable, test coverage is pretty good, and all in all, I can bend it to my will.

2. Right now it supports RPM, Deb, DMG/pkg, Swix, Solaris Pkg, AIX rpm and maybe a couple others I'm not remembering right now. We'll be adding Windows in the next couple months. 

3. It has an engine (vmpooler) that works really well with our testing system/CI system. That was huge for us. 

Right now, I'm using Mock for maximum portability in isolated environments but I'm always looking at ways to potentially speed things up.

Yup, we've used mock a lot. It's great, for rpm. There's nothing preventing vanagon from being able to use mock if that's how you want ot do builds. We don't do that because we basically build on a minimal VM and then  destroy it, (which is roughly what mock does, just on the same system). 

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUYQ8MdVkPBCoYvPyKTw_WGk5TaNYj-11bK%2B1HYYk6oSA%40mail.gmail.com.

[Trevor Vaughan]

Hey Michael,

Thanks for the thorough reply. It's nice to know where the various items came from and why they were chosen over their peers.

I'll definitely be taking a deeper look.

Thanks,

Trevor

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMto7LJ%2BpUQ_H_cj6rSxLK3J8LDQhbEE6Amyra-fGvmzQgsX6Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Stahnke]

On Mon, Oct 19, 2015 at 12:41 PM, Michael Stahnke <sta...@puppetlabs.com> wrote:

On Tue, Oct 13, 2015 at 6:04 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

Hi Michael,

Thanks for getting these released to the public, it's always good to have new workflow tools!

Could you explain the benefits of Vanagon over the Open Build Service? http://openbuildservice.org/help/manuals/obs-reference-guide/

Sorry for the late reply.  

Basically, vanagon is much simpler. We've looked at OBS a few times and been unable to make it do what we needed. We might be not very good at it though. When we met with some folks doing OBS in Intel/Yocto a while back, it sounded like they basically needed somebody dedicated 100% to OBS and were submitting patches/fixes to it all the time. The documentation is also sparse, from what we saw.  It might be very good, and honestly we're trying to compete with it. It has much more workflow built in than Vanagon does. \

^^ honestly we're *NOT* trying to compete with it. That not was kind of important there.