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

Octave J. Orgeron octave.orgeron at oracle.com
Fri May 5 21:35:16 UTC 2017

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 
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.


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170505/3cd86e3f/attachment.html>

More information about the OpenStack-dev mailing list