Open Stack

I'd like to announce my candidacy for the Technical Committee elections.


This last (Kilo) cycle I have been the PTL for Heat, but will not be for
Liberty.

Because of this, if I get elected to the TC, I can dedicate a significant
amount of time to TC duties.

I have an interest in projects that exist in the upper layers in OpenStack
(Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
slightly different viewpoint than the existing TC members (I hope this will
be complementary).


Topics that I am interested in pursuing:


1. How can the TC/PTL's better influence what developers work on?

We currently have working groups and project tags, but are there other ways
that we can encourage developers to work on global issues that users and
operators are asking for?

So if the TC came up with say 2 global "themes" every cycle, let's say
"ease of upgrades" and "scale", what can we use as a carrot to encourage a
developer to work on these topics rather than something else. Clearly this
has limits, but if the user survey is screaming "we need X", it would be
great to have a tool to help focus developers onto this.

One idea might be to use stackalytics main page to show the work done on TC
selected blueprints/bugs. We could tag particular blueprints/bugs and
highlight the developers that have worked on these (i.e. can we use
stackalytics as a tool to motivate developers to work on
TC supported "themes").

A note on this (some motivation for taking advantage of stackalytics):
It looks like this commit changed the default view on stackalytics from
commits to reviews
https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
(14 Apr 2014)
http://stackalytics.com/?release=all&metric=commits
http://stackalytics.com/?release=all

See the sudden plateau of commits and increase in reviews after that time
on the top graph (I am sure there are other factors at play too).


2. How can we better support new foundational projects that we expect other
projects to consume.

Under the new big tent model, we are welcoming more projects into the
openstack/ code namespace while simultaneously shifting the determination
of production-worthiness to distributors and operators. This poses a
problem for projects like Zaqar, Mistral, and even Heat, as these projects
may be consumed/used by other upper-layer projects. Consuming projects end
up with lots of conditional code as they must take into account that the
deployed cloud may not have these dependent projects installed.

How can we make the end user (and inter-project) experience richer and
friendlier with a consistent method of negotiating and discovering the
underlying features a deployed cloud offers?

Could tenant-based services/endpoints be helpful in allowing end users to
install optional projects?


3. Getting notification messages to the end user.

Based on this:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html

Other clouds provide better messaging feedback on what the infrastructure
is doing. We are really missing this and I'd like to help to get us to the
point where the user (that doesn't have access to the logs) can understand
what has happened to their resources.


I'm interested in either leading or participating in working groups from
within the TC to address these issues.


Thanks
Angus Salkeld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/b96096d1/attachment.html>