 Good morning Catherine. Can you introduce yourself, please? Hello, my name is Catherine Dip. I am the project team lead for the revstack project of the OpenStack Newton cycle. I currently work for IBM at Silicon Valley Lab, California. I am the performance and test engineer at IBM. Excellent. Can you tell us a little bit about the project you're leading and you know the roots of the projects and why it's so important for us? Okay, so revstack is the source of tools for OpenStack into our testing. So we all know that there are so many components in OpenStack with so many configurations that people can use for each of the components. The combination of the configuration and the components is tremendous. So in the off is a topic is a goal that the OpenStack community really need to achieve so that when we say OpenStack cloud, there's a minimum core requirements that all OpenStack clouds will be able to execute. So as a tool for OpenStack into our testing, the revstack projects have two major components, the revstack clients and the revstack server. The revstack client is the tools that the user or the vendor can download so that they can test their clouds on-premise. So once finished testing, they can upload the test results to the revstack server. The revstack server is currently hosted at revstack.openstack.org. So this is the official test results collector for reporting OpenStack into off data. It is also the source to store the data that is used for OpenStack power logo applications. This means that for any vendor who want to apply for the OpenStack power logo, they will have to run the revstack test, submit the result to the revstack server and then provide this link of their test result along with their application for the power logo application. Great. So based upon the last summit, what are, you know, two or three hot topics which came out for the revstack? So during the Austin Summit, one of the hottest topics that was discussed is about expanding the scope of the revstack project. So far the revstack project is pretty much concentrating on delivering the requirements set forward by the DevCord committee. This is especially true in the area of defining the must pass test and also the pass fail criteria, namely the DevCord guidelines. There I thought that revstack, being an OpenStack into off tool set, should allow vendor to define own test cases that they think fit it and also at the same time allow a way to upload the vendor to find pass fail criteria. So this is a very interesting topic at the same time. It's very controversial. It is especially in the area that if revstack allows vendor specified test and guidelines, how would a user coming to revstack being able to clearly differentiate the guidelines defined by DevCord versus the vendor specific guidelines? So we spend a lot of time on this topic. At the end, the consensus team agreement is that we will continue concentrating on delivering DevCord requirements during the Newton cycle. But at the same time, we will lay down the fundamental features that we see it would be needed to expand the revstack scope in the upcoming OpenStack releases. Excellent. So with respect to the current release or the work for the current release, the Newton one, what are top two or three priorities for the group? So during the summit, we got a lot of the feedback from the users that currently there is no way to associate the test result upload at the summit to the specific vendor or a product of a vendor, because currently the data can be upload to revstack server anonymously with a signature. However, the data sharing is always anonymously. So with that feedback from the user committee, in the next cycle, our top priority will be enabling vendor and product registration so that with that, we would be able to associate data with a specific vendor or a specific product. Okay. So that's one top priority. Any others you would like to share? The other priority is about data archiving. Like I said earlier, data can be upload today anonymously. So therefore, we have a lot of data upload up there. Some of them are very meaningful. Some of them are not. So we need to design and implement a data archiving strategy so that at one hand, we can clean the data, but also maintaining the integrity of the data itself. Excellent. So next question is respect to the themes and how the project deliveries fit into those. The top five themes for the open stock are scalability, resiliency, manageability, modularity, and interoperability. So clearly, interoperability is dependent on revstack, but I want to give you a forum to discuss how the revstack impacts or delivers on the other things also. Yes. So as you said, interoperability is our priority. And the priority is we will enabling open stock interoperability with using data driven methodology. That means that the more meaningful the test that we define, the better we will be able to test and ensuring that interoperability would be a reality for open stock. So testing, defining the test, the must pass and the pass fail criteria and collection of the data are the vehicles that we will use to enable open stock interoperability. Excellent. Any other things you would like to add for either themes or the priorities or kind of longer term direction of the revstack? Yes. So as I said earlier, our major access is the data. So I really encourage the community to really run the revstack test for the end product. We know that the underlying test suite for revstack is Tempest and all development environments will run Tempest test. But what we are talking about here is the end product, running the revstack test on the end product as a user and upload the data to revstack server. The more data we collected at the revstack server, the better chance for the Devcore team to perform analysis and also with that, they can defy a true and practical open stock core set of implementation out there for the community. So we really encourage the user and the community to test and upload the data. At the same time, we also would love to have more contribution to the revstack project. We are a very small project and we love to have any contribution that we can get. Excellent. Thank you. Catherine, one thing kind of struck me. Your revstack is data driven and the more data you collect, the better assessment and better results we can provide to the community. So any additional data or additional extension to the collected data, the revstack is contemplating or thinking about? Yeah. So right now, if you look at the Tempest test suite, the API test suite, there are about 1600 test cases. But if you look at the required test from the defy by Devcore committee, we are about 300 tests at the most with the upcoming test case. So we understand why the required test has to be small to begin with, because it is, we have to start something that we know that is core for everyone. Because of that, a lot of tests of the test result upload, I really only test the required test. We really love to have everyone to test the entire API Tempest test suite. With that, we would be able to defy a much more meaningful must pass test in the upcoming releases versus what we have been done so far is pretty much based on what the scoring of what we think it should be. With more data, we would be able to do data analysis. We are not there yet. Excellent.