Open Stack

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

>
> On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann <ghanshyammann at 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 at 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 at 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:
>> >
>> > * 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.
>> >
>> >   *        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 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170207/887c33c7/attachment.html>