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