[openstack-dev] [tc] persistently single-vendor projects

Fox, Kevin M Kevin.Fox at pnnl.gov
Thu Aug 4 18:39:27 UTC 2016


Sorry, I was a bit unclear here. I meant the radosgw in particular. I've seen multiple OpenStack projects fail to integrate with it.

The most recent example I can think of is Trove can't do database backups to it as the namespacing is slightly different in the older radosgw versions. (I think this is made more uniform in Jewel, but I haven't tested it). I know tempurl's work slightly differently too so may affect services that work with them.

I don't think the differences are really intentional, more that there isn't an official swift api spec and no cross testing is done because the OpenStack api test suite doesn't run against radosgw as its not in the tent.

Thanks,
Kevin
________________________________________
From: Erno Kuvaja [ekuvaja at redhat.com]
Sent: Thursday, August 04, 2016 9:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

Kevin,

What do you mean by "Other OpenStack projects don't take it into
account because its not a big tent thing"? I think there is pretty
decent adoption of Ceph across the projects where it would make sense.
Also I doubt none of them would be against 3rd party Ceph gates to
those project if the Ceph community felt that the testing is not
sufficient. We have for example Cinder being brilliant example of
demanding driver providers providing CI for their backends.

Would such demand for 3rd party CI across OpenStack rather than just
Cinder answer your concerns of the testing and how far we are willing
to take that?

- Erno

On Thu, Aug 4, 2016 at 4:57 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> Ok. I'll play devils advocate here and speak to the other side of this, because you raised an interesting issue...
>
> Ceph is outside of the tent. It provides a (mostly) api compatible implementation of the swift api (radosgw), and it is commonly used in OpenStack deployments.
>
> Other OpenStack projects don't take it into account because its not a big tent thing, even though it is very common. Because of some rules about only testing OpenStack things, radosgw is not tested against even though it is so common. This causes odd breakages at times that could easily be prevented, but for procedural things around the Big Tent.
>
> I do think this should be fixed before we advocate single vendor projects exit the big tent after some time. As the testing situation may be made worse.
>
> Thanks,
> Kevin
> ________________________________________
> From: Thierry Carrez [thierry at openstack.org]
> Sent: Thursday, August 04, 2016 5:59 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Thomas Goirand wrote:
>> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>>> But if a project is persistently single-vendor after some time and
>>> nobody seems interested to join it, the technical value of that project
>>> being "in" OpenStack rather than a separate project in the OpenStack
>>> ecosystem of projects is limited. It's limited for OpenStack (why
>>> provide resources to support a project that is obviously only beneficial
>>> to one organization ?), and it's limited to the organization itself (why
>>> go through the OpenStack-specific open processes when you could shortcut
>>> it with internal tools and meetings ? why accept the oversight of the
>>> Technical Committee ?).
>>
>> A project can still be useful for everyone with a single vendor
>> contributing to it, even after a long period of existence. IMO that's
>> not the issue we're trying to solve.
>
> I agree with that -- open source projects can be useful for everyone
> even if only a single vendor contributes to it.
>
> But you seem to imply that the only way an open source project can be
> useful is if it's developed as an OpenStack project under the OpenStack
> Technical Committee governance. I'm not advocating that these projects
> should stop or disappear. I'm just saying that if they are very unlikely
> to grow a more diverse affiliation in the future, they derive little
> value in being developed under the OpenStack Technical Committee
> oversight, and would probably be equally useful if developed outside of
> OpenStack official projects governance. There are plenty of projects
> that are useful to OpenStack that are not developed under the TC
> governance (libvirt, Ceph, OpenvSwitch...)
>
> What is the point for a project to submit themselves to the oversight of
> a multi-organization Technical Committee if they always will be the
> result of the efforts of a single organization ?
>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list