Open Stack

Angus,

Rally is designed as an operations tool. Its purpose is to run a production
cloud and give an operator tools and data to profile a production cloud. It
is intended as a first of many such tools.

There is a strong support in the community that operations tools should be
developed as part of OpenStack and Rally is the first such successful
community effort.

I can envision other tools building a community around them and they too
should become part of OpenStack operations tooling.  Maybe Operator Tools
program would be a better name?



Alex Freedland
Co-Founder
Mirantis, Inc.




On Thu, Jul 31, 2014 at 3:55 AM, Angus Salkeld <angus.salkeld at rackspace.com>
wrote:

> On Sun, 2014-07-27 at 07:57 -0700, Sean Dague wrote:
> > On 07/26/2014 05:51 PM, Hayes, Graham wrote:
> > > On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote:
> > >> On 07/22/2014 11:58 AM, David Kranz wrote:
> > >>> On 07/22/2014 10:44 AM, Sean Dague wrote:
> > >>>> Honestly, I'm really not sure I see this as a different program,
> but is
> > >>>> really something that should be folded into the QA program. I feel
> like
> > >>>> a top level effort like this is going to lead to a lot of
> duplication in
> > >>>> the data analysis that's currently going on, as well as
> functionality
> > >>>> for better load driver UX.
> > >>>>
> > >>>>  -Sean
> > >>> +1
> > >>> It will also lead to pointless discussions/arguments about which
> > >>> activities are part of "QA" and which are part of
> > >>> "Performance and Scalability Testing".
> > >
> > > I think that those discussions will still take place, it will just be
> on
> > > a per repository basis, instead of a per program one.
> > >
> > > [snip]
> > >
> > >>
> > >> Right, 100% agreed. Rally would remain with it's own repo + review
> team,
> > >> just like grenade.
> > >>
> > >>    -Sean
> > >>
> > >
> > > Is the concept of a separate review team not the point of a program?
> > >
> > > In the the thread from Designate's Incubation request Thierry said [1]:
> > >
> > >> "Programs" just let us bless goals and teams and let them organize
> > >> code however they want, with contribution to any code repo under that
> > >> umbrella being considered "official" and ATC-status-granting.
> > >
> > > I do think that this is something that needs to be clarified by the TC
> -
> > > Rally could not get a PTL if they were part of the QA project, but
> every
> > > time we get a program request, the same discussion happens.
> > >
> > > I think that mission statements can be edited to fit new programs as
> > > they occur, and that it is more important to let teams that have been
> > > working closely together to stay as a distinct group.
> >
> > My big concern here is that many of the things that these efforts have
> > been doing are things we actually want much closer to the base. For
> > instance, metrics on Tempest runs.
> >
> > When Rally was first created it had it's own load generator. It took a
> > ton of effort to keep the team from duplicating that and instead just
> > use some subset of Tempest. Then when measuring showed up, we actually
> > said that is something that would be great in Tempest, so whoever ran
> > it, be it for Testing, Monitoring, or Performance gathering, would have
> > access to that data. But the Rally team went off in a corner and did it
> > otherwise. That's caused the QA team to have to go and redo this work
> > from scratch with subunit2sql, in a way that can be consumed by multiple
> > efforts.
> >
> > So I'm generally -1 to this being a separate effort on the basis that so
> > far the team has decided to stay in their own sandbox instead of
> > participating actively where many of us thing the functions should be
> > added. I also think this isn't like Designate, because this isn't
> > intended to be part of the integrated release.
>
> From reading Boris's email it seems like rally will provide a horizon
> panel and api to back it (for the operator to kick of performance runs
> and view stats). So this does seem like something that would be a
> part of the integrated release (if I am reading things correctly).
>
> Is the QA program happy to extend their scope to include that?
> QA could become "Quality Assurance of upstream code and running
> OpenStack installations". If not we need to find some other program
> for rally.
>
> -Angus
>
> >
> > Of course you could decide to slice up the universe in a completely
> > different way, but we have toolchains today, which I think the focus
> > should be on participating there.
> >
> >       -Sean
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140801/916fa7ba/attachment.html>