 Hello everyone. My name is Abhishek Kikani and I am working with Red Hat as a senior software engineer. I am here to provide a project overview and update for Glass. I am serving as a Glass PTL for last couple of cycles and will be continuing for Apollo B cycle as well. So basically I am associated with Glass since Icehouse, mostly around 6 years and was involved in new input API. Then some of the new features added to Glass like hide old images, then multiple stores support different kind of stores, multiple stores for Glass. Then importing image to multiple stores, copying image, existing image to multiple stores etc. So in this session we are going to see what is Glass and what is currently going around Glass and what are the planning for current Apollo B cycle of Glass. And in the end if we have any questions then we would like to answer that as well. So let's start. So basically what does Glass do? Glass is the OpenStack image service. Glass provides services and associated libraries like Glass Store, Browse, Share, Distribute and Manage bootable disk images. Other data closely with initializing compute resources and metadata definitions. So basically Glass is one of the core project of the OpenStack. So as I said as it is one of the core project of OpenStack, it is founded during the Bexar release of OpenStack which is the second release of OpenStack. Let us survey indicates that Glass is deployed in 95% of clouds in production or test phases. New features and enhancements for Victoria. So during Victoria, actually Glass now supports multiple stores. So you can have different types of stores like combination of different types of stores like RBD, then file, RBD plus file etc. And in Usuri we have added features like we can import images, single image into multiple stores at the time of creation as well as we can copy existing image into multiple stores. So for example if we are using say pre Usuri version, for example train and you want to upgrade your cloud to Victoria, then you can copy your existing image into multiple stores using that feature. So in Victoria we have worked around a little bit on fine tuning that copy image feature where we are now allowing copying of unowned images by policy. So administrator can set this policy in the policy.yml or policy.json file to allow users to copy images which not belong to them. So enhancement in multiple stores features administrator can now set policy to allow user to copy images owned by other tenants. So if you there is a detailed spec link even here, then we have sparse image upload. Basically RBD and file system drivers now supports sparse image upload means sparse image upload means it ignoring null void sequences and upload only data itself at a given upset resulting in saving your storage. So there is one config parameter, if you enable that config parameter then you will enable this sparse image upload. You can find details in the given spec. Mixing sender driver compatible with multiple stores. So basically when we have added multiple store supports features at that time there was now provision for configuring multiple sender backends as a glance load driver. So in this Victoria cycle we have added this facility where in sender if you have different backends exposed using volume types you can configure a different store in glance for each of the volume type. So now you can have different sender drivers multiple sender drivers in glance as well. You can find those details in the given spec. So basically this is the features and enhancement we have done for Victoria. Apart from that there are many bug fixes and some small features like you can now set virtual size to the image. Not you, a virtual size to the image can be set automatically at the time of creation. So basically this can be used by NOVA and sender to avoid running heavy operations like KMO image info to calculate virtual size at their end. So this kind of features has been added to Victoria as well. So you can go through the Victoria release notes to find the detail information about what we have done in Victoria for a glance. This is just the basic highlights. Now we will go to possible features and enhancements for Volubi. So this is what we are planning to do for a glance in Volubi. Image encryption and decryption. So user can upload encrypted images to glance. Basically you can find more information in the given spec, glance cluster awareness. So this is again related to H framework in H deployment or in HF proxy deployment. You will know how many glance API nodes are running. So basically the use of this is that when you have multiple glance API nodes running and you are using glance direct import method to create the image, then it is not guaranteed that your all calls of glance image import will run through one API node only. So it is possible that your create image call goes to node A and staging call goes to node B and import call goes to node C. And as data of your image is on node B and import call is on node C, it will fail as it will not found the data to import into the package. So to avoid this situation we are coming with glance cluster awareness where it will know that where exactly is your data is and it will divert that import call to that particular node. So that is we are going to work then move cache under API. Currently cache is managed by admins and with a different utility called as glance cache manager. It is totally a different plant based tool which we are planning to move under API. So we are going to introduce a new V2 endpoint to handle cache related operations. And those commands will be made available in glance, Python glance plant as well. So basically existing glance cache managed tool will be deprecated and removed and it will be available under V2 API. Hence Balabi. Apart from that we are planning to complete community goals to implement role based access control system. And bug fixes if in. Apart from this you can find the various topics we have discussed at given Etherpad. So, this is the PTG etherpad where you can find the discussion topic from the discussion as well as the recording of the session each session. So, kindly go through it and let us know if you have any questions. So, basically that is it from the current cycle point of view. Now we definitely need your help we need more contributors particularly if the features people want are going to be implemented. So, at the moment basically Glanstein is hardly of 4 to 5 contributors who trying to implement these new features and it is hard for us that if there is any new feature comes in then it is very difficult for us to manage. So, if you are interested and if you are planning to add new features then kindly contact us and we will be helping you or whatever you need from us. So, if you want to contribute then there are lots of opportunities depending on your interest you can contribute in coding, fixing bugs then reviewing code so review reviewing also best part of the contribution improving documentation improving test coverage improving test test coverage etc. So, basically if you are interested in contributing or if you are interested in Glans then you can also join Glans weekly meeting which happens every Thursday around 1400 UTC at OpenStack-Mitting IRC channel so and if you have any questions then you can talk to us on IRC using OpenStack Glans IRC channel as well as you can communicate with us on OpenStack discuss mailing list as well yeah that is it from the strategy update. Let me know if you have any questions we will meet in the Q and A session after the presentation thank you have a good day.