[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Doug Hellmann doug at doughellmann.com
Sat May 6 20:56:03 UTC 2017

Excerpts from Octave J. Orgeron's message of 2017-05-05 15:35:16 -0600:
> Hi Matt,
> And this is actually part of the problem for vendors. Many Oracle 
> engineers, including myself, have tried to get features and fixes pushed 
> upstream. While that may sound easy, the reality is that it isn't! In 
> many cases, it takes months for us to get something in or we get shot 
> down altogether. Here are the big issues we run into:
>   * If it's in support of Oracle specific technologies such as Solaris,
>     ZFS, MySQL Cluster, etc. we are often shunned away because it's not
>     Linux or "mainstream" enough. A great example is how our Nova
>     drivers for Solaris Zones, Kernel Zones, and LDoms are turned away.
>     So we have to spend extra cycles maintaining our patches because
>     they are shunned away from getting into the gate.
>   * If we release an OpenStack distribution and a year later, a major
>     CVE security bug comes along.. we will patch it. But is there a way
>     for us to push those changes back in? No, because the branch for
>     that release is EOL'd and burned. So we have to maintain our own
>     copy of the repos so we have something to work against.
>   * Taking a release and productizing it takes more than just pulling
>     the git repo and building packages. It requires integrated testing
>     on a given OS distribution, hardware, and infrastructure. We have to
>     test it against our own products and handle upgrades from the
>     previous product release. We have to make sure it works for
>     customers. Then we have to spin up our distribution, documentation, etc.
> Lastly, just throwing resources at this isn't going to solve the 
> cultural or logistics problems. Everyone has to work together and Oracle 

Can you expand on what you see as cultural and logistical problems?


> will continue to try and work with the community. If other vendors, 
> customers, and operators are willing to work together to build an LTS 
> branch and the governance around it, then Oracle will support that 
> effort. But to go it alone I think is risky for any single individual or 
> vendor. It's pretty obvious that over the past year, a lot of vendors 
> that were ponying up efforts have had to pull the plug on their 
> investments. A lot of the issues that I've out-lined effect the 
> bottom-line for OpenStack vendors. This is not about which vendor does 
> more or less or who has the bigger budget to spend. It's about making it 
> easier for vendors to support and for customers to consume.
> Octave
> On 5/5/2017 2:40 PM, Matt Riedemann wrote:
> >
> > If you're spending exorbitant amounts of time patching in your forks 
> > to keep up with the upstream code, then you're doing the wrong thing. 
> > Upstream your changes, or work against the APIs, or try to get the 
> > APIs you need upstream to build on for your downstream features. 
> > Otherwise this is all just burden you've put on yourself and I can't 
> > justify an LTS support model because it might make someone's 
> > downstream fork strategy easier to manage. As noted earlier, I don't 
> > see Oracle developers leading the way upstream. If you want to see 
> > major changes, then contribute those resources, get involved and make 
> > a lasting effect.
> >

More information about the OpenStack-dev mailing list