Open Stack

On 09/07/15 04:39, Zane Bitter wrote:
> 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?
>
For devstack and these other projects Zane has mentioned it would be 
ideal to come up with a common convention for tags which designate that 
another project has implemented that capability. And there would be some 
value in distinguishing between in-tree and plugin support, since it has 
deployment implications.

So as a starter, I'd like to suggest:
devstack:in-tree
devstack:plugin
heat:in-tree
heat:plugin
horizon:in-tree
horizon:plugin
openstackclient:in-tree
openstackclient:plugin
...etc

I'm not sure if this would apply to ceilometer since I assume the 
capability is always implemented in the project tree, so that tag could 
be something like ceilometer:publishes-metrics.

These project-namespaced tags would all imply that it is up to the PTL 
of the respective projects to come up with the process for proposing 
these tags, and the TC has final approval.


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