Open Stack

On Aug 4, 2016, at 12:43 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:

The problem is, OpenStack is a very fractured landscape. It takes significant amounts of time for an operator to deploy "one more service".

So, I spent a while deploying Trove, got it 90% working, then discovered Trove didn't work with RadosGW. RadosGW was a done deal long ago, and couldn't be re-evaluated at that point. (Plus you cant have more then one swift endpoint in a cloud...). So, for now, I'm supporting a 90% functional Trove.

If I went and installed Ironic tomorrow, would it work with the radosgw I already have? I have no idea. The, "it supports swift" implies but doesn't answer. If I want to consider deploying it now, I have to block out even more time to experiment in order to try. and then do a bunch of manual testing to verify.


Ironic does have radosgw support, and it's documented here: http://docs.openstack.org/developer/ironic/deploy/radosgw.html -- clearly it's not "first class" as we don't validate it in CI like we do with swift, but the code exists and I believe we have users out in the wild.

I know this is orthogonal to the discussion, but I wanted someone seeing this thread to know it does work :).

Thanks,
Jay Faulkner
OSIC

This kind of thing makes it even harder on operators to deploy new services.

Yes, it could be solved at the Ceph level, where they deploy a complete OpenStack with all the advanced services and test everything, but OpenStack is already doing that. It is significantly easier for OpenStack to test it instead of Ceph.

Thanks,
Kevin




________________________________________
From: Ben Swartzlander [ben at swartzlander.org<mailto:ben at swartzlander.org>]
Sent: Thursday, August 04, 2016 12:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 03:02 PM, Fox, Kevin M wrote:
Nope. The incompatibility was for things that never were in radosgw, not things that regressed over time. tmpurls differences and the namespacing things were there since the beginning first introduced.

At the last summit, I started with the DefCore folks and worked backwards until someone said, no we won't ever add tests for compatibility for that because radosgw is not an OpenStack project and we only test OpenStack.

Yes, I think thats a terrible thing. I'm just relaying the message I got.

I don't see how this is terrible at all. If someone were to start up a
clone of another OpenStack project (say, Cinder) which aimed for 100%
API compatibility with Cinder, but outside the tent, and then they
somehow failed to achieve true compatibility because of Cinder's
undocumented details, nobody would proclaim that the this was somehow
our (the OpenStack community's) fault.

I think the Radosgw people probably have a legitimate beef with the
Swift team about the lack of an official API spec that they can code do,
but that's a choice for the Swift community to make. If users of Swift
are satisfied with a the-code-is-the-spec stance then I say good luck to
them.

If the user community cares enough about interoperability between
swift-like things they will demand an API spec and conformance tests and
someone will write those and then radosgw will have something to conform
to. None of this has anything to do with the governance model for Ceph
though.

-Ben Swartzlander



Thanks,
Kevin
________________________________________
From: Ben Swartzlander [ben at swartzlander.org<mailto:ben at swartzlander.org>]
Sent: Thursday, August 04, 2016 10:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

On 08/04/2016 11:57 AM, Fox, Kevin M 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.

I call BS on this assertion. We test things that outside the tent in the
upstream gate all the time -- the only requirement is that they be
released. We won't test against unreleased stuff that's outside the big
tent and the reason for that should be obvious.

This causes odd breakages at times that could easily be prevented, but for procedural things around the Big Tent.

The only way I can see for "odd breakages" to sneak in is on the Ceph
side, if they aren't testing their changes against OpenStack and they
introduce a regression, then that's their fault (assuming of course that
we have good test coverage running against the latest stable release of
Ceph). It's reasonable to request that we increase our test coverage
with Ceph if it's not good enough and if we are the ones causing the
breakages. But their outside status isn't the problem.

-Ben Swartzlander


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<mailto:thierry at openstack.org>]
Sent: Thursday, August 04, 2016 5:59 AM
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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

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