Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Rodrigo Duarte]

On Tue, Feb 7, 2017 at 7:34 AM, Andrea Frittoli 
wrote:

>
> On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann 
> wrote:
>
>> Hi Jordan,
>>
>> Thanks for bring it up. I know we had both side of argument on those
>> changes.
>>
>> IMO in general, its all QA team responsibility to verify the requirement
>> very strictly and make sure no changes break existing released version and
>> so users. Many times QA team does not agree to development team :).
>>
>> But as we are working as community and one of our key goal is to smooth
>> development also. But as of now, strong rejection or formal approval from
>> QA team is something missing in formal guidelines or formal written.
>>
>> We have api-wg and its guidelines which are a great things in OpenStack
>> and helped a lot to improve the APIs. But those are just guidelines and no
>> hard restriction.
>>
>> Many of us can say if we are changing the APIs in backward incompatible
>> way, then api-wg and QA agreements are great to consider and then only
>> proceed but many of us can say if project team want then even disagreement
>> from QA or api-wg does not matter much.
>>
>> As we do not have any official statement anywhere about mandatory
>> agreement of QA team, i do not think we can stop any projects for such
>> changes but we can always put our strong opinion and try to make project
>> team understand that how harmful that changes can be.
>>
>> To make it in more smooth way in future, there is proposal in TC for new
>> tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
>> refactoring the api-wg guidelines accordingly [2].
>>
>> This is really nice direction and if any projects adopt to have that new
>> tag, then they have to honor the API compatibility and honor the api-wg, QA
>> and TC decision.
>>
>
> +1.
> I think the discussion around the referenced API changes has been quite
> positive, it has lead to a review of api-wg guidelines as well as the
> proposal for a new tag.
> As a QA team we have the responsibility - at least for the projects whose
> tests are hosted in Tempest - to identity changes that may break API
> compatibility and trigger such discussions in the community and help
> building consensus. Ideally in future the process will be much smoother as
> we keep improving guidelines and processes around API stability.
>

Changes that break APIs stability are not uncommon, in keystone, for
example, we already had to deal with some of them. Hopefully, we are
creating a culture where tempest-like tests are being more present and with
this, we can quickly spot such kind of changes.


>
>
>>
>> My opinion on that to have a clear responsibility of QA, api-wg to make
>> projects considering new tag strictly honor the compatibility guidelines.
>> So that we as QA team have formal rights to stop any incompatible changes.
>>
>>
>
>> I personally feel we have to have a very clear responsibility of QA team
>> over API incompatible changes which will be helped by TC and all of us to
>> have consensus on that and keep/make OpenStack APIs as one of the best APIs
>> for users.
>>
>> ..1 https://review.openstack.org/#/c/418010/3
>> ..2 https://review.openstack.org/#/c/421846/
>>
>>
>> -gmann
>>
>> On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier <
>> jordan.pitt...@scality.com> wrote:
>>
>> Hi gmann,
>> 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 Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
>>  wrote:
>> > Hi All,
>> >
>> >
>> >
>> > First and foremost would like to wish you all a successful 2017 ahead
>> and
>> > with this I'm announcing my PTL candidacy of the Quality Assurance team
>> for
>> > the Pike release cycle.
>> >
>> >
>> >
>> > I am glad to work in OpenStack community and would like to thank all the
>> > contributors who supported me to explore new things which brings out my
>> best
>> > for the community.
>> >
>> >
>> >
>> > Let me introduce myself, briefly. I have joined the OpenStack 

Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Andrea Frittoli]

On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann 
wrote:

> Hi Jordan,
>
> Thanks for bring it up. I know we had both side of argument on those
> changes.
>
> IMO in general, its all QA team responsibility to verify the requirement
> very strictly and make sure no changes break existing released version and
> so users. Many times QA team does not agree to development team :).
>
> But as we are working as community and one of our key goal is to smooth
> development also. But as of now, strong rejection or formal approval from
> QA team is something missing in formal guidelines or formal written.
>
> We have api-wg and its guidelines which are a great things in OpenStack
> and helped a lot to improve the APIs. But those are just guidelines and no
> hard restriction.
>
> Many of us can say if we are changing the APIs in backward incompatible
> way, then api-wg and QA agreements are great to consider and then only
> proceed but many of us can say if project team want then even disagreement
> from QA or api-wg does not matter much.
>
> As we do not have any official statement anywhere about mandatory
> agreement of QA team, i do not think we can stop any projects for such
> changes but we can always put our strong opinion and try to make project
> team understand that how harmful that changes can be.
>
> To make it in more smooth way in future, there is proposal in TC for new
> tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
> refactoring the api-wg guidelines accordingly [2].
>
> This is really nice direction and if any projects adopt to have that new
> tag, then they have to honor the API compatibility and honor the api-wg, QA
> and TC decision.
>

+1.
I think the discussion around the referenced API changes has been quite
positive, it has lead to a review of api-wg guidelines as well as the
proposal for a new tag.
As a QA team we have the responsibility - at least for the projects whose
tests are hosted in Tempest - to identity changes that may break API
compatibility and trigger such discussions in the community and help
building consensus. Ideally in future the process will be much smoother as
we keep improving guidelines and processes around API stability.


>
> My opinion on that to have a clear responsibility of QA, api-wg to make
> projects considering new tag strictly honor the compatibility guidelines.
> So that we as QA team have formal rights to stop any incompatible changes.
>
>

> I personally feel we have to have a very clear responsibility of QA team
> over API incompatible changes which will be helped by TC and all of us to
> have consensus on that and keep/make OpenStack APIs as one of the best APIs
> for users.
>
> ..1 https://review.openstack.org/#/c/418010/3
> ..2 https://review.openstack.org/#/c/421846/
>
>
> -gmann
>
> On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier  > wrote:
>
> Hi gmann,
> 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 Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
>  wrote:
> > Hi All,
> >
> >
> >
> > First and foremost would like to wish you all a successful 2017 ahead and
> > with this I'm announcing my PTL candidacy of the Quality Assurance team
> for
> > the Pike release cycle.
> >
> >
> >
> > I am glad to work in OpenStack community and would like to thank all the
> > contributors who supported me to explore new things which brings out my
> best
> > for the community.
> >
> >
> >
> > Let me introduce myself, briefly. I have joined the OpenStack community
> > development in 2014 during mid of Ice-House release. Currently, I'm
> > contributing in QA projects and Nova as well as a core member in Tempest.
> > Since Barcelona Summit, I volunteered  as mentor in the upstream
> training.
> > It‘s always a great experience to introduce OpenStack upstream workflow
> to
> > new contributors and encourage them.
> >
> >
> >
> > Following are my contribution activities:
> >
> > * Review:
> > 

Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Ghanshyam Mann]

Hi Jordan,

Thanks for bring it up. I know we had both side of argument on those
changes.

IMO in general, its all QA team responsibility to verify the requirement
very strictly and make sure no changes break existing released version and
so users. Many times QA team does not agree to development team :).

But as we are working as community and one of our key goal is to smooth
development also. But as of now, strong rejection or formal approval from
QA team is something missing in formal guidelines or formal written.

We have api-wg and its guidelines which are a great things in OpenStack and
helped a lot to improve the APIs. But those are just guidelines and no hard
restriction.

Many of us can say if we are changing the APIs in backward incompatible
way, then api-wg and QA agreements are great to consider and then only
proceed but many of us can say if project team want then even disagreement
from QA or api-wg does not matter much.

As we do not have any official statement anywhere about mandatory agreement
of QA team, i do not think we can stop any projects for such changes but we
can always put our strong opinion and try to make project team understand
that how harmful that changes can be.

To make it in more smooth way in future, there is proposal in TC for new
tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
refactoring the api-wg guidelines accordingly [2].

This is really nice direction and if any projects adopt to have that new
tag, then they have to honor the API compatibility and honor the api-wg, QA
and TC decision.

My opinion on that to have a clear responsibility of QA, api-wg to make
projects considering new tag strictly honor the compatibility guidelines.
So that we as QA team have formal rights to stop any incompatible changes.

I personally feel we have to have a very clear responsibility of QA team
over API incompatible changes which will be helped by TC and all of us to
have consensus on that and keep/make OpenStack APIs as one of the best APIs
for users.

..1 https://review.openstack.org/#/c/418010/3
..2 https://review.openstack.org/#/c/421846/


-gmann

On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier 
wrote:

> Hi gmann,
> 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 Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
>  wrote:
> > Hi All,
> >
> >
> >
> > First and foremost would like to wish you all a successful 2017 ahead and
> > with this I'm announcing my PTL candidacy of the Quality Assurance team
> for
> > the Pike release cycle.
> >
> >
> >
> > I am glad to work in OpenStack community and would like to thank all the
> > contributors who supported me to explore new things which brings out my
> best
> > for the community.
> >
> >
> >
> > Let me introduce myself, briefly. I have joined the OpenStack community
> > development in 2014 during mid of Ice-House release. Currently, I'm
> > contributing in QA projects and Nova as well as a core member in Tempest.
> > Since Barcelona Summit, I volunteered  as mentor in the upstream
> training.
> > It‘s always a great experience to introduce OpenStack upstream workflow
> to
> > new contributors and encourage them.
> >
> >
> >
> > Following are my contribution activities:
> >
> > * Review:
> > http://stackalytics.com/?release=all=marks_id=ghanshyammann
> >
> > * Commit:
> > http://stackalytics.com/?release=all=commits;
> user_id=ghanshyammann
> >
> >
> >
> > I have worked on some key areas on QA like Interfaces migration to lib,
> JSON
> > schema response validation(for compute), API Microversion testing
> framework
> > in Tempest, Improve test coverage and Bug Triage etc.
> >
> >
> >
> > QA program has been immensely improved since it was introduced which
> > increased upstream development quality as well as helping production
> Cloud
> > for their testing and stability. We have a lot of ideas from many
> different
> > contributors to keep improving the QA which is phenomenal and I truly
> > appreciate.
> >
> >
> >
> > Moving 

Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Jordan Pittier]

Hi gmann,
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 Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
 wrote:
> Hi All,
>
>
>
> First and foremost would like to wish you all a successful 2017 ahead and
> with this I'm announcing my PTL candidacy of the Quality Assurance team for
> the Pike release cycle.
>
>
>
> I am glad to work in OpenStack community and would like to thank all the
> contributors who supported me to explore new things which brings out my best
> for the community.
>
>
>
> Let me introduce myself, briefly. I have joined the OpenStack community
> development in 2014 during mid of Ice-House release. Currently, I'm
> contributing in QA projects and Nova as well as a core member in Tempest.
> Since Barcelona Summit, I volunteered  as mentor in the upstream training.
> It‘s always a great experience to introduce OpenStack upstream workflow to
> new contributors and encourage them.
>
>
>
> Following are my contribution activities:
>
> * Review:
> http://stackalytics.com/?release=all=marks_id=ghanshyammann
>
> * Commit:
> http://stackalytics.com/?release=all=commits_id=ghanshyammann
>
>
>
> I have worked on some key areas on QA like Interfaces migration to lib, JSON
> schema response validation(for compute), API Microversion testing framework
> in Tempest, Improve test coverage and Bug Triage etc.
>
>
>
> QA program has been immensely improved since it was introduced which
> increased upstream development quality as well as helping production Cloud
> for their testing and stability. We have a lot of ideas from many different
> contributors to keep improving the QA which is phenomenal and I truly
> appreciate.
>
>
>
> Moving forwards, following are my focus areas for Pike Cycle:
>
>
>
> * Help the other Projects' developments and Plugin Improvement:
>
> OpenStack projects consider the quality is important and QA team needs to
> provide useful testing framework for them. Projects who all needs to
> implement their tempest tests in plugin, focus will be to help plugin tests
> improvement and so projects quality. Lot of Tempest  interfaces are moving
> towards stable interfaces, existing plugin tests needs to be fixed multiple
> times. We are taking care of those and helping them to migrate smoothly. But
> there are still many  interfaces going to migrate to lib and further to be
> adopted on plugin side. I’d like to have some mechanism/automation to
> trigger plugins to know about change interfaces before it breaks them. Also
> help them to use the framework correctly. This helps the other non-core
> projects’ tests.
>
>
>
> * Improve QA projects for Production Cloud:
>
> This will be the main focus area. Having QA projects more useful for
> Production Cloud testing is/will be great achievement for QA team. This area
> has been improved a lot since last couple of cycles and still a lot to do.
> We have to improve Production scenario testing coverage and make all QA
> projects easy to configure and use. During Barcelona summit, 2 new projects
> are initiated which will definitely help to achieve this goal.
>
>   *RBAC Policy -  https://github.com/openstack/patrole
>
>   *HA testing  -  https://review.openstack.org/#/c/374667/
>
>   https://review.openstack.org/#/c/399618/
>
>   *Hoping for more in future
>
> There will be more focus on those projects and new ideas which will help
> production Cloud testing in more powerful way.
>
>
>
> * JSON Schema *response* validation for projects:
>
> JSON schema response validation for compute APIs has been very helpful to
> keep the APIs quality and compatibility. Currently many projects support
> microversion which provides a way to introduce the APIs changes in Backward
> compatible way. I'd like to concentrate on response schema validation for
> those projects also. This helps the OpenStack interoperability and the APIs
> compatibility.
>
>
>
> * Improve Documentation and UX:
>
> Documentation and UX are the key part for any software. There have been huge
> improvement in UX , documentation 

[openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Ghanshyam Mann]

Hi All,

First and foremost would like to wish you all a successful 2017 ahead and with 
this I'm announcing my PTL candidacy of the Quality Assurance team for the Pike 
release cycle.

I am glad to work in OpenStack community and would like to thank all the 
contributors who supported me to explore new things which brings out my best 
for the community.

Let me introduce myself, briefly. I have joined the OpenStack community 
development in 2014 during mid of Ice-House release. Currently, I'm 
contributing in QA projects and Nova as well as a core member in Tempest. Since 
Barcelona Summit, I volunteered  as mentor in the upstream training. It's 
always a great experience to introduce OpenStack upstream workflow to new 
contributors and encourage them.

Following are my contribution activities:
* Review:  
http://stackalytics.com/?release=all=marks_id=ghanshyammann
* Commit:  
http://stackalytics.com/?release=all=commits_id=ghanshyammann

I have worked on some key areas on QA like Interfaces migration to lib, JSON 
schema response validation(for compute), API Microversion testing framework in 
Tempest, Improve test coverage and Bug Triage etc.

QA program has been immensely improved since it was introduced which increased 
upstream development quality as well as helping production Cloud for their 
testing and stability. We have a lot of ideas from many different contributors 
to keep improving the QA which is phenomenal and I truly appreciate.

Moving forwards, following are my focus areas for Pike Cycle:

* Help the other Projects' developments and Plugin Improvement:
OpenStack projects consider the quality is important and QA team needs to 
provide useful testing framework for them. Projects who all needs to implement 
their tempest tests in plugin, focus will be to help plugin tests improvement 
and so projects quality. Lot of Tempest  interfaces are moving towards stable 
interfaces, existing plugin tests needs to be fixed multiple times. We are 
taking care of those and helping them to migrate smoothly. But there are still 
many  interfaces going to migrate to lib and further to be adopted on plugin 
side. I'd like to have some mechanism/automation to trigger plugins to know 
about change interfaces before it breaks them. Also help them to use the 
framework correctly. This helps the other non-core projects' tests.

* Improve QA projects for Production Cloud:
This will be the main focus area. Having QA projects more useful for Production 
Cloud testing is/will be great achievement for QA team. This area has been 
improved a lot since last couple of cycles and still a lot to do. We have to 
improve Production scenario testing coverage and make all QA projects easy to 
configure and use. During Barcelona summit, 2 new projects are initiated which 
will definitely help to achieve this goal.
  *RBAC Policy -  https://github.com/openstack/patrole
  *HA testing  -  https://review.openstack.org/#/c/374667/
  https://review.openstack.org/#/c/399618/
  *Hoping for more in future
There will be more focus on those projects and new ideas which will help 
production Cloud testing in more powerful way.

* JSON Schema *response* validation for projects:
JSON schema response validation for compute APIs has been very helpful to keep 
the APIs quality and compatibility. Currently many projects support 
microversion which provides a way to introduce the APIs changes in Backward 
compatible way. I'd like to concentrate on response schema validation for those 
projects also. This helps the OpenStack interoperability and the APIs 
compatibility.

* Improve Documentation and UX:
Documentation and UX are the key part for any software. There have been huge 
improvement in UX , documentation side and new Tempest workflow is available.  
Still configuration and usage is the pain point for Users. During summit/ptg or 
other platforms I'd like us to have more feedbacks from users and improve 
accordingly. Making configuration easy for people is one of the area we will be 
focusing on.

* Bring on more contributor and core reviewers:
QA projects have been one of the active projects during last couple of years 
and I'd like the team to mentor new contributors to help QA projects in planned 
goal and get them to a place where they will be ready for core reviewers.

* Migrate required Tempest Interfaces as stable to lib:
We together have done great job in this area which helped plugin tests. In 
Service clients migration, Object Storage service client are left and all 
others have been moved as stable interfaces. Lot of others framework/interface 
also available in lib. But still lot of unstable interfaces are being used in 
Plugins which should be migrated to lib soon. In Pike cycle, we will wind up 
all remaining service client migration and other required interfaces.

* Last but not the least, Openness is great power of Open Source and so does 
OpenStack. All new ideas from anyone