settingsLogin | Registersettings

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

0 votes

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&metric=marks&user_id=ghanshyammann
* Commit: http://stackalytics.com/?release=all&metric=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 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.

  • 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 will be most welcome.

Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great leadership quality and taken QA projects to a new height. I have learnt a lot from them which motivates me.

I look forward to contributing to all of these areas and more during the Pike cycle.

-gmann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Feb 7, 2017 in openstack-dev by ghanshyam.mann_at_ne (940 points)   1

3 Responses

0 votes

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 jordan.pittier@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
ghanshyam.mann@nectechnologies.in 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:

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.

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 will be most welcome.

Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great
leadership quality and taken QA projects to a new height. I have learnt a
lot from them which motivates me.

I look forward to contributing to all of these areas and more during the
Pike cycle.

-gmann



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

--

quadrant-object-storage?utmcampaign=MQ&utmmedium=Email&
utm_source=signatures>


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 7, 2017 by GHANSHYAM_MANN (5,700 points)   1 3 4
0 votes

On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann ghanshyammann@gmail.com
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 <jordan.pittier@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
ghanshyam.mann@nectechnologies.in 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:

http://stackalytics.com/?release=all&metric=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 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.

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 will be most welcome.

Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great
leadership quality and taken QA projects to a new height. I have learnt a
lot from them which motivates me.

I look forward to contributing to all of these areas and more during the
Pike cycle.

-gmann


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

--

<
http://go.scality.com/acton/media/18585/gartner-magic-quadrant-object-storage?utm_campaign=MQ&utm_medium=Email&utm_source=signatures
>


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 7, 2017 by Andrea_Frittoli (5,920 points)   1 2 3
0 votes

On Tue, Feb 7, 2017 at 7:34 AM, Andrea Frittoli andrea.frittoli@gmail.com
wrote:

On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann ghanshyammann@gmail.com
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.pittier@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
ghanshyam.mann@nectechnologies.in 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:

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.

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 will be most welcome.

Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great
leadership quality and taken QA projects to a new height. I have learnt
a
lot from them which motivates me.

I look forward to contributing to all of these areas and more during the
Pike cycle.

-gmann



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

--

quadrant-object-storage?utmcampaign=MQ&utmmedium=Email&
utm_source=signatures>



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 7, 2017 by Rodrigo_Duarte (1,760 points)   2
...