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

>
>
> On Tue, Oct 13, 2015 at 6:04 AM, Trevor Vaughan <tvaug...@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.

>
> 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).
>
>
>
>> Thanks,
>>
>> Trevor
>>
>> On Mon, Oct 12, 2015 at 2:31 PM, Michael Stahnke <stah...@puppetlabs.com>
>> wrote:
>>
>>> 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/
>>>
>>>
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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 --
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUYQ8MdVkPBCoYvPyKTw_WGk5TaNYj-11bK%2B1HYYk6oSA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUYQ8MdVkPBCoYvPyKTw_WGk5TaNYj-11bK%2B1HYYk6oSA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7L%2Bb8Tq7mAjm_COZbjAcy5PONCcktgDYS2tRE2s9WWHwdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to