Re: [openstack-dev] [tc][all] Plugins for all

[Steve Martinelli]

On Fri, Jul 22, 2016 at 2:08 PM, Hayes, Graham  wrote:

>   * OpenStack Client
>
> OpenStack CLI privileged projects have access to more commands, as
> plugins cannot hook in to them (e.g. quotas)
>

It's been OSC's intention to allow for command hooking, we just don't
really know how to do that just yet :\


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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 21/07/2016 16:49, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-19 16:59:20 +:
>> On 19/07/2016 16:39, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
 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.
>
> OK, but is that an "impression" or is it a stated "policy"?
>
>> 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.
>
> Before we start making lots of specific rules about how teams
> coordinate, I would like to understand the problem those rules are meant
> to solve, so thank you for providing that example. I still haven't heard
> from the QA team, though. Ken'ichi?
>
>> 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.
>
> I think I understand your motivation. It's not clear yet whether
> there needs to be a new policy to change the existing intent,
> or if a discussion just hasn't happened, or if someone simply needs
> to edit some code.
>
> Are there other examples we can talk about in the mean time?

Sure.

  * Horizon

Horizon privileged projects have access to much more panels than
plugins (service status, quotas, overviews etc).
Plugins have to rely on tarballs of horizon

  * OpenStack Client

OpenStack CLI privileged projects have access to more commands, as
plugins cannot hook in to them (e.g. quotas)

  * Grenade

Plugins may or may not have tempest tests ran (I think that patch
merged), they have to use parts of tempest I was told explicitly
plugins should not use to get the tests to run at that point.

  * Docs

We can now add install guides and hook into the API Reference, and API
guides. This is great - and I am really happy about 

Re: [openstack-dev] [tc][all] Plugins for all

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-07-19 16:59:20 +:
> On 19/07/2016 16:39, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
> >> 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.

OK, but is that an "impression" or is it a stated "policy"?

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

Before we start making lots of specific rules about how teams
coordinate, I would like to understand the problem those rules are meant
to solve, so thank you for providing that example. I still haven't heard
from the QA team, though. Ken'ichi?

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

I think I understand your motivation. It's not clear yet whether
there needs to be a new policy to change the existing intent,
or if a discussion just hasn't happened, or if someone simply needs
to edit some code.

Are there other examples we can talk about in the mean time?

Doug

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

Re: [openstack-dev] [tc][all] Plugins for all

[Doug Hellmann]

Excerpts from Doug Wiegley's message of 2016-07-19 13:58:59 -0600:
> 
> > On Jul 19, 2016, at 9:36 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
> >> 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?
> 
> Doug, one example that I’m aware of — I’ve suggested moving neutron entirely 
> out of devstack and into the neutron repo, via the devstack plugin interface. 
> This was rejected, and the counter-argument given was that the folks that 
> maintain the integrated gate, which happen to be many of the same folks 
> maintaining devstack and the like, want to retain control of the items that 
> can break the integrated gate, and that it gets too hard to track down 
> individual project folks when the world is burning.
> 
> I don’t personally agree with the decision, but I can see some merit in that 
> argument.

Yes, this is one of the outcomes of being in a situation where other
projects require something as a dependency -- each side loses a little
control, and some centralization happens to ensure that we can maintain
the flow of work for OpenStack as a whole.

Doug

> 
> Thanks,
> doug
> 
> > 
> > Doug
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Sean Dague]

On 07/18/2016 06:49 AM, Dmitry Tantsur wrote:

On 07/17/2016 11:04 PM, Jay Pipes wrote:

On 07/14/2016 12:21 PM, Hayes, Graham wrote:

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas.


There *is* no standard CLI or UI for setting quotas.


They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.


This has nothing to do with the big tent and everything to do with the
fact that the community at large has conflated quotas -- i.e. the limit
of a particular class of resource that a user or tenant can consume --
with the usage of a particular class of resource. The two things are not
the same nor do they need to be handled by the same service, IMHO.

I've proposed before that quotas -- i.e. the *limits* for different
resource classes that a consumer of those resources has -- be handled by
the Keystone API. This is the endpoint that I personally think makes the
most sense to house this information.

Usage information is necessarily the domain of the individual service
projects who must control allocation/consumption of resources under
their control. It would be *helpful* to have a set of best-practice
guidelines for projects to follow in safely accounting for consumption
of resources, but "the big tent" has nothing to do with our community
failing to do this. We've failed to do this from the beginning of
OpenStack, well before the big tent was just a spark in the minds of the
TC.


Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface.


What "resources" are you referring to above? What is the "unstable
interface" you are referring to? Tempest should only ever be validating
public REST APIs.


Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.


An example here would be super-useful, since as mentioned above, Tempest
should only be validating public HTTP/REST APIs.


Not entirely related example, but still in support of the original point
(IMO): grenade currently does not catch smoke tests coming from tempest
plugins when running after upgrade. It's just one missing call [1], and
it probably would not go unnoticed if Nova tests did not run ;)

[1] https://review.openstack.org/337372


The patch is merged.

Also... missing tests have gone missing for long times on all kinds of 
projects, including nova / neutron. Missing tests require people keeping 
an eye on things, because they don't fail when they disappear.


-Sean

--
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tc][all] Plugins for all

[Doug Wiegley]

> On Jul 19, 2016, at 9:36 AM, Doug Hellmann  wrote:
> 
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> 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?

Doug, one example that I’m aware of — I’ve suggested moving neutron entirely 
out of devstack and into the neutron repo, via the devstack plugin interface. 
This was rejected, and the counter-argument given was that the folks that 
maintain the integrated gate, which happen to be many of the same folks 
maintaining devstack and the like, want to retain control of the items that can 
break the integrated gate, and that it gets too hard to track down individual 
project folks when the world is burning.

I don’t personally agree with the decision, but I can see some merit in that 
argument.

Thanks,
doug


> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[John Dickinson]

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 +:
>>> 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-requ...@lists.openstack.org?subject:unsubscribe
>> 

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 19/07/2016 16:39, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
> 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?

Doug

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

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.




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

Re: [openstack-dev] [tc][all] Plugins for all

[Thierry Carrez]

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.


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.


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


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc][all] Plugins for all

[Dmitry Tantsur]

On 07/17/2016 11:04 PM, Jay Pipes wrote:

On 07/14/2016 12:21 PM, Hayes, Graham wrote:

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas.


There *is* no standard CLI or UI for setting quotas.


They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.


This has nothing to do with the big tent and everything to do with the
fact that the community at large has conflated quotas -- i.e. the limit
of a particular class of resource that a user or tenant can consume --
with the usage of a particular class of resource. The two things are not
the same nor do they need to be handled by the same service, IMHO.

I've proposed before that quotas -- i.e. the *limits* for different
resource classes that a consumer of those resources has -- be handled by
the Keystone API. This is the endpoint that I personally think makes the
most sense to house this information.

Usage information is necessarily the domain of the individual service
projects who must control allocation/consumption of resources under
their control. It would be *helpful* to have a set of best-practice
guidelines for projects to follow in safely accounting for consumption
of resources, but "the big tent" has nothing to do with our community
failing to do this. We've failed to do this from the beginning of
OpenStack, well before the big tent was just a spark in the minds of the
TC.


Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface.


What "resources" are you referring to above? What is the "unstable
interface" you are referring to? Tempest should only ever be validating
public REST APIs.


Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.


An example here would be super-useful, since as mentioned above, Tempest
should only be validating public HTTP/REST APIs.


Not entirely related example, but still in support of the original point 
(IMO): grenade currently does not catch smoke tests coming from tempest 
plugins when running after upgrade. It's just one missing call [1], and 
it probably would not go unnoticed if Nova tests did not run ;)


[1] https://review.openstack.org/337372




None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.


I guess I don't understand what you are referring to as a "plugin"
above. Are you referring to devstack libXXX things? Or are you referring
to *drivers* for things like the hypervisor in Nova or the ML2 mech
drivers in Neutron? Or something else entirely?

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 17/07/2016 22:08, Jay Pipes wrote:
> On 07/14/2016 12:21 PM, Hayes, Graham wrote:
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas.
>
> There *is* no standard CLI or UI for setting quotas.

Well if you are nova, neutron or cinder there is.

http://docs.openstack.org/admin-guide/cli_set_quotas.html
http://docs.openstack.org/admin-guide/dashboard_set_quotas.html


>  > They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> This has nothing to do with the big tent and everything to do with the
> fact that the community at large has conflated quotas -- i.e. the limit
> of a particular class of resource that a user or tenant can consume --
> with the usage of a particular class of resource. The two things are not
> the same nor do they need to be handled by the same service, IMHO.
>
> I've proposed before that quotas -- i.e. the *limits* for different
> resource classes that a consumer of those resources has -- be handled by
> the Keystone API. This is the endpoint that I personally think makes the
> most sense to house this information.

As have I, but the reality is that *currently* limits are set by quotas.

(As a side note, keystone is the only place that this makes any sense,
but we needed quotas a few years ago, and we had to do what everyone
else had done at the time)

> Usage information is necessarily the domain of the individual service
> projects who must control allocation/consumption of resources under
> their control. It would be *helpful* to have a set of best-practice
> guidelines for projects to follow in safely accounting for consumption
> of resources, but "the big tent" has nothing to do with our community
> failing to do this. We've failed to do this from the beginning of
> OpenStack, well before the big tent was just a spark in the minds of the TC.
>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface.
>
> What "resources" are you referring to above? What is the "unstable
> interface" you are referring to? Tempest should only ever be validating
> public REST APIs.

The resources in tempest - thinks like setting up users / projects for
running the tests, cleaning up resources post testing, checking if
services are enabled / disabled in the cloud being tested, tagging tests
(smoke, slow, etc)

The are all used by projects using tempest for testing, and all of the
above are only available to projects not using the plugin interface
(the in tree tempest tests, in the openstack/tempest repository)

>> Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> An example here would be super-useful, since as mentioned above, Tempest
> should only be validating public HTTP/REST APIs.
>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>
> I guess I don't understand what you are referring to as a "plugin"
> above. Are you referring to devstack libXXX things? Or are you referring
> to *drivers* for things like the hypervisor in Nova or the ML2 mech
> drivers in Neutron? Or something else entirely?
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 18/07/2016 01:59, Matt Riedemann wrote:
> On 7/17/2016 4:13 PM, Jay Pipes wrote:
>> On 07/15/2016 08:36 AM, Hayes, Graham wrote:
>>> On 14/07/2016 21:20, Matt Riedemann wrote:
 And does this also include plugins within projects, like storage
 backends in cinder and hypervisor drivers in nova?
>>>
>>> This is aimed at cross project interaction. So, if there is a project in
>>> projects.yaml that is a backend, or a hypervisor driver, it should.
>>>
>>> However, in the proposal, there is a choice that projects can make -
>>> all in tree, or all plugins. The point of the proposal is equality of
>>> access for the community.
>>>
>>> What would that mean in practice for Nova? Nothing would really change
>>> - they have decided to do in tree.
>>>
>>> 99% of deliverables tagged type:service will have no impact from this,
>>> the change will be in projects that are used by  teams across the
>>> community (CLI, Docs, UI etc), and provide a way for these projects
>>> to integrate with them.
>>>
>>> These integration points should be the same for *all* projects.
>>
>> What integration points exactly are you referring to? Can you provide a
>> specific example that Designate has run into issues with?
>>
 Nova has been pushing for a few releases now on getting rid of plug
 points since they are barriers to interoperability.
>>>
>>> Well, nova's plugins were barriers to interoperability, for other
>>> projects they are the only mechanism for interoperability.
>>
>> Perhaps there is some terminology problem here, but plugins absolutely
>> do NOT enable interoperability between clouds. They are the antithesis
>> of interoperability points.
>>
>> The REST APIs (and for projects that support it, the versioned
>> notifications payloads) should be the *only* interoperability and
>> integration points that projects should rely on.
>>
>> Best,
>> -jay
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I think I'm getting the point. Rather than devstack, tempest,
> openstack-manuals and horizon have stuff baked in for certain projects,
> e.g. nova, cinder, keystone, neutron, etc, every project has to plug in
> the same way, which would force all projects to experience any pain
> associated with dealing with plugging into those projects - and help
> drive making the plugin API better for everyone.
>

That is it - put much more concisely than I managed to.


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

Re: [openstack-dev] [tc][all] Plugins for all

[Matt Riedemann]

On 7/17/2016 4:13 PM, Jay Pipes wrote:

On 07/15/2016 08:36 AM, Hayes, Graham wrote:

On 14/07/2016 21:20, Matt Riedemann wrote:

And does this also include plugins within projects, like storage
backends in cinder and hypervisor drivers in nova?


This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.


What integration points exactly are you referring to? Can you provide a
specific example that Designate has run into issues with?


Nova has been pushing for a few releases now on getting rid of plug
points since they are barriers to interoperability.


Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.


Perhaps there is some terminology problem here, but plugins absolutely
do NOT enable interoperability between clouds. They are the antithesis
of interoperability points.

The REST APIs (and for projects that support it, the versioned
notifications payloads) should be the *only* interoperability and
integration points that projects should rely on.

Best,
-jay

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



I think I'm getting the point. Rather than devstack, tempest, 
openstack-manuals and horizon have stuff baked in for certain projects, 
e.g. nova, cinder, keystone, neutron, etc, every project has to plug in 
the same way, which would force all projects to experience any pain 
associated with dealing with plugging into those projects - and help 
drive making the plugin API better for everyone.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [tc][all] Plugins for all

[Jay Pipes]

On 07/15/2016 08:36 AM, Hayes, Graham wrote:

On 14/07/2016 21:20, Matt Riedemann wrote:

And does this also include plugins within projects, like storage
backends in cinder and hypervisor drivers in nova?


This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.


What integration points exactly are you referring to? Can you provide a 
specific example that Designate has run into issues with?



Nova has been pushing for a few releases now on getting rid of plug
points since they are barriers to interoperability.


Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.


Perhaps there is some terminology problem here, but plugins absolutely 
do NOT enable interoperability between clouds. They are the antithesis 
of interoperability points.


The REST APIs (and for projects that support it, the versioned 
notifications payloads) should be the *only* interoperability and 
integration points that projects should rely on.


Best,
-jay

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

Re: [openstack-dev] [tc][all] Plugins for all

[Jay Pipes]

On 07/14/2016 12:21 PM, Hayes, Graham wrote:

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas.


There *is* no standard CLI or UI for setting quotas.

> They can be done as either extra commands

(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.


This has nothing to do with the big tent and everything to do with the 
fact that the community at large has conflated quotas -- i.e. the limit 
of a particular class of resource that a user or tenant can consume -- 
with the usage of a particular class of resource. The two things are not 
the same nor do they need to be handled by the same service, IMHO.


I've proposed before that quotas -- i.e. the *limits* for different 
resource classes that a consumer of those resources has -- be handled by 
the Keystone API. This is the endpoint that I personally think makes the 
most sense to house this information.


Usage information is necessarily the domain of the individual service 
projects who must control allocation/consumption of resources under 
their control. It would be *helpful* to have a set of best-practice 
guidelines for projects to follow in safely accounting for consumption 
of resources, but "the big tent" has nothing to do with our community 
failing to do this. We've failed to do this from the beginning of 
OpenStack, well before the big tent was just a spark in the minds of the TC.



Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface.


What "resources" are you referring to above? What is the "unstable 
interface" you are referring to? Tempest should only ever be validating 
public REST APIs.



Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.


An example here would be super-useful, since as mentioned above, Tempest 
should only be validating public HTTP/REST APIs.



None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.


I guess I don't understand what you are referring to as a "plugin" 
above. Are you referring to devstack libXXX things? Or are you referring 
to *drivers* for things like the hypervisor in Nova or the ML2 mech 
drivers in Neutron? Or something else entirely?


Best,
-jay

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 18:24, Luigi Toscano wrote:
> On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:52, Luigi Toscano wrote:
>>> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
 On 15/07/2016 17:10, Andrew Laski wrote:
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

 When we have asked previously, we have been told that certain parts
 of tempest "are not really meant for plugins".

 The main part that is used that is not part of the tempest stable
 interface is the base test class.

 This is the bit that sets up credentials, clients, and other useful
 things.

 There is a base test class in the tempest lib - but it is very sparse -
 meaning any project using it would have to re-invent creating users,
 resources, and clients.

 https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
 vs
 https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>>>
>>> This is a known situation, but it is being addressed right now. It's not
>>> like no one wants to have a stable Tempest interface, but it had to be
>>> cleanly built.
>>> There is a spec and work in progress to make the client manager interface
>>> stable:
>>>
>>> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager
>>> -refactor.html
>>>
>>> So yes, almost existing plugins are using unstable interfaces right now,
>>> but again this is not meant to be the long term scenario.
>>>
>>> Ciao
>>
>> Yeap - I have seen the spec.
>>
>> My point is that if all projects had to use the same plugin interface,
>> this would not be a problem.
>
> Could you please clarify: do you advocate for a generic plugin interface for
> every project, or that each project should expose a plugin interface that
> allows plugin to behave as in-tree components? Because the latter is what
> happens with Tempest, and I see the former a bit complicated.

For every project that has cross project interaction - tempest is a good 
example.

For these projects, they should allow all projects in tree (like Nova, 
Neutron, Cinder etc are today), or they should have a plugin interface 
(like they currently do), but all projects *must* use it, and not use
parts of tempest that are not exposed in that interface.

This would mean that tempest would move the nova, neutron, etc tests to
use the plugin interface.

Now, that plugin could be kept in the tempest repo, and still maintained
by the QA team, but should use the same interface as the other plugins
that are not in that repository.

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.

>>
>> If we have this as our default position as the community continues to
>> build more and more things like tempest, OSC, devstack, grenade we
>> should build it so there is not a discrepancy between projects.
>>
>> The root cause is not being addressed, as features can still land in
>> tempest, but not tempest.lib, and then can only be used by the projects
>> that tempest keeps as built in.
>
>
> I think I disagree here. The root cause is being addressed: external tests can
> use the Tempest plugin interface, and use the API, which is being stabilized.
> The fact that the Tempest API is partially unstable is a temporary things, due
> to the origin of the project and the way the scope was redefined, but again
> it's temporary.
>

But the situation could very easily re-occur. If there is a new feature
that is added to tempest, but not tempest.lib plugins will have a choice
of re implementing it, or relying on an unstable interface.


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

Re: [openstack-dev] [tc][all] Plugins for all

[Luigi Toscano]

On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote:
> On 15/07/2016 17:52, Luigi Toscano wrote:
> > On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
> >> On 15/07/2016 17:10, Andrew Laski wrote:
>  Tempest plugins are another example. Approximately 30 of the 36
>  current plugins are using resources that are not supposed to be
>  used, and are an unstable interface. Projects in tree in tempest
>  are at a much better position, as any change to the internal
>  API will have to be fixed before the gate merges, but other
>  out of tree plugins are in a place where they can be broken at any
>  point.
> >>> 
> >>> Has there been an attempt to elevate these internal interfaces into
> >>> stable and publicly consumable interfaces? Was there resistance to such
> >>> an effort?
> >> 
> >> When we have asked previously, we have been told that certain parts
> >> of tempest "are not really meant for plugins".
> >> 
> >> The main part that is used that is not part of the tempest stable
> >> interface is the base test class.
> >> 
> >> This is the bit that sets up credentials, clients, and other useful
> >> things.
> >> 
> >> There is a base test class in the tempest lib - but it is very sparse -
> >> meaning any project using it would have to re-invent creating users,
> >> resources, and clients.
> >> 
> >> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
> >> vs
> >> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
> > 
> > This is a known situation, but it is being addressed right now. It's not
> > like no one wants to have a stable Tempest interface, but it had to be
> > cleanly built.
> > There is a spec and work in progress to make the client manager interface
> > stable:
> > 
> > http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager
> > -refactor.html
> > 
> > So yes, almost existing plugins are using unstable interfaces right now,
> > but again this is not meant to be the long term scenario.
> > 
> > Ciao
> 
> Yeap - I have seen the spec.
> 
> My point is that if all projects had to use the same plugin interface,
> this would not be a problem.

Could you please clarify: do you advocate for a generic plugin interface for 
every project, or that each project should expose a plugin interface that 
allows plugin to behave as in-tree components? Because the latter is what 
happens with Tempest, and I see the former a bit complicated.

> 
> If we have this as our default position as the community continues to
> build more and more things like tempest, OSC, devstack, grenade we
> should build it so there is not a discrepancy between projects.
> 
> The root cause is not being addressed, as features can still land in
> tempest, but not tempest.lib, and then can only be used by the projects
> that tempest keeps as built in.


I think I disagree here. The root cause is being addressed: external tests can 
use the Tempest plugin interface, and use the API, which is being stabilized. 
The fact that the Tempest API is partially unstable is a temporary things, due 
to the origin of the project and the way the scope was redefined, but again 
it's temporary.

-- 
Luigi

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:52, Luigi Toscano wrote:
> On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
>> On 15/07/2016 17:10, Andrew Laski wrote:
>
 Tempest plugins are another example. Approximately 30 of the 36
 current plugins are using resources that are not supposed to be
 used, and are an unstable interface. Projects in tree in tempest
 are at a much better position, as any change to the internal
 API will have to be fixed before the gate merges, but other
 out of tree plugins are in a place where they can be broken at any
 point.
>>>
>>> Has there been an attempt to elevate these internal interfaces into
>>> stable and publicly consumable interfaces? Was there resistance to such
>>> an effort?
>>
>> When we have asked previously, we have been told that certain parts
>> of tempest "are not really meant for plugins".
>>
>> The main part that is used that is not part of the tempest stable
>> interface is the base test class.
>>
>> This is the bit that sets up credentials, clients, and other useful
>> things.
>>
>> There is a base test class in the tempest lib - but it is very sparse -
>> meaning any project using it would have to re-invent creating users,
>> resources, and clients.
>>
>> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
>> vs
>> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22
>
>
> This is a known situation, but it is being addressed right now. It's not like
> no one wants to have a stable Tempest interface, but it had to be cleanly
> built.
> There is a spec and work in progress to make the client manager interface
> stable:
>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html
>
> So yes, almost existing plugins are using unstable interfaces right now, but
> again this is not meant to be the long term scenario.
>
> Ciao
>

Yeap - I have seen the spec.

My point is that if all projects had to use the same plugin interface,
this would not be a problem.

If we have this as our default position as the community continues to
build more and more things like tempest, OSC, devstack, grenade we
should build it so there is not a discrepancy between projects.

The root cause is not being addressed, as features can still land in
tempest, but not tempest.lib, and then can only be used by the projects
that tempest keeps as built in.

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

Re: [openstack-dev] [tc][all] Plugins for all

[Luigi Toscano]

On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote:
> On 15/07/2016 17:10, Andrew Laski wrote:

> >> Tempest plugins are another example. Approximately 30 of the 36
> >> current plugins are using resources that are not supposed to be
> >> used, and are an unstable interface. Projects in tree in tempest
> >> are at a much better position, as any change to the internal
> >> API will have to be fixed before the gate merges, but other
> >> out of tree plugins are in a place where they can be broken at any
> >> point.
> > 
> > Has there been an attempt to elevate these internal interfaces into
> > stable and publicly consumable interfaces? Was there resistance to such
> > an effort?
> 
> When we have asked previously, we have been told that certain parts
> of tempest "are not really meant for plugins".
> 
> The main part that is used that is not part of the tempest stable
> interface is the base test class.
> 
> This is the bit that sets up credentials, clients, and other useful
> things.
> 
> There is a base test class in the tempest lib - but it is very sparse -
> meaning any project using it would have to re-invent creating users,
> resources, and clients.
> 
> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
> vs
> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22


This is a known situation, but it is being addressed right now. It's not like 
no one wants to have a stable Tempest interface, but it had to be cleanly 
built.
There is a spec and work in progress to make the client manager interface 
stable:

http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager-refactor.html

So yes, almost existing plugins are using unstable interfaces right now, but 
again this is not meant to be the long term scenario.

Ciao
-- 
Luigi

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 15/07/2016 17:10, Andrew Laski wrote:
>
>
> On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>
> Which internal APIs are you referring to here? Are you limiting this to
> internal APIs within Tempest/Devstack that projects can use for
> testing/deployment, or are you referring to things like the nova-compute
> service which has an internal RPC API?

Any APIs that are used by other projects. So, an RPC API will probably
be out of scope.

> I feel like I'm missing some context when reading this email because
> there are a lot of references to plugins with no clear definition, that
> I can see, of what exactly you mean by that.

It is for any project that has cross project code. If a project has
ways for other projects to hook in, this interface should be the same.

This means that a project cannot say the Nova can have code that calls
internal code but Glance has to use a plugin that only has access to
certain calls.

>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>
> Can you provide more clarity on how "openstack dns quota set --foo bar"
> differs from setting a quota on Nova/Neutron/Cinder?

Sure - nearly all other quotas are set either in the "admin" -> "quotas" 
panel in Horizon (which plugins cannot add their quotas
there.

For the cli - quotas are set as `openstack quota set --instances 10`

I realise it is a small difference, but each of these makes it more
complex for end users, and means that Designate had to re-invent the
quotas command, and keep it in their plugin.

>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>
> Has there been an attempt to elevate these internal interfaces into
> stable and publicly consumable interfaces? Was there resistance to such
> an effort?

When we have asked previously, we have been told that certain parts
of tempest "are not really meant for plugins".

The main part that is used that is not part of the tempest stable
interface is the base test class.

This is the bit that sets up credentials, clients, and other useful
things.

There is a base test class in the tempest lib - but it is very sparse -
meaning any project using it would have to re-invent creating users,
resources, and clients.

https://github.com/openstack/tempest/blob/master/tempest/test.py#L203
vs
https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22

>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start 

Re: [openstack-dev] [tc][all] Plugins for all

[Andrew Laski]

On Thu, Jul 14, 2016, at 03:21 PM, Hayes, Graham wrote:
> I just proposed a review to openstack/governance repo [0] that aims
> to have everything across OpenStack be plugin based for all cross
> project interaction, or allow all projects access to the same internal
> APIs and I wanted to give a bit of background on my motivation, and how
> it came about.

Which internal APIs are you referring to here? Are you limiting this to
internal APIs within Tempest/Devstack that projects can use for
testing/deployment, or are you referring to things like the nova-compute
service which has an internal RPC API?

I feel like I'm missing some context when reading this email because
there are a lot of references to plugins with no clear definition, that
I can see, of what exactly you mean by that.

> 
> Coming from a smaller project, I can see issues for new projects,
> smaller projects, and projects that may not be seen as "important".
> 
> As a smaller project trying to fit into cross project initiatives,
> (and yes, make sure our software looks at least OK in the
> Project Navigator) the process can be difficult.
> 
> A lot of projects / repositories have plugin interfaces, but also
> have project integrations in tree, that do not follow the plugin
> interface. This makes it difficult to see what a plugin can, and
> should do.
> 
> When we moved to the big tent, we wanted as a community to move to
> a flatter model, removing the old integrated status.
> 
> Unfortunately we still have areas when some projects are more equal -
> there is a lingering set of projects who were integrated at the point
> in time that we moved, and have preferential status.
> 
> A lot of the effects are hard to see, and are not insurmountable, but
> do cause projects to re-invent the wheel.
> 
> For example, quotas - there is no way for a project that is not nova, 
> neutron, cinder to hook into the standard CLI, or UI for setting
> quotas. They can be done as either extra commands
> (openstack dns quota set --foo bar) or as custom panels, but not
> the way other quotas get set.

Can you provide more clarity on how "openstack dns quota set --foo bar"
differs from setting a quota on Nova/Neutron/Cinder?

> 
> Tempest plugins are another example. Approximately 30 of the 36
> current plugins are using resources that are not supposed to be
> used, and are an unstable interface. Projects in tree in tempest
> are at a much better position, as any change to the internal
> API will have to be fixed before the gate merges, but other
> out of tree plugins are in a place where they can be broken at any
> point.

Has there been an attempt to elevate these internal interfaces into
stable and publicly consumable interfaces? Was there resistance to such
an effort?

> 
> None of this is meant to single out projects, or teams. A lot
> of the projects that are in this situation have inordinate amounts of
> work placed on them by the big-tent, and I can emphasize with why things 
> are this way. These were the examples that currently stick out
> in my mind, and I think we have come to a point where we need to make
> a change as a community.
> 
> By moving to a "plugins for all" model, these issues are reduced.
> It undoubtedly will cause more, but it is closer to our goal
> of Recognizing all our community is part of OpenStack, and
> differentiate projects by tags.
> 
> This won't be a change that happens tomorrow, next week, or even next
> cycle, but think as a goal, we should start moving in this direction
> as soon as we can, and start building momentum.

Is this just a matter of nobody is doing this work, or are there claims
that some projects are special and should have access that other
projects do not?

> 
> Thanks,
> 
> Graham
> 
> 0 - https://review.openstack.org/342366
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 14/07/2016 21:20, Matt Riedemann wrote:
> On 7/14/2016 2:21 PM, Hayes, Graham wrote:
>> I just proposed a review to openstack/governance repo [0] that aims
>> to have everything across OpenStack be plugin based for all cross
>> project interaction, or allow all projects access to the same internal
>> APIs and I wanted to give a bit of background on my motivation, and how
>> it came about.
>>
>> Coming from a smaller project, I can see issues for new projects,
>> smaller projects, and projects that may not be seen as "important".
>>
>> As a smaller project trying to fit into cross project initiatives,
>> (and yes, make sure our software looks at least OK in the
>> Project Navigator) the process can be difficult.
>>
>> A lot of projects / repositories have plugin interfaces, but also
>> have project integrations in tree, that do not follow the plugin
>> interface. This makes it difficult to see what a plugin can, and
>> should do.
>>
>> When we moved to the big tent, we wanted as a community to move to
>> a flatter model, removing the old integrated status.
>>
>> Unfortunately we still have areas when some projects are more equal -
>> there is a lingering set of projects who were integrated at the point
>> in time that we moved, and have preferential status.
>>
>> A lot of the effects are hard to see, and are not insurmountable, but
>> do cause projects to re-invent the wheel.
>>
>> For example, quotas - there is no way for a project that is not nova,
>> neutron, cinder to hook into the standard CLI, or UI for setting
>> quotas. They can be done as either extra commands
>> (openstack dns quota set --foo bar) or as custom panels, but not
>> the way other quotas get set.
>>
>> Tempest plugins are another example. Approximately 30 of the 36
>> current plugins are using resources that are not supposed to be
>> used, and are an unstable interface. Projects in tree in tempest
>> are at a much better position, as any change to the internal
>> API will have to be fixed before the gate merges, but other
>> out of tree plugins are in a place where they can be broken at any
>> point.
>>
>> None of this is meant to single out projects, or teams. A lot
>> of the projects that are in this situation have inordinate amounts of
>> work placed on them by the big-tent, and I can emphasize with why things
>> are this way. These were the examples that currently stick out
>> in my mind, and I think we have come to a point where we need to make
>> a change as a community.
>>
>> By moving to a "plugins for all" model, these issues are reduced.
>> It undoubtedly will cause more, but it is closer to our goal
>> of Recognizing all our community is part of OpenStack, and
>> differentiate projects by tags.
>>
>> This won't be a change that happens tomorrow, next week, or even next
>> cycle, but think as a goal, we should start moving in this direction
>> as soon as we can, and start building momentum.
>>
>> Thanks,
>>
>> Graham
>>
>> 0 - https://review.openstack.org/342366
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Just for my own understanding, are you suggesting that something like
> nova, cinder or neutron become optional for an openstack cloud?

Not in this proposal. (but that is an interesting idea we should follow
up on at a later date)

> And does this also include plugins within projects, like storage
> backends in cinder and hypervisor drivers in nova?

This is aimed at cross project interaction. So, if there is a project in
projects.yaml that is a backend, or a hypervisor driver, it should.

However, in the proposal, there is a choice that projects can make -
all in tree, or all plugins. The point of the proposal is equality of
access for the community.

What would that mean in practice for Nova? Nothing would really change
- they have decided to do in tree.

99% of deliverables tagged type:service will have no impact from this,
the change will be in projects that are used by  teams across the
community (CLI, Docs, UI etc), and provide a way for these projects
to integrate with them.

These integration points should be the same for *all* projects.

> Nova has been pushing for a few releases now on getting rid of plug
> points since they are barriers to interoperability.

Well, nova's plugins were barriers to interoperability, for other
projects they are the only mechanism for interoperability.


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

Re: [openstack-dev] [tc][all] Plugins for all

[Matt Riedemann]

On 7/14/2016 2:21 PM, Hayes, Graham wrote:

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova,
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

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



Just for my own understanding, are you suggesting that something like 
nova, cinder or neutron become optional for an openstack cloud?


And does this also include plugins within projects, like storage 
backends in cinder and hypervisor drivers in nova?


Nova has been pushing for a few releases now on getting rid of plug 
points since they are barriers to interoperability.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

I just proposed a review to openstack/governance repo [0] that aims
to have everything across OpenStack be plugin based for all cross
project interaction, or allow all projects access to the same internal
APIs and I wanted to give a bit of background on my motivation, and how
it came about.

Coming from a smaller project, I can see issues for new projects,
smaller projects, and projects that may not be seen as "important".

As a smaller project trying to fit into cross project initiatives,
(and yes, make sure our software looks at least OK in the
Project Navigator) the process can be difficult.

A lot of projects / repositories have plugin interfaces, but also
have project integrations in tree, that do not follow the plugin
interface. This makes it difficult to see what a plugin can, and
should do.

When we moved to the big tent, we wanted as a community to move to
a flatter model, removing the old integrated status.

Unfortunately we still have areas when some projects are more equal -
there is a lingering set of projects who were integrated at the point
in time that we moved, and have preferential status.

A lot of the effects are hard to see, and are not insurmountable, but
do cause projects to re-invent the wheel.

For example, quotas - there is no way for a project that is not nova, 
neutron, cinder to hook into the standard CLI, or UI for setting
quotas. They can be done as either extra commands
(openstack dns quota set --foo bar) or as custom panels, but not
the way other quotas get set.

Tempest plugins are another example. Approximately 30 of the 36
current plugins are using resources that are not supposed to be
used, and are an unstable interface. Projects in tree in tempest
are at a much better position, as any change to the internal
API will have to be fixed before the gate merges, but other
out of tree plugins are in a place where they can be broken at any
point.

None of this is meant to single out projects, or teams. A lot
of the projects that are in this situation have inordinate amounts of
work placed on them by the big-tent, and I can emphasize with why things 
are this way. These were the examples that currently stick out
in my mind, and I think we have come to a point where we need to make
a change as a community.

By moving to a "plugins for all" model, these issues are reduced.
It undoubtedly will cause more, but it is closer to our goal
of Recognizing all our community is part of OpenStack, and
differentiate projects by tags.

This won't be a change that happens tomorrow, next week, or even next
cycle, but think as a goal, we should start moving in this direction
as soon as we can, and start building momentum.

Thanks,

Graham

0 - https://review.openstack.org/342366

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