Open Stack

Le 30/07/2014 22:13, Boris Pavlovic a écrit :
> Hi all, 
>
> This thread is very useful. We've detect issue related to the mission
> statement and name of proposed program on early steps. Seems like
> mission statement and name are totally unclear and don't present in
> the right perspective goals of this program. 
>
> I updated name and mission statement:
>
> name:
>     SLA Management
>
> mission:
>     Provide SLA Management for production OpenStack clouds. This includes
>     measuring and tracking performance of OpenStack Services, key API
> methods
>     and cloud applications, performance and functional tests on
> demand, and
>     everything that is required to detect and debug issues in live
> production clouds. 
>
> As well, I updated patch to governance:
> https://review.openstack.org/#/c/108502/3
>
>
> I hope now it's more clear, what is the goal of this program and why
> we should add new program. 
>
> Thoughts? 
>


-1 to it. SLA means that you create a contract in between a provider and
an user. Here, you don't create a contract (ie. you don't create ratios
and engagement) but you monitor these contracts.

As there are no SLAs now in OpenStack upstream (that's something for
operators), we can't say if the KPIs are OK or not.
How can you ensure that the code will be 9 nines if you don't look at
how OpenStack will be deployed ?

If you say the mission statement is to provide measurement tools for
OpenStack, then it possibly goes either in QA or in Telemetry programs.
If you say that the goal is to detect and debug issues in clouds, then
it clearly goes into QA program.


IMHO, both your name and your mission statement are confusing. Long
story short, I'm pro Rally as a separate project but in the QA program.

-Sylvain

> Best regards,
> Boris Pavlovic 
>
>
> On Tue, Jul 29, 2014 at 12:39 AM, Boris Pavlovic <boris at pavlovic.me
> <mailto:boris at pavlovic.me>> wrote:
>
>     Hi Sean,
>
>     I appreciate you valuing Rally so highly as to suggesting it
>     should join the QA program. It is a great vote of confidence for
>     me. While I believe that Rally  and Tempest will always work
>     closely together, the intended utility and the direction of where
>     we are planing to take Rally will not be compatible with the
>     direction of where I think the QA program is going. Please let me
>     explain in more details below.
>
>     Tempest is a collection of Functional and Performance Tests which
>     is used by the developers to improve the quality of the OpenStack
>     code.  
>
>     Rally on the other hand, is envisioned as a Tool that is going to
>     be run by the cloud operators in order to measure, tune and
>     continuously improve the performance of an OpenStack cloud.
>      Moreover, we have an SLA module that allows the Operator to
>     define what constitutes an acceptable level of performance and a
>     profiler that would provide both the user and the developer the
>     diagnostic set of performance data.  Finally, Rally is designed to
>     run on production clouds and to be integrated as a Horizon plugin. 
>
>     In the future, we envision integrating Rally with other services
>     (e.g. Logging as a Service, Satori, Rubick, and other
>     operator-targeted services). I believe that this is not the
>     direction compatible with the mission of the the QA program .
>
>     Before applying for a new Performance and Scalability program, we
>     have thought that the best existing program that Rally could be a
>     part of now and in the future is the Telemetry program. We have
>     discussed with Eoghan Glynn the idea of extending the scope of its
>     mission to include other operator related projects and include
>     Rally to it. Eoghan liked the idea in general but felt that
>     Ceilometer currently has too much on its plate and was not in a
>     position to merge in a new project. However, I can still see the
>     two programs maturing and potentially becoming one down the road. 
>
>     Now, regarding the point that you make of Rally and Tempest doing
>     some duplicate work. I completely agree with you that we should
>     avoid it as much as possible and we should stay in close
>     communication to make sure that duplicate requirements are only
>     implemented once. 
>
>     Following our earlier discussion, Rally is now using Tempest for
>     those benchmarks that do not require special complex environments,
>     we also encapsulated and automated Tempest usage to make it more
>     accessible for the Operators (here is the Blog documenting it --
>      http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/). 
>
>     We would like to further continue to de-duplicate the work inside
>     Tempest and Rally. We made some joint design decisions in Atlanta
>     to transfer some of the Integration code from Rally to Tempest,
>     resulting in the work performed by Andrew Kurilin
>     (https://review.openstack.org/#/c/94473/). I would encourage and
>     welcome more of such cooperation in the future. 
>
>     I trust that this addresses most of your concerns and please do
>     not hesitate to bring up more questions and suggestions.
>
>     Sincerely,
>
>     Boris
>
>
>     On Sun, Jul 27, 2014 at 6:57 PM, Sean Dague <sean at dague.net
>     <mailto:sean at dague.net>> 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.
>
>         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
>
>         --
>         Sean Dague
>         http://dague.net
>
>
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto: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/20140731/042b6c10/attachment.html>