 Hello, Guten Tag. So, welcome to join us open-stock storage project update today. I'm Kotatsu Yuzaki, working for MTT in Japanese telecom company and has been taking a lot of storage PTL since Queen's release. So I'm really happy to share the update today. Thank you for coming. So before talking about the recent storage activity, I'd like to explain what's storage here. So this is a storage description. The storage is a project to prepare the application environment for users. This sounds like the Nova VM, Magnum Control, Queenly functionality as a service in the open-stock. But the characteristic of the storage is that, as you see, it depends on the open-stock object storage switch. So storage can enable users to run their applications inside the object storage system. So storage uses the physical environment of your object storage system. And the reason why storage is doing so is the storage is focusing on the efficient computation for this processing. So basically, the transfer cost, the transfer cost from the storage to the computing environment should be really high. So and the storage attempts to reduce the cost. So you can imagine if you want to process your data in the virtual machines, that requires to read a whole bunch of data from the storage system. But if you deploy the open-stock, you need to cost the transfer cost from the storage system into your VM using your network. So when you are using storage, you can move your cost into the storage system. So it doesn't spend your networking bandwidth in the outside of the storage system. So that's really effective, I think, I believe. And also, I would like to introduce some great functionality of storage. The storage is a very easy deployment of your user codes into Swift. That is because the requirement to deploy your code into the storage is just to upload your code into Swift. So I think Swift API is very easy to upload, you know? So if you want to make your application, just upload your code into Swift. That's OK. And also, the great functionality of storage is that code will run in the sandbox. We are using the Docker container inside of the Swift. So and that basically doesn't support any reachability of the network to outside of the container. So that sandbox is purely safe from your storage system. So storage attempts to save your storage system environment. And you can deploy your code very safely. And this is the current storage state of the contributors. The project is starting from Aaron Lomb, who is the progress PTA, and we contributed, entity contributed to improve the project. So the half of the contributors is still entity. But the point I'd like to focus on in this slide is the percentage of entity is decreasing from the past presentation I had in the Vancouver. So that means that the other contributors is coming into this community. So I think that shows being good health in the open source community project, I believe. OK, you understand how storage works and the current state of the storage. So in this slide, I'd like to explain what's changed in the localities. Sorry, this is not so much progress in the localities. But basically, that is because we are focusing on some PIC3 compatibility in the storage project. Storage has some code written by Python 2 and P3. And in the Queen's release, we are developing, moving the code from Python 2 to Python 3 compatible. But still in the localities, we need to improve the P3 compatibility. And basically, we finished the P3 compatible codes in this localities. But that is only server-side currently. So that server-side, that means the storage project inside of the other provider that works with the P3. But we still need to change some from Python 2 to P3 if there are a couple of things. One is switch. Switch requires to be P3 compatible to work on P3 environment. And the other thing is the storage still doesn't support user-defined P3 code. So storage is basically supporting the two languages, Java and Python. But currently, the storage invoked the user-defined code as Python 2. So we need to still improve the logic to... User can choose what runtime you want to run with the Python 2 or Python 3. We still need to be updated at that point. So, and then from here, I would like to explain what we can expect in the stainless. That is starting from last September, PTG. So there are three things I would like to expect to improve. The first item was from the OpenStack community mailing list in September. So that's March output with a single input use case. So that's so interesting, I think. The mail also wants to deploy an application that saves March objects by single object put in the storage system. For example, the users in his work want to store objects into OpenStack Swift. Then also they want to create a couple of objects. One is the low, just store the low object. And then the other is the compressed object. So they want to couple of objects in the Swift. And then storage currently supports multiple stream inputs and store the single object. That use case is sort of comparing the different objects or merging the multiple objects into a single object. But the March object approach, that means the March put of March project storage is not currently supported. So to apply his use case, we need to improve our storage like that for, yeah. So I would like to follow up the new application model. So I'd like to encourage his work in the storage community and hope it could work by the end of the stream release. That's the first item. The second one is the important thing to, very important thing. Since storage prepared the environment, the user code run inside in your storage system, we should think of the security risk and performance considerations. Speaking of the performance, I don't think to mind that because modern content run time supports resource management. Like Lansi, limit the Linux resource like CPU memory, so you can set some resource management tools to limit user environment. But the security risk is also is really required because the storage basically run in the container environment in your storage system. So basically that's controlled any risks in the container. But as you know, we have some major security instance like the meltdown spectrum. So sort of that, we need to make the, make storage more secure, I think. So I'm now planning to employ some more secure run time like OpenStack Foundation wants to make the, like Cata container. So I'd like to prepare the experience in our storage community for the Cata container use case. And the last thing is just what I said in the previous slides, we would like to support SPICY for user-defined code. And as you know, perhaps some of these, you know, storage are really looking forward to more contributors in this community. So beyond the staying, I would like to improve more storage actively in the OpenStack community code. And if you can, if you want to get more information, storage is now in the Project Navigator that was in the Loki. And Teri is very help-free managing this one. And currently, storage is clearly in the add-ons for SIFT. That's very clear information for users. And this one is how to give feedback or contribute. So we have the OpenStack Storage channel and mailing list, I can see. And if you want to, some stuff you want to improve in the storage, I'm really welcome to, if you contributed in the storage project. Thank you. Questions? Or it might be, we are running out of time. No, no, we have 20 minutes. Oh, sorry. We have the five minutes left. Sorry, I thought 15 minutes, so I should explain more detail. OK, thank you.