Open Stack

On 08/07/15 09:03, Sean Dague wrote:
> Personally, I'm running out of steam on tags for this cycle, but Zane
> brought up a good point in the TC meeting yesterday, which was that "it
> would be nice to have tags for criteria that we used to use for
> integration requirements". I strongly agree with that perspective.
>
> A few ideas I was thinking about here from the areas that I poke at
> quite often. I'm doing this on the ML as a lighter weight discussion
> medium than gerrit as these are pretty raw brain droppings.
>
> Devstack:
>
>   * some tag that stated if it was in_devstack or has_devstack_plugin. I
> hesitate breaking those into 2, because it assumes value judgement that
> one is better than the other. However, has_devstack_plugin is useful
> information to know you need to add 1 line to your local.conf to enable
> that service.
>
> has_devstack_plugin has a very specific meaning that the project
> implements this interface -
> http://docs.openstack.org/developer/devstack/plugins.html

+1

Equivalents for Horizon & Heat were part of the 'First cycle 
expectations' list, and I believe would be helpful too. I'd also like to 
see one for python-openstackclient and another for the SDK. We could do 
something similar for other projects that use plugins too, like Mistral.

Ceilometer integration was also on the 'First cycle expectations' list, 
and would make a good tag. It also says "The lifecycle of resources 
managed by the project should be externalized via notifications so that 
they can be consumed by other integrated projects", but I'm not sure 
what that means... I assume those are the same notifications that 
Ceilometer reads? I guess it makes sense to have two tags - one for 
notifications being sent and one for Ceilometer knowing how to read them.

Who would be responsible for applying these tags? How about it happens 
by joint agreement of the project receiving the tag and the relevant tag 
owner (e.g. Devstack for has_devstack_plugin), as represented by their 
respective PTLs?

> QA:
>
>   * full_stack_testing - does the project have voting gate jobs that
> bring up an OpenStack environment with it and some other selection of
> OpenStack projects needed to test it. Basically, is the project doing
> more than unit testing. (Possibly also specify that tests run parallel,
> given that transition from serial to parallel testing has exposed real
> bugs in nearly every project that's done that).

+1

> Upgrade:
>
> There are various qualities about upgrade that we'd like to see out of
> projects, and highlight when they exist.
>
> * no config change upgrades - the config file for N-1 works with N
> * partial upgrades - N-1 and N components can exist simultaneously in a
> cluster (allows for rolling upgrades)
> * upgrade testing - changes are gated on a voting upgrade test
> * partial upgrade testing - changes are gated on a voting partial
> upgrade test

+1

> Most of these are pretty objective, I think there are also items around
> API contract, but that's actually a bit less objective, as we've seen
> around the debates on whether or not there is such a thing as a
> compatible API change with no user signaling in the microversion thread.

I think we need a stable-api-since tag, but we should leave it entirely 
in the hands of the project teams themselves to apply. That way it's up 
to the project to decide when it starts enforcing API stability, and we 
have a clear way to communicate to users when that happened. 
(Previously, integrated projects were required to have stable APIs and 
any project not in the integrated release could be presumed not to.)

Another possibility would be tags to indicate that a project uses 
oslo.config and oslo.log. (There may be other Oslo libraries that have a 
significant operator-facing interface impact, if anyone knows of any 
please list them.)

I believe if all of the ideas here were implemented that would give 
pretty good coverage of the non-woolly requirements in the 
incubation/graduation checklist that aren't already covered by tags or 
by the requirements to get into the OpenStack tent.

cheers,
Zane.