Open Stack

On Wed, Mar 7, 2018 at 10:15 PM, Andrea Frittoli <andrea.frittoli at gmail.com>
wrote:

>
>
> On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
>
>>  Hi All,
>>
>> QA had discussion in Dublin PTG about interop adds-on tests location.
>> First of all thanks all (specially markvoelker, dhellmann, mugsie) for
>> joining the sessions. and I am glad we conclude the things and agreed on
>> solution.
>>
>> Discussion was carry forward from the ML discussion [1] and to get the
>> agreement about interop adds-on program tests location.
>>
>> Till now only 2 projects (heat and designate) are in list of adds-on
>> program from interop side. After discussion and points from all stack
>> holders, QA team agreed to host these 2 projects interop tests.  Tests from
>> both projects are not much as of now and QA team can accommodate to host
>> their interop tests.
>>
>> Along with that agreement we had few more technical points to consider
>> while moving designate and heat interop tests in Tempest repo. All the
>> interop tests going to be added in Tempest must to be Tempest like tests.
>> Tempest like tests here means tests written using Tempest interfaces and
>> guidelines. For example, heat has their tests in heat-tempest-plugin based
>> on gabbi and to move heat interop tests to Tempest those have to be written
>> as Tempest like test. This is because if we accept non-tempest like tests
>> in Tempest then, it will be too difficult to maintain by Tempest team.
>>
>> Projects (designate and heat) and QA team will work closely to move
>> interop tests to Tempest repo which might needs some extra work of
>> standardizing their tests and interface used by them like service clients
>> etc.
>>
>> In future, if there are more new interop adds-on program proposal then,
>> we need to analyse the situation again regarding QA team bandwidth. TC or
>> QA or interop team needs to raise the resource requirement to Board of
>> Directors before any more new adds-on program is being proposed. If QA team
>> has less resource and less review bandwitdh then we cannot accept the more
>> interop programs till QA get more resource to maintain new interop tests.
>>
>> Overall Summary:
>> - QA team agreed to host the interop tests for heat and designate in
>> Tempest repo.
>> - Existing TC resolution needs to be adjust about the QA team resource
>> bandwidth requirement. If there is going to be more adds-on program
>> proposal then, QA team will not accept the new interop tests if QA team
>> bandwidth issue still exist that time also.
>> - Tempest will document the clear process about interop tests addition
>> and other more care items etc.
>> - Projects team to make their tests and interface as Tempest like tests
>> and stable interfaces standards. Tempest team will closely work and help
>> Designate and Heat on this.
>>
>> Thanks for the summary Ghanshyam!
>
> We had some follow up discussion on Friday about this, after the Heat team
> expressed their concern about proceeding with the plan we discussed during
> the session on Wednesday.
> A group of representatives of the Heat, Designate and Interop teams met
> with the TC and agreed on reviving the resolution started by mugsie in
> https://review.openstack.org/#/c/521602 to add an alternative to hosting
> tests in the Tempest repo. Unfortunately I was only there for the last few
> minutes of the meeting, but I understand that the proposal drafted there
> was to allow team to have interop-specific Tempest plugins
> ​​
> co-owned by QA/Interop/add-on project team. mugsie has updated the
> resolution accordingly and I think the discussion on that can continue in
> gerrit directly.
>

​Thanks for pointing that. I feel
​
co-owned is not solving any issue here and i am little worried if that
makes things more difficult on controlling the tests. If tests are not
tempest like tests then, it is little difficult for QA team to control or
input. and if it is also owned by project then how it make sure to control
the test modification by non-project team. I mean i am all ok with separate
plugin which is more easy for QA team but ownership to QA is kind of going
to same direction(QA team maintaining interop ads-on tests) in more
difficult way.
I will check and add my points on gerrit.
​

>
> Just to clarify, nothing has been decided yet, but at least the new
> proposal was received positively by all parties involved in the discussion
> on Friday.
>
> Action Items:
>> - mugsie to abandon https://review.openstack.org/#/c/521602 with quick
>> summary of discussion here at PTG
>>
> This is not valid anymore, we should discuss this further and hopefully
> reach an agreement.
>
>
>> - markvoelker to write up clarification to InteropWG process stating that
>> tests should be moved into Tempest before being proposed to the BoD
>> - markvoelker to work with gmann before next InteropWG+BoD discussion to
>> frame up a note about resourcing testing for add-on/vertical programs
>> - dhellmann to adjust the TC resolution for resource requirement in QA
>> when new adds-on program is being proposed
>> - project teams to convert  interop test and  framework as per tempest
>> like tests and propose to add to tempest repo.
>>
> If the new resolution is agreed on, this will become one of the options.
>
>
>> - gmann to define process in QA about interop tests addition and
>> maintainance
>>
> This is still an option so you may still want to do it.
>
> Andrea Frittoli (andreaf)
>
>>
>> We have added this as one of the monitoring/helping item for QA to make
>> sure it is done without delay.  Let's work together to finish this
>> activity.
>>
>> Discussion Details: https://etherpad.openstack.
>> org/p/qa-rocky-ptg-Interop-test-for-adds-on-project
>>
>> ..1 http://lists.openstack.org/pipermail/openstack-dev/2018-
>> January/126146.html
>>
>> -gmann
>> _______________________________________________
>> Interop-wg mailing list
>> Interop-wg at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg
>>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180307/225f4963/attachment.html>