 Yeah. Hello, everyone. Let's start. So this is OpenStackQA project update. Myself, consumer, I'm serving as QAPTL since last cycle. So this is our logo. So what is OpenStackQA? We develop, maintain and initiate the tools and we plan to ensure the upstream stability and quality. And on the release wise, like each release cycle, we do the CI CD with gate job and we make sure we are not breaking things or every project is delivering with the quality codes. So that is mission statement for QAPTL. And we have a lot of tooling and projects under QAPTL. We have Tempest, DevStack, Granite. So Tempest is having a set of test case with you with common framework, which you can implement the Tempest like test. DevStack, doing the setup for your development environment, Granite for upgrade testing at development level. Petrol is the new one, which started with the RBAC testing. It is not yet stable released yet, but we are planning to release it in Stein cycle. And there are a lot of other tooling also. DevStack tool, we have plugins, we have for DevStack. And we have test result data also like OpenStackHealth, StackWiz and OS tester to run the test case. Hacking we have for checking the code styles within the OpenStack code. And yeah, there are a lot of other projects also. Few of them are deprecated like last one. Tempest live is already deprecated since one or two years, which we have moved into the Tempest itself. So these are the current repository, or you can see the current subprojects under QA. And this is what OpenStack QA does. So we are community driven approach to QA. And we serve as OpenStack community, drive testing best practices. Like for example, for interrupt cases, we for the compute and now we are doing for volume test case also, we are doing the strict validation using JSON schema. So that is helpful for interrupt testing and all. So those are the like some best practice we maybe maintain and drive. And we maintain test tool and frameworks. And yeah, we keep the gate running smoothly. So every day like we keep checking the gate stability and if there is something broken, so QA team will be like helpful or responsible to support that fix and to maintain the gate stability so that the development of every projects can go smoothly. And we support the interoperability test effort. Currently interop has six, five or six projects under them. And all of them test cases are under Tempest repository now. But interop is extending the certification program with I think heat and designate which got approved I think yesterday board meeting. But those test cases will be in the heat repository and designate repository. But whatever the test case we have currently for NOAA Cinder glance, we will keep maintaining them and we will be providing the interop best practice for the other repository and project also. And we do the cross community collaboration for testing tool etc. Like there is no actually real project exist as of now. But we have few initiative for the cross community testing. One is the extreme testing project. And some data plane and control plane testing plans we discussed during last PTC which can be like used across the community like with the OPNFV or with Kubernetes, CICD role. And we are open for the new testing ideas and projects. So if the new if you think like something you are doing at downstream and that you are like feeling should go at the upstream under QA. So if that is within our scope, so we are very open to adopt that under the QA project. And these are the some contribution stats I collected. So this mainly show that how like the activeness we have in term of the number of contribution or contribute. So if number of commit I say it is 497 in Rocky cycle and which is little less than Queen cycle. But still it's very good number. And review also we have around 2000 reviews doing in five, six months and we are solving like file bug 87 and we resolved 58 bugs. And if you see like the important part is the diversity of companies doing QA. And it's not like only one company is doing all this stuff it's all distributed. And yeah with AT&T Red Hat is doing since a lot of time NEC doing so JT Corporation also started back doing that. So that is good like we have a variety of companies and developers they are handling all these QA to links. And on the if you see right side bottom, so these are the current open request. So we have total open reviews around 600 and which are waiting for some meter 300 but on reverse side also 200 which is the something we should improve because 200 reviews waiting on reverse side. It can be possible like 50 or 40% of the reviews are stale or obsolete. We have to just close them. But still even if it's 50% saying 100 review request is open. So that is a big number I think. So that is something we are going to improve like you want to do this number as minimum as possible. So if you are like submitting any patch, if you are fixing something, so we should be able to like quickly respond on quickly merge that patches. And that is the one reason we are losing few of the key contributors since last one year from like HPE IBM and yeah but we have to see like if how we can solve these numbers we can make it minimize. And next I'll cover like what all things we have covered in rookie cycle and what all we are planning for the Stein cycle. So these are the rocky features. One thing we have done is Zool V3 native base job. So as you might know like all these gate job has been migrated from project config which is infraside on the each project site. And the base job like DevStack jobs or Tempest job, Grenade jobs those has to be owned by QA. And those are the base job which are 90% of each projects run them with the different different configuration and there are few say 10 to 20% project defining their own jobs. So these base jobs are very important and very base part of every project getting. So what we have done we have migrated those base job under the Zool V3 natives and DevStack is all done, Tempest is all done, Grenade is in progress which is under review and we should be finishing in Stein cycle. So once all these V3 native jobs are available so each projects can either have their concrete jobs or they can use directly these V3 native jobs. And next is testing the latest APIs. One is the we did like volume testing on gate we defaulted it to the V3 APIs. And previously it was V2 APIs and V2 API in Cinder is deprecated and V3 is the latest. So what we did we moved all these default testing on the V3 APIs and we have a single jobs which running on the V2 APIs test case. So we make sure that V2 is also working fine but everything else testing the latest API which is V3 and API micro version testing like it's many of the projects has adopted the API micro version like NOAA, Ironic, Cinder and I don't remember many other. So in every cycle they implement and they increase the API micro versions like NOAA is around more than 70 or Cinder is also around 60, 70. So what we do like what all micro version has to be tested on QA what all micro version test case has to be written on Tempest we make sure we write them within that cycle. So we try to catch the latest micro version testing whatever project is releasing on that cycle. And we did yeah, Kola Tempest Plugin Container source of is there so you have the Kola image where you have the Tempest and all the Tempest plugins available. So you can use that and perform the testing or I think there is one Kola job also doing that testing but that is only done at the setup level like bring up that image, install Tempest, install all the plugins and that's it. So just a sanity check it is but each projects can use that and they can extend to the more deep testing with that image. And more coverage for new feature and API in Tempest and DevStack like whatever feature gets implemented in each project like for Keystone it was application credential I think and NOAA did a lot of integration services between Cinder and NOAA like volume swap and attach volume new workflow and all. So we make sure we keep testing those new features and we try to cover more and more use case there. And Petrol so this is as I mentioned earlier this was a new project for doing the RBAC testing and it is not stable release is not done so but whatever things we have finished in Rokey is we are doing the stable branch testing in Petrol gate. So now Petrol is testing the policies RBAC testing against master plus queens and pike. So that is helpful because when we test stable branch things on Petrol master so we make sure that any project has not changed the policy which is in backward incompatible way from the previous release. So if they do that Petrol getting a test case going to fail on that job so we can capture immediately. And we started Neutron test coverage so Neutron was Neutron policy is really complicated in term of the documentation and all but yeah we started the Neutron policy test coverage also it is not completed and multi policy testing support this means like we have few APIs operation which covers the multiple policies between the different different project also even say for example NOAA swap volume so it enforce the NOAA swap volume policy then it called the NOAA Cinder and Cinder enforce the Cinder swap volume policy so there are two policy involved in the single operation. So those two policies testing support is also in Petrol now so you can mention both policy and check whether which one you want to fail it and confirm the failure and all. And other is a lot of update about the stable release and main is about the documentation we have covered we finished lot of documentation on Petrol and that is the very first step to move towards the stable release. So these are the item we did in Rocky and apart from that as I mentioned like we keep doing the gate stability work day to day so that is also kind of work we are doing in each cycle. So this is the item we are targeting for open stack stein and we discussed it during the Denver PTC. First one is rule v3 finish work for the granite which is very needed like we provide the granite base job and project start testing the granite job on that. And second priority is Petrol stable release. So Petrol stable release is the something we wanted to do in stein so that we can start doing the gate testing of Petrol on project side. So currently there is no project doing the Petrol testing on their gate it is just Petrol gate jobs are running on Petrol code only. So what our main goal is like for example we start with Keystone. So on Keystone changes we start doing the Petrol test case run also and if they break any policies so they should block by that gate testing. And to do that yeah first step will be our to release the Petrol as a stable. The other reason for that doing that is currently Petrol is implementing the test case for 5 projects which include NOAA, Keystone, Glance, Cinder and yeah Neutron doing shift doesn't have policy thing. And we are planning to cover only those project inside the Petrol tree and provide the framework to write the Petrol test case within the project side testing repository. For example each project has their tempest plugin repositories. So there they can write their Petrol test case also. But for that Petrol project will provide them the stable framework. So that is also one main purpose to make it a stable release in Petrol. And yeah more documentation and guidelines for tempest plugins. So this is the one I'll say big challenge for tempest plugin side like they always complain like we don't have a good documentation of on tempest side guidelines like last cycle we started the release of each tempest plugin. So that was a lot of confusion why we have to do the tempest release tempest plugins release and how we should do that. And second thing is how tempest plugin test case should be doing the testing on project side. Like for tempest what we do we do test the master and on the master itself we do test the old supported stable branch also. For example currently it is Okata, Py, Queen, Rocky plus master. So for stable branch we are testing in master. So which is making sure anything changed on project side is all working on all these four stable branches also not. So that is something also we wanted to we wanted tempest plugins side also should do that. And for that yeah we need to document and provide the best practices like that. I think Neutron already doing that. Few project doing so we have to provide a centralized guidelines there. Next is consuming all the tempest CLI in gate tempest CLI we break many times and something we have lacking with the unit test also which is in progress we are doing but something we are trying is if we can try to consume those tempest CLI in gate testing so that is the thing we can make sure all the CLIs are working fine day to day basis. And then scenario manager stable for plugins so that was also one request like load of tempest plugins they use the scenario manager in the tempest. So we try to make it stable for plugins and we so that we do not break them. And there is one feature like tempest smart cleanup features request so currently tempest doing a cleanup based on the saved file versus the file after test case things so that is very kind of risky and you will be easily able to delete your production level resources. So what the proposal is which is back in progress so the proposal is to provide the resource prefix and tempest will create each resources based on that resource prefix and based on that we can try some cleanup and it has the control that okay I am mentioning these resources and I know these resources are only created by test and tempest and those only will be this tempest cleanup CLI should delete. So that is under progress in spec. Next volume strict validation testing using json schema so for compute we already doing that and that is very helpful for interop also and even for us it is saving our lot of code also and it is making really automatic validation on that. Keystone system scope testing that is the one thing like Keystone has implemented the system scope in policies and having the support in tempest or in dev stack is the very important step to adopt system scopes in all other projects also. So that is in progress and I have a lot of testing past there last already submitted the system scope testing support thing and should be like next week or next to next week we should be able to merge that and few new initiative we have proposal for new QA project that is control plane testing and we have the responsibility of supporting the some open stack CICD platform also like migrating the gate jobs to new distribution we are trying with 18.04 and image update which used to be done by infra but now QATM will be happening. I will just quickly cover because time is less and these are the things beyond the Stein so extreme testing these new projects things and RBEC testing it on each project site and these are cross project work Joule v3 migration will be keep doing like if there is any new request that okay this is the job should be declared as a base job in QA things so we will be doing that plugins help and yeah CICD support we will do that and this is how you can give us feedback we have the onboarding session today at 5.10 you can join that and otherwise we have the feedback session also there is a link which is I think tomorrow 11.30 or 11.40 and you can ping us on IRC mailing list and you can contribute like we have lot of items which we need volunteer and as I said we lost few key contributors so if anyone want to contribute and help and it doesn't need to be a hundred percent even if like within a one week you show up like two hours three hours want to help on any of the items so that will be a great help for that and if you are doing something downstream things which you wanted to discuss and wanted to do on upstream that will be a great contribution in QA so yeah OpenStack QA IRC channel we are almost available on its time zone I think I am working from Tokyo time zone and Tila is there from Europe and US time zone I think we don't have right now anyone but yeah you can even send a mailing list also if you are not finding us on that QA channel so yeah I will just open up for any question anyone has so under QA each tool you are saying is all with the different purpose so there is no more than one tool doing the same thing so that is we are making sure but thing is like if we if we you are coming like with the different model or different architecture for doing data plane testing and there is another one also doing for data plan or control plane testing and based on their advantage disadvantage we can collaborate between them but as of now we have all these tooling doing their own specific work there is no overlap between any of these which one Rally is not part of QA testing so that is a separate project but yeah it is not under QA yeah means I remember the history when Rally was started so we discussed a lot to put that under the QA but I think that was Rally team decision to make it as a separate project only not under the QA so that was how it started the Rally as a separate project otherwise we always wanted to have it under the QA but Rally used Tempest to run the test case which one each testing like frame order testing how happens when it gets under some frame of condition so that is not there till now but the thing is so under the QA thing if like you have any idea or proposal for introducing another sub project under QA so we are ready to adopt that but the thing is each QA tool each QA projects like all these 2022 they all have a separate sub team like Tempest has separate team DevStack has separate so there might be some overlap between if a single developer working among more than one tool but the thing is if there is any proposal of the new ideas new project we are ready to open but that project has to maintain their own team under the QA stadium or QA program yeah the one good example was extreme testing and we discussed it I think since two years the main problem we are facing we are not having a dedicated team who can drive the extreme testing project there is one person Sam from Masakari and he is not able to put bandwidth and so I will say currently zero but a lot of people a lot of operators are looking for the extreme testing and we are really happy to proceed on that but we really need someone to drive that and that is the only thing yeah it was started since Barcelona when Mirantis people was there were there and then it's all disappeared yeah we started in Boston also and but two three people started doing POCA and all stuff but after six months that also got disappeared so that is the thing like we are not having a dedicated people even one or two people who can like keep it working on extreme testing okay so I think we are done with time thank you everyone and we have on boarding session I said in the evening 5 10 and happy to come there and you can ask even any question you want to ask how to contribute or anything related to QA we'll be there thank you