Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On 08/03/18 19:31, Doug Hellmann wrote: If these new plugins might contain "candidate" tests and all tests are potentially candidates, how are these new repos different from the existing repos that already contain all of the tests? We have to allow candidate tests because otherwise there's a chicken-and-egg type problem where we can never add tests to an existing trademark program. But the definition of 'candidate' that I'm thinking of is along the lines of "under active discussion to be added to the next iteration of refstack". Perhaps that should be documented. To answer your question directly, the main way they're different is that by putting tests in one of these repos, teams are committing to not really change them, and certainly to ~never break backwards compat. It seems like at least part of the problem with the current system was triggered by confusion about when to move tests around to satisfy the policy. Can we avoid that problem with the new system? If we're not going to move the tests into Tempest itself and have the QA team manage them, why not simply take the tests from the repos where they already live? I think a lesson we've learned from Tempest is that there are two parts to successfully reviewing a change: 1) Determine whether the change affects a test that is part of the trademark program. 2) Don't make the change if it does. 2 is easy, but 1 is hard. By separating the trademark tests into a separate repo, we make 1 easy as well. This reduces risk and increases review throughput. I thought the QA team no longer wanted to be responsible for these extra tests. Has that changed again? I've lost track of everyone's positions, I'm afraid. Their position as I understand it is: * They're not going to write tests * They're happy to document the process, offer advice, and review tests as time allows * They don't want tests to be thrown over the transom and made their problem for the rest of time That doesn't conflict with anybody's goals here, so it's mostly a matter of documenting it clearly so that somebody reading without all this context won't get the wrong idea. cheers, Zane. __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On Fri, Mar 9, 2018 at 9:31 AM, Doug Hellmann wrote: > Excerpts from Zane Bitter's message of 2018-03-08 15:51:05 -0500: >> On 08/03/18 12:57, Doug Hellmann wrote: >> > Why would the repos be owned by anyone other than the original project >> > team? >> >> A few reasons I think it makes sense in this instance: >> >> * Not every set of trademark tests will necessarily belong to a single >> project. Tempest itself is an example of this - in fact that's basically >> how the QA program came to exist. Vertical-specific trademark programs >> are another example that we anticipate in the future. >> * Allowing projects to create their own repos means that there's no >> co-ordination point to ensure e.g. a consistent naming scheme. Amongst >> other things, this could potentially cause confusion about which plugins >> are trademark-candidates-only and which are just regular tempest plugins. > > If these new plugins might contain "candidate" tests and all tests > are potentially candidates, how are these new repos different from > the existing repos that already contain all of the tests? It seems > like at least part of the problem with the current system was > triggered by confusion about when to move tests around to satisfy > the policy. Can we avoid that problem with the new system? If we're > not going to move the tests into Tempest itself and have the QA > team manage them, why not simply take the tests from the repos where > they already live? I completely agree on this. If tests are going to move in Tempest then, its all QA things and we own them completely but this is not case now as not all projects ok to do that. Otherwise if interop going to use tests from plugins then just consume tests from their current location. For other future interop program like nfv, HA etc, tests can be in new repo or if interop find any QA projects where they can consume tests then use those QA projects example - Extreme testing [1] which is under review though. > >> * By registering trademark plugins all in one place it makes it easy to >> determine how many there are, which plugins exist (e.g. are there any >> extant plugins that are not referenced by refstack? This is a question >> you can answer in 20s if they're all registered in the same place.) >> * The goal is for maintenance of these plugins to be a collaborative >> effort by the project team, the QA team, and RefStack. If the first step >> for a project establishing a trademark test plugin involves the project >> team reaching out to the QA team then that's a good foot to start on. If >> teams create the repos in their own projects and fly under QA's radar >> then QA folks might not even be aware that they've become core reviewers >> on the repo. > > I thought the QA team no longer wanted to be responsible for these > extra tests. Has that changed again? I've lost track of everyone's > positions, I'm afraid. Maybe we could get people to start voting > on the actual resolutions so it's easier to keep track of that? > > As you pointed out earlier, when contributors to a repo are allowed > to vote in the election for the team lead that owns the repo. We > should think through the implications of that fact when we consider > who will own these new repos (if we actually need anything new and > we can't just use the existing repos). For me, voting things does not matter much. What i see as overall is that interop is ready to consume tests from different places and QA team is all ready to share their review bandwidth with interop team, projects team to review the interop tests irrespective of test location and help to build process/guidelines about consistency, do-not-change-tests etc. And we will make sure that happens. Currently also we do such practice for tempest plugin tests (fix them, use right interface there) and in Rocky we are going to start a program for Tempest plugins to stabilize them where we will grep-ing all plugins for best practice & right way setup and use interfaces. Anyways current proposed version of resolution looks ok to me - https://review.openstack.org/#/c/443504/ > >> I guess we have examples of both models in the community... e.g. >> puppet-openstack vs. Horizon plugins. I wonder if there are any lessons >> we can draw on to see which works better, and when. >> >> cheers, >> Zane. >> ..1 https://review.openstack.org/#/c/443504/ -gmann > > __ > 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
Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On Fri, Mar 9, 2018 at 4:34 AM, Rico Lin wrote: > >> >> Why would the repos be owned by anyone other than the original project >> team? >> > For normal tempest tests, which owned and maintained by original projects. > I think there were discussions in that PTG QA session about interop tests > should be maintained by QA team. > >> > > In the new resolution, we can make sure QA team and project teams will stay > in their obligation to interop testing structure together (isn't that just > like how current tempest plugin structure works). > And allow interop team to focus on interop structure (ideally not the tests > itself). > > I agree with Zane, that we really want all 3 teams to contribute to reviews, > since they each bring different expertise to format this interop structure. Big +1. QA team will always be there to review and spend time on setup the guidelines and best practice for interop tests. We maintained such guidelines for tempest interop tests since 2-3 year or longer and they work perfectly. -gmann > > > > > Rico Lin > > __ > 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
Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
Excerpts from Zane Bitter's message of 2018-03-08 15:51:05 -0500: > On 08/03/18 12:57, Doug Hellmann wrote: > > Why would the repos be owned by anyone other than the original project > > team? > > A few reasons I think it makes sense in this instance: > > * Not every set of trademark tests will necessarily belong to a single > project. Tempest itself is an example of this - in fact that's basically > how the QA program came to exist. Vertical-specific trademark programs > are another example that we anticipate in the future. > * Allowing projects to create their own repos means that there's no > co-ordination point to ensure e.g. a consistent naming scheme. Amongst > other things, this could potentially cause confusion about which plugins > are trademark-candidates-only and which are just regular tempest plugins. If these new plugins might contain "candidate" tests and all tests are potentially candidates, how are these new repos different from the existing repos that already contain all of the tests? It seems like at least part of the problem with the current system was triggered by confusion about when to move tests around to satisfy the policy. Can we avoid that problem with the new system? If we're not going to move the tests into Tempest itself and have the QA team manage them, why not simply take the tests from the repos where they already live? > * By registering trademark plugins all in one place it makes it easy to > determine how many there are, which plugins exist (e.g. are there any > extant plugins that are not referenced by refstack? This is a question > you can answer in 20s if they're all registered in the same place.) > * The goal is for maintenance of these plugins to be a collaborative > effort by the project team, the QA team, and RefStack. If the first step > for a project establishing a trademark test plugin involves the project > team reaching out to the QA team then that's a good foot to start on. If > teams create the repos in their own projects and fly under QA's radar > then QA folks might not even be aware that they've become core reviewers > on the repo. I thought the QA team no longer wanted to be responsible for these extra tests. Has that changed again? I've lost track of everyone's positions, I'm afraid. Maybe we could get people to start voting on the actual resolutions so it's easier to keep track of that? As you pointed out earlier, when contributors to a repo are allowed to vote in the election for the team lead that owns the repo. We should think through the implications of that fact when we consider who will own these new repos (if we actually need anything new and we can't just use the existing repos). > I guess we have examples of both models in the community... e.g. > puppet-openstack vs. Horizon plugins. I wonder if there are any lessons > we can draw on to see which works better, and when. > > cheers, > Zane. > __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On 08/03/18 12:57, Doug Hellmann wrote: Why would the repos be owned by anyone other than the original project team? A few reasons I think it makes sense in this instance: * Not every set of trademark tests will necessarily belong to a single project. Tempest itself is an example of this - in fact that's basically how the QA program came to exist. Vertical-specific trademark programs are another example that we anticipate in the future. * Allowing projects to create their own repos means that there's no co-ordination point to ensure e.g. a consistent naming scheme. Amongst other things, this could potentially cause confusion about which plugins are trademark-candidates-only and which are just regular tempest plugins. * By registering trademark plugins all in one place it makes it easy to determine how many there are, which plugins exist (e.g. are there any extant plugins that are not referenced by refstack? This is a question you can answer in 20s if they're all registered in the same place.) * The goal is for maintenance of these plugins to be a collaborative effort by the project team, the QA team, and RefStack. If the first step for a project establishing a trademark test plugin involves the project team reaching out to the QA team then that's a good foot to start on. If teams create the repos in their own projects and fly under QA's radar then QA folks might not even be aware that they've become core reviewers on the repo. I guess we have examples of both models in the community... e.g. puppet-openstack vs. Horizon plugins. I wonder if there are any lessons we can draw on to see which works better, and when. cheers, Zane. __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
> > Why would the repos be owned by anyone other than the original project > team? > For normal tempest tests, which owned and maintained by original projects. I think there were discussions in that PTG QA session about interop tests should be maintained by QA team. > In the new resolution, we can make sure QA team and project teams will stay in their obligation to interop testing structure together (isn't that just like how current tempest plugin structure works). And allow interop team to focus on interop structure (ideally not the tests itself). I agree with Zane, that we really want all 3 teams to contribute to reviews, since they each bring different expertise to format this interop structure. Rico Lin __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
Excerpts from Zane Bitter's message of 2018-03-08 12:45:11 -0500: > On 07/03/18 08:44, Ghanshyam Mann wrote: > > 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. > > After reading this and the logs from the QA meeting,[1] I feel like > there is some confusion/miscommunication over what the proposed > resolution means by 'ownership'. Basically every Git repo has to be > registered to *some* project in > http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml > > The proposal was to register the trademark test plugins to the QA > project. The implications of this are fairly minimal in my view: > > * The project gets a say on any new repo creation requests (this will > help maintain e.g. a consistent naming scheme IMO) > * Contributors to the repos are considered contributors to the project, > get to vote in the PTL elections, and are allowed to put the logo > sticker on their laptop.[2] (This seems appropriate to me, and in the > best case might even help convert some people into becoming core > reviewers for QA in the long term.) > * The project would have to meet any other obligations in regards to > those repos that the TC delegates to project teams and PTLs - though > none of the ones I can think of (releases, tracking project-wide goals) > would really apply in practice to the repos we're talking about. > > Perhaps I am missing something that you have a specific concern with? > > It is *not* meant to imply that the project has an obligation to write > tests (nobody expects this, in fact), nor that the core reviewers it > contributes to the core review team for the repo have any stronger > obligation to do reviews than any of the other core reviewers (we really > want all 3 teams to contribute to reviews, since they each bring > different expertise). > > I think we have two options that could resolve this: > * Change the wording to ensure that future readers cannot interpret the > resolution as placing obligations on the QA team that we didn't intend > and they do not want; or > * Register the Git repos to the refstack project instead. > > cheers, > Zane. > > [1] > http://eavesdrop.openstack.org/meetings/qa/2018/qa.2018-03-08-07.59.log.html#l-34 > [2] kidding! Everyone knows you can't have the sticker until after the > initiation ;) > Why would the repos be owned by anyone other than the original project team? Doug __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On 07/03/18 08:44, Ghanshyam Mann wrote: 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. After reading this and the logs from the QA meeting,[1] I feel like there is some confusion/miscommunication over what the proposed resolution means by 'ownership'. Basically every Git repo has to be registered to *some* project in http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml The proposal was to register the trademark test plugins to the QA project. The implications of this are fairly minimal in my view: * The project gets a say on any new repo creation requests (this will help maintain e.g. a consistent naming scheme IMO) * Contributors to the repos are considered contributors to the project, get to vote in the PTL elections, and are allowed to put the logo sticker on their laptop.[2] (This seems appropriate to me, and in the best case might even help convert some people into becoming core reviewers for QA in the long term.) * The project would have to meet any other obligations in regards to those repos that the TC delegates to project teams and PTLs - though none of the ones I can think of (releases, tracking project-wide goals) would really apply in practice to the repos we're talking about. Perhaps I am missing something that you have a specific concern with? It is *not* meant to imply that the project has an obligation to write tests (nobody expects this, in fact), nor that the core reviewers it contributes to the core review team for the repo have any stronger obligation to do reviews than any of the other core reviewers (we really want all 3 teams to contribute to reviews, since they each bring different expertise). I think we have two options that could resolve this: * Change the wording to ensure that future readers cannot interpret the resolution as placing obligations on the QA team that we didn't intend and they do not want; or * Register the Git repos to the refstack project instead. cheers, Zane. [1] http://eavesdrop.openstack.org/meetings/qa/2018/qa.2018-03-08-07.59.log.html#l-34 [2] kidding! Everyone knows you can't have the sticker until after the initiation ;) __ 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] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On Wed, Mar 7, 2018 at 10:15 PM, Andrea Frittoli wrote: > > > On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann > 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 requi
Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project
On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann 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. 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 > > > -g
