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.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 > > 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