Open Stack

On 23 April 2015 at 09:14, Chris Dent <chdent at redhat.com> wrote:

>
> This might be a bit presumptuous, but why not give it a try...
>
> This cycle's TC elections didn't come with a set of prepackaged
> questions and though the self-nomination messages have included some
> very interesting stuff I think it would be useful to get answers
> from the candidates on at least one topical but open-ended
> question. Maybe other people have additional questions they think
> are important but this one is the one that matters to me and also
> captures the role that I wish the TC filled more strongly. Here's
> the preamble:
>
> There are lots of different ways to categorize the various
> stakeholders in the OpenStack community, no list is complete. For
> the sake of this question the people I'm concerned with are the
> developers, end-users and operators of OpenStack: the individuals
> who are actively involved with it on a daily basis. I'm intentionally
> leaving out things like "the downstream".
>
> There are many different ways to define "quality". For the sake of
> this question feel free to use whatever definition you like but take
> it as given that "quality" needs to be improved.
>
> Here's the question:
>
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?


I am possibly the latest candidate to respond to this thread...what a lousy
candidate that I am! :)

Without incurring the risk of becoming incredibly verbose, and trying to
keep this discussion down to earth, one thing I would like to see happen is
addressing the sort of quality that can be qualitatively measured on an
ongoing basis. For instance, to date we cannot tell at any given time (and
without support of downstream tools) whether certain key operations (like
VM boot) have degraded because of a specific change (if there is, as a
developer I'd be keen to learn how to take advantage of it, but that's
another discussion)!

For instance, when I was at VMware and in charge of 3rd party CI, I
designed a small mechanism to track the mobile average of test run times
that would tell a developer the impact of his/her change to the overall
performance of the system (single devstack). For instance, in change [1],
the VMware CI reported back 94.32% faster than the average run time. That
clearly meant that the change had no negative impact to the operations that
involved the VMware plugin for Neutron. Had that number been 150%, that
would have alerted a reviewer and triggered further analysis.

That number is obviously a coarse grained way of capturing quality, and may
have its own flaws but I found it incredibly useful and I would like to see
something along those lines be implemented in Zuul.

Anyhow, I hope you get the gist, should you want to know more, I guess
you'd have to vote for me :P

Cheers,
Armando

[1] https://review.openstack.org/#/c/80387/


>
>
> --
> Chris Dent tw:@anticdent freenode:cdent
> https://tank.peermore.com/tanks/cdent
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/18a50aa3/attachment.html>