Re: [openstack-dev] [qa] PTL Candidacy for Pike

[Jordan Pittier]

Hi Andrea,
Thanks for your candidacy. Let me ask one question if it's not too
late. What's the role of the QA team when it comes to API change ? I
have in mind the recent Glance change related to private vs shared
image status.

Someone in our community asked :
* "I need to get an official decision from the QA team on whether
[such a] patch is acceptable or not"
* "what's needed is an "official" response from the QA team concerning
the acceptability of the patch"

But we didn't provide such an answer. There could be a feeling that
the QA team is acting as a self-appointed activist judiciary.

Now we have another occurrence of a disagreement between the QA team
and a project team: https://bugs.launchpad.net/glance/+bug/1656183,
https://review.openstack.org/#/c/420038/,
https://review.openstack.org/#/c/425487/

I have myself no strong opinion on the matter, that why I need a leader here :)

Note, there *is* a question in this email :D

Jordan

On Fri, Jan 20, 2017 at 1:56 AM, Andrea Frittoli
 wrote:
> Dear all,
>
> I’d like to announce my candidacy for PTL of the QA Program for the Pike
> cycle.
>
> I started working with OpenStack towards the end of 2011. Since 2014 I’ve
> been
> a core developer for Tempest.
> I’ve always aimed for Tempest to be able to run against any OpenStack cloud;
> a lot of my contributions to Tempest have been driven by that.
> I’ve worked on QA for the OpenStack community, for an OpenStack based public
> cloud as well as for an OpenStack distribution.
>
> I believe that quality engineers should develop innovative, high quality
> open-source tools and tests.
>
> The OpenStack community has built an amazing set of tools and services to
> handle quality engineering at such a large scale.
> The number of tests executed, the test infrastructure and amount of test
> data
> produced can still be difficult to handle.
> Complexity can inhibit new contributors as well as existing ones, not only
> for
> the QA program but for OpenStack in general as well.
>
> If elected, in the Pike cycle I would like to focus on two areas.
>
> - QA team support to the broader OpenStack community
> - Finish the work on Tempest stable interfaces for plugins and support
>   existing plugins in the transition
> - Keep an open channel with the broader community when setting
> priorities
>
> - Promote contribution to the QA program, by:
> - removing cruft from Tempest code
> - making it easier to know “what’s going on” when a test job fails
> - focus on tools that help triage and debug gate failures (OpenStack
>   Health, Stackviz)
> - leverage the huge amount of test data we produce every day to
>   automate as much as possible the failure triage and issue
> discovery
>   processes
>
> I hold the QA crew in great esteem, and I would be honoured to serve as the
> next PTL.
>
> Thank you
>
> Andrea Frittoli (andreaf)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] PTL Candidacy for Pike

[Andrea Frittoli]

Dear all,

I’d like to announce my candidacy for PTL of the QA Program for the Pike
cycle.

I started working with OpenStack towards the end of 2011. Since 2014 I’ve
been
a core developer for Tempest.
I’ve always aimed for Tempest to be able to run against any OpenStack cloud;
a lot of my contributions to Tempest have been driven by that.
I’ve worked on QA for the OpenStack community, for an OpenStack based public
cloud as well as for an OpenStack distribution.

I believe that quality engineers should develop innovative, high quality
open-source tools and tests.

The OpenStack community has built an amazing set of tools and services to
handle quality engineering at such a large scale.
The number of tests executed, the test infrastructure and amount of test
data
produced can still be difficult to handle.
Complexity can inhibit new contributors as well as existing ones, not only
for
the QA program but for OpenStack in general as well.

If elected, in the Pike cycle I would like to focus on two areas.

- QA team support to the broader OpenStack community
- Finish the work on Tempest stable interfaces for plugins and support
  existing plugins in the transition
- Keep an open channel with the broader community when setting
priorities

- Promote contribution to the QA program, by:
- removing cruft from Tempest code
- making it easier to know “what’s going on” when a test job fails
- focus on tools that help triage and debug gate failures (OpenStack
  Health, Stackviz)
- leverage the huge amount of test data we produce every day to
  automate as much as possible the failure triage and issue
discovery
  processes

I hold the QA crew in great esteem, and I would be honoured to serve as the
next PTL.

Thank you

Andrea Frittoli (andreaf)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] PTL candidacy

[Omichi, Kenichi]

Hi everyone,

Thank you for given chance to run as a PTL in current Newton cycle.
This experience is exciting and I am glad to work together in the community.
I'd like to continue running as the PTL in the Ocata cycle.

# Newton Summary

At first, it is nice to summarize the Newton cycle for the next Ocata cycle.
We have worked for multiple items in this Newton cycle, and the progress is
amazing. To be honest, my power is not enough to cover all area and this
achievement has been attained by all contributors in this project.
Thank you very much for your contributions.

## Tempest

Tempest is a biggest project under OpenStack QA, the commit number is 13th
of 754 in whole OpenStack[1]. During the Newton cycle, we have provided
Tempest CLI workflow. Users can use Tempest for different clouds/usecases
with separated workspaces, then the operation becomes easy.

The other thing is the cleanup. Tempest had deep class hierarchy and some
magic for resource creation and cleanup. That made investigations hard when
detecting issues. We have removed such barriers for easy debugging.

Now Tempest provides test frameworks to whole OpenStack projects with stable
interfaces. The interfaces still are increasing by releasing Tempest for helping
the other projects. In the Newton cycle, we released 2 versions(12.1.0, 12.2.0)
and they contain many features as these renos[2]. The other projects switched
using these stable interfaces, this situation is appreciated.

## Devstack

One of big Devstack changes is Neutron becomes the default. Neutron is the
direction as the network service instead of nova-net. The change has long
history like enabling/reverting the default Neutron, and now the activation
is stable. So we will be able to get feedback about Neutron widely from
the ecosystem and that will make the quality better in long-term.

The other try is the Devstack code migration for Heat. Devstack provides
a plugin interface to manage its own Devstack code on each project repo,
that makes each project development smooth. The Devstack code has been
implemented in Heat repo and the Heat gate starts running by using that
in the Newton cycle. In addition, several projects rely on Heat. So these
projects need to enable Heat on the gate, and Magnum team succeeded to
do that by working together with Heat team. That is a good collaboration
across projects.

## OpenStack-Health

OpenStack-Health is a useful tool to know test condition of whole OpenStack
projects from bird's-eye view. By using much data for showing graphs, the
performance became issue and we have improved that in this cycle.

The other thing is links to elastic recheck and bug report.
On last failed tests, we can see related elastic recheck and bug report on
the same line. That helps developers to investigate gate issues.

# For Ocata

Based on the Newton experience, I think there are several items for the Ocata 
cycle.

* Help other projects:
  According to the other projects' PTL candidacies, many future PTLs will work
  for QA in the next cycle. QA team will continue helping these projects by
  communicating to the other projects. And it is nice to provide good document
  which describes how to use new test interfaces of Tempest for the other 
projects.
* Continue bug triage:
  An interesting thing is that bug reports tend to be submitted as Tempest bugs
  even if they are due to the other projects' issues. So the bug triage of 
Tempest
  is important to improve whole OpenStack quality by setting reports to suitable
  projects. We started some prototype[3] to show bug triage progress of Tempest.
  Such kind of graph will be helpful to motivate people for the triage. I hope
  this will be expanded to other projects.

This is my proposal and thanks for giving me a chance to raise my hand again.
Regardless of the election result, I will do my best in this project for the 
next cycle.

Thanks
Ken'ichi Ohmichi

---
[1]: http://stackalytics.com/?metric=commits=newton
[2]: http://docs.openstack.org/releasenotes/tempest/unreleased.html
[3]: https://github.com/oomichi/bug-counter#current-graph


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] PTL candidacy

[Kenichi Oomichi]

Hi everyone,

I'd like to announce my candidacy for PTL of the Quality Assurance
team for the Newton release cycle. I have joined into the OpenStack
community since 2012 as a developer, and you can see my activities on
the following metric:

 * Review: http://stackalytics.com/?release=all_id=oomichi=marks
 * Commit: http://stackalytics.com/?release=all_id=oomichi=commits

I have concentrated on solving bugs on both QA and Nova sides in long
term, my contribution has created Nova V2.1 API as a result. The API
is necessary to solve both API inconsistencies and wrong behaviors of
the existing API without clients' pain. Now many projects start to use
its mechanism (API microversions) for solving these own issues.
In Mitaka cycle, we have implemented the testing framework for the API
microversions in Tempest to be used in all projects. The fact is my
pleasure because we can work together to solve the same issues between
whole OpenStack projects. That is a strong point of our OpenStack
community.

In Newton cycle, I'd like to finish service client development which
makes it easy to implement Tempest-like tests for non-core projects.
That will be helpful for OpenStack big-tent. We have already implemented
many clients as stable interfaces, but some clients still remain.
I believe we can finish that with folks in the cycle. On the other hand,
tempest-resources feature also is one of that I want to concentrate on
in the cycle. That will make Tempest easier to be used on production
environments. If implementing it, we can involve more users in our
upstream development and debugging. One more thing is OpenStack health
dashboard, that attracts people to QA project. We can see current test
situation easily from the dashboard. The dashboard is already great, but
there are still several ideas for improving. I want to see the improved
one in the cycle.

I don't want to enforce something on folks. The door of QA project
should be always open as previous PTLs did. New ideas are welcome for
improving test coverage and easy debugging, this is open source project.

I am glad that this chance is given to all developers, this community
is really open. Regardless of the election result, I will do my best
in this project.

Thanks
Ken'ichi Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 04/03/2015 12:33 PM, Matthew Treinish wrote:
 Hi Everyone,
 
 I'd like to throw my hat into the ring for another cycle as the PTL for the QA
 program/team/group/whatever it's called under the new governance model.
 
 This past cycle has been a very exciting one for the QA program. We've made a
 bunch of progress on numerous work items to improve the growing number of
 projects under the QA umbrella. While this work is ongoing we've also had to
 adapt as the wider community has been moving to a new governance model.
 
 We've been working to make the QA program more externally accessible and
 consumable in preparation for a large growth in the number of projects. On the
 tempest side this has meant a steady expansion of code being moved into
 tempest-lib to provide resources, which were previously only available in
 tempest, externally consumable. For devstack we've seen the addition of plugin
 support which allows new projects to leverage deploying, testing, and 
 developing
 with devstack without needing to modify devstack's code itself.
 
 Another effort which I outlined in my candidacy email for this past cycle [1]
 and a blog post preceding that [2] was the work to make the QA projects more
 modular and reusable. It turned out that this work lines up quite well with 
 what
 is needed to enable the self service model we're working towards under the big
 tent. I expect that as we continue to evolve our current set of projects to be
 more modular and work under the big tent that using the tooling in different
 workflows will also improve.
 
 Moving into Liberty my plan is to continue heading down this same path and
 working to enable more projects to become self sufficient when using QA
 projects. To this end I expect we'll be adding a similar external plugin
 interface into grenade early in liberty, a continued expansion on the use of
 devstack plugins, and migrating more of tempest's common code over to
 tempest-lib.
 
 Additionally, the continued efforts that we've been pushing for some time to
 make tempest and the other QA projects easier to use in general, both in and
 out of the gate, will definitely continue. This is something we've made a lot 
 of
 progress on this past cycle and think it will definitely be a continued 
 priority
 for Liberty.
 
 It's been my honor to serve as the QA PTL for the past 2 cycles and I'm 
 looking
 forward to helping make Liberty another great cycle. I hope to have the
 opportunity to continue leading the QA program as PTL and work towards making
 a better OpenStack with the rest of the community.
 
 Thanks,
 
 Matt Treinish
 
 [1] 
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/046704.html
 [2] http://blog.kortar.org/?p=4
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] PTL Candidacy

[Matthew Treinish]

Hi Everyone,

I'd like to throw my hat into the ring for another cycle as the PTL for the QA
program/team/group/whatever it's called under the new governance model.

This past cycle has been a very exciting one for the QA program. We've made a
bunch of progress on numerous work items to improve the growing number of
projects under the QA umbrella. While this work is ongoing we've also had to
adapt as the wider community has been moving to a new governance model.

We've been working to make the QA program more externally accessible and
consumable in preparation for a large growth in the number of projects. On the
tempest side this has meant a steady expansion of code being moved into
tempest-lib to provide resources, which were previously only available in
tempest, externally consumable. For devstack we've seen the addition of plugin
support which allows new projects to leverage deploying, testing, and developing
with devstack without needing to modify devstack's code itself.

Another effort which I outlined in my candidacy email for this past cycle [1]
and a blog post preceding that [2] was the work to make the QA projects more
modular and reusable. It turned out that this work lines up quite well with what
is needed to enable the self service model we're working towards under the big
tent. I expect that as we continue to evolve our current set of projects to be
more modular and work under the big tent that using the tooling in different
workflows will also improve.

Moving into Liberty my plan is to continue heading down this same path and
working to enable more projects to become self sufficient when using QA
projects. To this end I expect we'll be adding a similar external plugin
interface into grenade early in liberty, a continued expansion on the use of
devstack plugins, and migrating more of tempest's common code over to
tempest-lib.

Additionally, the continued efforts that we've been pushing for some time to
make tempest and the other QA projects easier to use in general, both in and
out of the gate, will definitely continue. This is something we've made a lot of
progress on this past cycle and think it will definitely be a continued priority
for Liberty.

It's been my honor to serve as the QA PTL for the past 2 cycles and I'm looking
forward to helping make Liberty another great cycle. I hope to have the
opportunity to continue leading the QA program as PTL and work towards making
a better OpenStack with the rest of the community.

Thanks,

Matt Treinish

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046704.html
[2] http://blog.kortar.org/?p=4


pgpqXNPJyxzUK.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] PTL Candidacy

[Matthew Treinish]

I'd like to throw my hat into the ring for another term as PTL of the QA
program.

The Juno cycle has been very productive with some big developments in the QA
program including: being the first cycle to implement branchless Tempest,
starting tempest-lib, and consolidating the devstack program with the QA
program. This cycle was also unique in that we identified some large scaling
limits with our current integrated gating model. Together with infra we came up
with some substantial changes to try and address these issues.[1] 

Just as OpenStack itself has been growing and evolving the QA program has been
undergoing similar changes. I personally feel that scaling with the rest of
OpenStack has been one of the biggest challenges for the QA program. This will
continue to be true in Kilo as well. However, it's definitely something I feel
that we can continue to address and be solved by working together as a community
to come up with new solutions to as these new issues appear. Moving forward
I expect that working towards this will be a top priority for everyone, not just
QA and Infra, but for the QA program specifically I expect that this change in
our gating model will continue to heavily influence the development goals into
Kilo.

For Kilo I also have a couple of other separate priorities, firstly to make the
QA projects more modular and reusable. [2] This is to in order to make consuming
QA program projects easier to use by themselves. Also by making each project
more targeted and externally consumable it should make it easier to build off of
them and use each project for different scenarios both in and outside of the
gate. Tempest-lib was the start of this effort late in Juno, and I expect this
trend will continue into Kilo.

My other larger priority for Kilo is to work on making the QA projects more
accessible. This is something I outlined as a priority for a Juno cycle, [3] and
I think we've made good progress on this so far. But, recent larger discussions
we've had in the OpenStack community have made it clear that there is still a
lot of work left on making it clearer how things work. Whether it be improving
the UX or the documentation around the projects in the QA program or coming up
with better channels to improve cross-project communication this is something I
view as very important for Kilo. Also, by working on this it will hopefully
enable growing the communities and number of contributors for the QA program
projects.

I'm looking forward to helping make Kilo another great cycle, and I hope to have
the opportunity to continue leading the QA program and work towards making a
better OpenStack with the rest of the community.

Thanks,

Matt Treinish

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html
[2] http://blog.kortar.org/?p=4
[3] http://lists.openstack.org/pipermail/openstack-dev/2014-March/031297.html


pgpu0JPnskDG_.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] PTL Candidacy

[Tristan Cacqueray]

confirmed

On 22/09/14 12:32 PM, Matthew Treinish wrote:
 I'd like to throw my hat into the ring for another term as PTL of the QA
 program.
 
 The Juno cycle has been very productive with some big developments in the QA
 program including: being the first cycle to implement branchless Tempest,
 starting tempest-lib, and consolidating the devstack program with the QA
 program. This cycle was also unique in that we identified some large scaling
 limits with our current integrated gating model. Together with infra we came 
 up
 with some substantial changes to try and address these issues.[1] 
 
 Just as OpenStack itself has been growing and evolving the QA program has been
 undergoing similar changes. I personally feel that scaling with the rest of
 OpenStack has been one of the biggest challenges for the QA program. This will
 continue to be true in Kilo as well. However, it's definitely something I feel
 that we can continue to address and be solved by working together as a 
 community
 to come up with new solutions to as these new issues appear. Moving forward
 I expect that working towards this will be a top priority for everyone, not 
 just
 QA and Infra, but for the QA program specifically I expect that this change in
 our gating model will continue to heavily influence the development goals into
 Kilo.
 
 For Kilo I also have a couple of other separate priorities, firstly to make 
 the
 QA projects more modular and reusable. [2] This is to in order to make 
 consuming
 QA program projects easier to use by themselves. Also by making each project
 more targeted and externally consumable it should make it easier to build off 
 of
 them and use each project for different scenarios both in and outside of the
 gate. Tempest-lib was the start of this effort late in Juno, and I expect this
 trend will continue into Kilo.
 
 My other larger priority for Kilo is to work on making the QA projects more
 accessible. This is something I outlined as a priority for a Juno cycle, [3] 
 and
 I think we've made good progress on this so far. But, recent larger 
 discussions
 we've had in the OpenStack community have made it clear that there is still a
 lot of work left on making it clearer how things work. Whether it be improving
 the UX or the documentation around the projects in the QA program or coming up
 with better channels to improve cross-project communication this is something 
 I
 view as very important for Kilo. Also, by working on this it will hopefully
 enable growing the communities and number of contributors for the QA program
 projects.
 
 I'm looking forward to helping make Kilo another great cycle, and I hope to 
 have
 the opportunity to continue leading the QA program and work towards making a
 better OpenStack with the rest of the community.
 
 Thanks,
 
 Matt Treinish
 
 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html
 [2] http://blog.kortar.org/?p=4
 [3] http://lists.openstack.org/pipermail/openstack-dev/2014-March/031297.html
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev