Open Stack

On 07/08/2015 06:12 PM, 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

+1 that seems pretty clear. When it comes to plugins we should make sure
that there is very specific documentation in the Tag description about
what it means to be a plugin, and how users enable them (which should be
a global process for each kind of thing).

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

So, honestly, it feels like application of these things should be pretty
automatic. In the devstack case, I could write a script to get the
answer, because devstack plugins require a very specific directory
structure in the project.

If every project has different instructions about how to add themselves
to horizon, that seems pretty anti user. If there is a framework in
Horizon that means all projects follow the same instructions when being
added, that is much better. And seems like could be basically scripted
for detection.

Mostly, I think the TC should hold off calling things plugins unless
they have a pretty strict contract, and enabling interface. Because if
we have those the difference between in-tree and plugin should be
minimal from a user perspective, which supports the model of a big tent.

(Note: I honestly don't know what the plugin interfaces look like for
all the rest of these things, so I'm completely conjecturing. Writing up
tag definitions that provide overview and pointers to them will be great
cross learning for our whole community.)

	-Sean

-- 
Sean Dague
http://dague.net