[chef] Re: Re: An deep topic

[Daniel DeLeo < >]

This is a bit more about omnibus than berkshelf, straying maybe a bit off 
topic, but here goes.


On Friday, July 11, 2014 at 6:56 AM, Brian Akins wrote:  
> Coming late to this thread, but I am one of the folks who had an offline 
> discussion/rant with lusis.  
>  
> When Heartbleed (#1) happened, I needed to rebuild a ton of omnibus things 
> and omnibus was just horribly broken. It had worked fine just a few days 
> before then it just didn't. In a fury of vendoring things and doing 
> horrible hacks to get through the ordeal, I vented privately to a few folks 
> who were having to do the same and also had a few public "wtf?!" comments. 
> In this instance, it was just incredible bad timing and had the "breaking 
> features" happened a week later, it probably would not have been a big 
> deal. It was a stressful 48-72 hours to put it mildly, and the rants were 
> just me blowing off some steam. Then a few weeks later, omnibus broke 
> again, then again, etc. I do appreciated the statement ChefCo made 
> concerning omnibus and what would and would not be "supported" - it was 
> just a little late for me. Similar things have happened with other parts of 
> the toolchain.

This has always been the most confusing part of this (for lack of a better 
word) disagreement to me. My initial reaction to this is, “why would you go 
through a major breaking change just to get a newer version of OpenSSL?”. All 
of the breaking changes in omnibus followed the semver guidelines, why not 
just pin to “~> 1.0” ?

I have to imagine that you would’ve done that if you thought you could, 
though. So I’m guessing that you pulled down the latest omnibus-software, 
that project had a dependency on new omnibus, and you felt like that was your 
best or maybe only option to accomplish your goal of shipping you project 
with a patched OpenSSL. Clearly, that sucks.

I think there’s a couple of things we should consider to make this better in 
the future:

1. We announced on our blog that we’re only going to support a very narrow 
scope of functionality in omnibus-software, but I think it’s the right thing 
to do for us to make an exception for severe security issues like heart 
bleed. For example, we could have provided a branch of omnibus-software that 
was omnibus 1.0 compatible that had just the heartbleed patch. This is 
something we did anyway, because we have a lot of omnibus projects and we 
don’t keep them all on the bleeding edge.

2. There’s a huge difference in how we at Chef Software think about the 
“build lab” feature of omnibus and how a lot of people use it. To build our 
own products, we have a jenkins cluster with long-lived build slaves (on a 
mishmash of clouds and some physical hardware) that run the omnibus builds 
and move the artifacts around. The “build lab” stuff is only used for 
development. Lots of people outside Chef Software seem to be using the build 
lab as the thing that builds the artifacts they release to their users. Given 
that understanding, we’ll be more conscientious about changing the build lab 
stuff in the future. Also, if you want to have an optional different 
configuration for the build lab that uses different tools, then submit it as 
a patch.

3. Instead of seething privately or subtweeting us, find us on IRC, post to 
this list, create a bug, or non-sub-tweet at us (or all four). We could’ve 
gotten you a minimal patch for omnibus-software that worked with your 
existing tools (we did exactly that for our own needs) to solve the immediate 
problem with a lot less hassle.

>  
> Hugs to every one. I feel like this should be a discussion at a bar or 
> something.
>  
> --Brian  
Like Adam said, come to the summit and we can :)  

--  
Daniel DeLeo