<div dir="ltr">Thierry, <div><br></div><div>I like "Operations" name for this program. It totally makes sense as we can keep this name and extend just mission of this program to include such projects like satori, rubick, logaas and others in future. </div>
<div><br></div><div><br></div><div>Sylvian, </div><div><br></div><div>Thank you for your input. </div><div><br></div><div>In my opinion, having 2 separated programs doesn't mean that these 2 programs shouldn't collaborate and work together. Imho we are all one big community and should help each other.</div>
<div><br></div><div>Actually the goal of "Operations" program is to be able to organize centralized work on OpenStack API that will provide for OpenStack Operators everything required to analyze how live production OpenStack cloud perform. And in case of issues, to be able fast to detect and debug them. </div>
<div><br></div><div>If we present this via OpenStack APi, it will just make a life of QA simpler, because they won't need to do all this via scripts in gates (which is much harder task)</div><div><br></div><div><br></div>
<div>Best regards,</div><div>Boris Pavlovic </div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 1:04 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
<div>Le 02/08/2014 04:31, Alex Freedland a
écrit :<br>
</div><div>
<blockquote type="cite">
<div dir="ltr">Angus,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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? </div>
<div><br>
</div>
<div> <br>
</div>
</div>
</blockquote>
<br></div>
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])<br>
<br>
<br>
IMHO, there are 2 distinct concerns : <br>
- either we consider that Rally is another great tool for
qualifying OpenStack releases, and then IMHO, the QA Program mission
statement can cover this.<br>
- 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.<br>
<br>
-Sylvain<br>
<br>
<br>
<br>
[1]
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/041731.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/041731.html</a><div><div><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra"><br clear="all">
<div><span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Alex
Freedland</span><br style="color:rgb(0,0,0);font-family:verdana,sans-serif">
<span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Co-Founder </span><br style="color:rgb(0,0,0);font-family:verdana,sans-serif">
<span style="color:rgb(0,0,0);font-family:verdana,sans-serif">Mirantis,
Inc.</span><br style="color:rgb(51,204,255);font-family:comic sans ms,sans-serif">
<br>
<br>
</div>
<br>
<br>
<div class="gmail_quote">On Thu, Jul 31, 2014 at 3:55 AM,
Angus Salkeld <span dir="ltr"><<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On Sun, 2014-07-27 at 07:57 -0700,
Sean Dague wrote:<br>
> On 07/26/2014 05:51 PM, Hayes, Graham wrote:<br>
> > On Tue, 2014-07-22 at 12:18 -0400, Sean
Dague wrote:<br>
> >> On 07/22/2014 11:58 AM, David Kranz
wrote:<br>
> >>> On 07/22/2014 10:44 AM, Sean Dague
wrote:<br>
> >>>> Honestly, I'm really not sure
I see this as a different program, but is<br>
> >>>> really something that should
be folded into the QA program. I feel like<br>
> >>>> a top level effort like this
is going to lead to a lot of duplication in<br>
> >>>> the data analysis that's
currently going on, as well as functionality<br>
> >>>> for better load driver UX.<br>
> >>>><br>
> >>>> -Sean<br>
> >>> +1<br>
> >>> It will also lead to pointless
discussions/arguments about which<br>
> >>> activities are part of "QA" and
which are part of<br>
> >>> "Performance and Scalability
Testing".<br>
> ><br>
> > I think that those discussions will still
take place, it will just be on<br>
> > a per repository basis, instead of a per
program one.<br>
> ><br>
> > [snip]<br>
> ><br>
> >><br>
> >> Right, 100% agreed. Rally would remain
with it's own repo + review team,<br>
> >> just like grenade.<br>
> >><br>
> >> -Sean<br>
> >><br>
> ><br>
> > Is the concept of a separate review team
not the point of a program?<br>
> ><br>
> > In the the thread from Designate's
Incubation request Thierry said [1]:<br>
> ><br>
> >> "Programs" just let us bless goals and
teams and let them organize<br>
> >> code however they want, with
contribution to any code repo under that<br>
> >> umbrella being considered "official"
and ATC-status-granting.<br>
> ><br>
> > I do think that this is something that
needs to be clarified by the TC -<br>
> > Rally could not get a PTL if they were
part of the QA project, but every<br>
> > time we get a program request, the same
discussion happens.<br>
> ><br>
> > I think that mission statements can be
edited to fit new programs as<br>
> > they occur, and that it is more important
to let teams that have been<br>
> > working closely together to stay as a
distinct group.<br>
><br>
> My big concern here is that many of the things
that these efforts have<br>
> been doing are things we actually want much
closer to the base. For<br>
> instance, metrics on Tempest runs.<br>
><br>
> When Rally was first created it had it's own
load generator. It took a<br>
> ton of effort to keep the team from duplicating
that and instead just<br>
> use some subset of Tempest. Then when measuring
showed up, we actually<br>
> said that is something that would be great in
Tempest, so whoever ran<br>
> it, be it for Testing, Monitoring, or
Performance gathering, would have<br>
> access to that data. But the Rally team went
off in a corner and did it<br>
> otherwise. That's caused the QA team to have to
go and redo this work<br>
> from scratch with subunit2sql, in a way that
can be consumed by multiple<br>
> efforts.<br>
><br>
> So I'm generally -1 to this being a separate
effort on the basis that so<br>
> far the team has decided to stay in their own
sandbox instead of<br>
> participating actively where many of us thing
the functions should be<br>
> added. I also think this isn't like Designate,
because this isn't<br>
> intended to be part of the integrated release.<br>
<br>
</div>
</div>
From reading Boris's email it seems like rally will
provide a horizon<br>
panel and api to back it (for the operator to kick of
performance runs<br>
and view stats). So this does seem like something that
would be a<br>
part of the integrated release (if I am reading things
correctly).<br>
<br>
Is the QA program happy to extend their scope to include
that?<br>
QA could become "Quality Assurance of upstream code and
running<br>
OpenStack installations". If not we need to find some
other program<br>
for rally.<br>
<span><font color="#888888"><br>
-Angus<br>
</font></span>
<div><br>
><br>
> Of course you could decide to slice up the
universe in a completely<br>
> different way, but we have toolchains today,
which I think the focus<br>
> should be on participating there.<br>
><br>
> -Sean<br>
><br>
</div>
<div>
<div>>
_______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>