Open Stack

I've been trying to follow this thread, but I'll admit I'm confused about what is being asked about or proposed. I'm not sure what "plugins for all" means.

Is "plugins for all" a way to make every plugin in an OpenStack project work the same way? How would that work? There's a huge set of diversity in the kind of things that plugins are used for, so I can't really imagine how there is a common subset that can be used everywhere.

Is "plugins for all" a way to say that every OpenStack project should have a stable API and that's the *only* way to talk to it (i.e. zero knowledge of internal state or design)? I think that's a really good idea that is vital to the future of OpenStack.

Is "plugins for all" a way to say that there is a set of functionality that is guaranteed to be there, eg with Neutron for networking or Trove for DBs, and if a project uses that functionality it must use the right OpenStack project?

I've picked up on elements of all three of these goals throughout the thread, but I'm not sure what's right or if I'm completely missing it.

Please help!

--John




On 19 Jul 2016, at 9:59, Hayes, Graham wrote:

> On 19/07/2016 16:39, Doug Hellmann wrote:
>> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +0000:
>>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>>> Hayes, Graham wrote:
>>>>> [...]
>>>>> The point is that we were supposed to be a level field as a community
>>>>> but if we have examples like this, there is not a level playing field.
>>>>
>>>> While I generally agree on your goals here (avoid special-casing some
>>>> projects in generic support projects like Tempest), I want to clarify
>>>> what we meant by "level playing field" in a recent resolution.
>>>
>>>
>>> Yes - it has been pointed out the title is probably overloading a term
>>> just used for a different purpose - I am more than willing to change it.
>>>
>>> I wasn't sure where I got the name, and I realised that was probably in
>>> my head from that resolution.
>>>
>>>> This was meant as a level playing field for contributors within a
>>>> project, not a level playing field between projects. The idea is that
>>>> any contributor joining any OpenStack project should not be technically
>>>> limited compared to other contributors on the same project. So, no
>>>> "secret sauce" that only a subset of developers on a project have access to.
>>>
>>> There is a correlation here - "special sauce" (not secret obviously)
>>> that only a subset of projects have access to.
>>>
>>>> I think I understand where you're gong when you say that all projects
>>>> should have equal chances, but keep in mind that (1) projects should not
>>>> really "compete" against each other (but rather all projects should
>>>> contribute to the success of OpenStack as a whole) and (2) some
>>>> OpenStack projects will always be more equal than others (for example we
>>>> require that every project integrates with Keystone, and I don't see
>>>> that changing).
>>>
>>> Yes, I agree we should not be competing. But was should not be asking
>>> the smaller projects to re-implement functionality, just because they
>>> did not get integrated in time.
>>>
>>> We require all projects to integrate with keystone for auth, as we
>>> require all projects to integrate with neutron for network operations
>>> and designate for DNS, I just see it as a requirement for using the
>>> other components of OpenStack for their defined purpose.
>>>
>>
>> It would be useful to have some specific information from the QA/Tempest
>> team (and any others with a similar situation) about whether the current
>> situation about how differences between in-tree tests and plugin tests
>> are allowed to use various APIs. For example, are there APIs only
>> available to in-tree tests that are going to stay that way? Or is this
>> just a matter of not having had time to "harden" or "certify" or
>> otherwise prepare those APIs for plugins to use them?
>
> "Staying that way" is certainly the impression given to users from
> other projects.
>
> In any case tempest is just an example. From my viewpoint, we need to
> make this a community default, to avoid even the short (which really
> ends up a long) term discrepancy between projects.
>
> If the standard in the community is equal access, this means when the
> next testing tool, CLI, SDK, $cross_project_tool comes along, it is
> available to all projects equally.
>
> If everyone uses the interfaces, they get better for all users of them,
> "big tent projects" and "tc-approved-release" alike. Having two
> way of doing the same thing means that there will always be
> discrepancies between people who are in the club, and those who are not.
>
> - Graham
>
>> Doug
>>
>> __________________________________________________________________________
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160719/6b63071a/attachment.pgp>