Le 02/08/2014 04:31, Alex Freedland a écrit :
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?
Some tooling exists already for development purposes : Devstack,
Grenade, Tempest for the one most known. All of them are part of the QA
program, except Devstack which is probably soon to be integrated as well
in that QA program (see [1])
IMHO, there are 2 distinct concerns :
- either we consider that Rally is another great tool for qualifying
OpenStack releases, and then IMHO, the QA Program mission statement can
cover this.
- or, we consider that Rally is for operations only (IMHO we would
loose some benefits then) and then possibly a new program could make
sense. That said, by looking at the Deployment Program mission
statement, I'm thinking that Rally could be part of, as it would be a
gread addition for TripleO deployments.
-Sylvain
[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041731.html
Alex Freedland
Co-Founder
Mirantis, Inc.
On Thu, Jul 31, 2014 at 3:55 AM, Angus Salkeld
<angus.salk...@rackspace.com <mailto:angus.salk...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
