Open Stack

On 08/07/15 18:12, Steve Baker wrote:
> 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

TBH I'd much rather get to a point where the distinction doesn't matter. 
Preferably one where every plugin is treated equally - i.e. for any 
given project, either all plugins are out-of-tree (I believe Horizon 
have talked about going down this path) or all plugins are in-tree 
(we've talked about doing this with Heat).

In the case of Heat for example, I think we'd only apply the tag to 
projects with in-tree plugins and we'd encourage anybody with 
out-of-tree plugins or appropriate /contrib plugins ('appropriate' here 
meaning that they're driving APIs that are part of OpenStack) to get 
them into the main tree so we could give them the tag.

cheers,
Zane.

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