oVirt and OpenStack Storage (present and future)
Simoncelli, Federico
This session will cover the current status of integration between oVirt and the OpenStack image repository (Glance), analyzing the motivations, the low level implementation (including Keystone authentication), and ideas for the future. This presentation will include also an ample part dedicated to the future work and ideas to introduce the integration with Cinder (the OpenStack volume manager). * Introduction to oVirt Storage Architecture * Glance Integration Motivations * Glance Integration Deep Dive * Ideas and Future Work on Glance Integration * Future Integration with Cinder * Roadmap
 Hi. My name is Federico and I'm working for Red Hat in the Overt Storage group. I'm here to present you the current integration between Overt and OpenStack storage. So the presentation is mostly about the integration between Overt and OpenStack, but I will give you a short introduction about Overt and OpenStack just to get you started on what they are. Then I'll go over the present current integration. So what we have today with the Overt and Glance integration, always in the storage side, it's important as part of Glance images and current limitations, and then I'll go over what we will have in the future with the Glance, future integration, new things that we can add and improve there, keystone authentication and how that is also involved with storage somehow, Overt and the similar integration in the coming future. So just to start, what is Overt? This is the definition that you can find around pretty much everywhere. Overt is the virtualization management application that manages hardware nodes, storage and network resources in your data center in order to deploy virtual machines. It's open source release under the terms of the Apache license, and this is a quite old diagram that you can find, but nothing like we have some new things going on, but this is pretty much the idea. We have two different web interfaces, the administration portal and the user portal to interact with it. Rest API, then a JBus application that is the engine that controls the data centers, and then on each node of the cluster, you have VDSM that takes care of controlling those nodes and make them available and usable from the engine to manage basically everything from storage's network, anything that the virtual machine would need to actually run. What is OpenStack? Well, it's cloud computing project that provides an infrastructure as a service and also controls large pools of compute, storage and networking resources. Apache license is governed by a foundation that was established in September 2012. There might be some overlap in the two projects. They are tailored for different workloads, so today it makes sense to make them living together in the same infrastructure, so that is why we need to integrate them. I won't go much further into the differences, but because the time is really limited, so this is the idea. So at the present time, you need some interaction between the two. And as we see OpenStack can have three different areas of projects, compute, networking and storage. We will focus on storage obviously in the scope of this presentation, and more specifically, we'll look at Glance and how that can benefit in the integration with OVR. So what is Glance? Glance provides services for discovering, registering and retrieving virtual machine images. It has a RESTful API for querying VM images metadata and actually downloading that image. These images can be thought as templates if you're familiar with that concept in OVR. It can also be used as backup and has different backends eventually, ranging from the simplified system to Zwift. It supports several disks formats and containers formats. Disk formats, as raw, Qco, ISO and container formats as bare and OVF. You're probably familiar with these if you already use also OVR. It supports image metadata. Basically, these are some additional information that you can have on the images that are stored in Glance. You can pretty much go over them yourself. I just mentioned two of them because they're kind of important in the integration. One is the size. The size has to be intended as the real size of the image of the file that is transferred, uploaded or downloaded from Glance. The status, there's a special status that is queued and it is when you have the metadata that is raiding Glance, but the image is not there yet. These are important for the integration. We also have some additional properties that are now more standardized in version two about the some additional information about the image as the architecture, the hypervisor type and some other information. We decided not to use these common properties to store OVR-specific information because we wanted to actually have full integration with OpenStack. That information wouldn't have been consumable by OpenStack. We are not storing any additional properties in Glance for now. The interesting use cases for OVR that we wanted to integrate with are importing and exporting single images or templates from and to Glance for the interoperability with OpenStack. We can be used for backups of images of VMs and basically also use it as ISO domain. They overtest something specific that is called ISO domains that are used to store ISO images for the VMs, but we can try to leverage Glance also for that. The final goal that is really ambitious is to import and export full VMs and templates supporting complete VM definition, multiple disks and snapshots. For the initial phase, we just focused on the first point here, which is importing and exporting single images. Basically, that integration has been implemented using something that came along in OVR-33 that are called external providers. In OVR-33, we introduced the concept of external providers that are services that we are able to understand and integrate with. Basically, both OpenStack, image, Glance and network and also Forman have been integrated as external providers in OVR. We have a new tab in the web admin UI and this is where you can add new external providers and this is how it looks like when you have Glance integration here. The Glance external provider, when you define it, you have several fields that you have to fill in, name, description, the URL of the service and the authentication. You can also test the connection at that point. This pretty much gets you started with it and as soon as you add this Glance external provider, you will also find a new storage domain in the storage tab that is exactly the Glance domain that you just added. They are somewhat special. They basically are unattached to a storage pool. Up until now, we always had storage domains that were attached to a certain data center. In this case, they're not attached to any specific data center and you can use them, in fact, to import and export images between different data centers. For some operation that we do from the OVR perspective, we needed to interface with OpenStack services, but OpenStack provides, at the moment, only Python bindings for that and Engine in OVR is written in Java. So we also started contributing to OpenStack Java SDK as a mean of communication between the Engine and the OpenStack services. We tried to stabilize it and add the support for things that we needed. So we can dive in one of the operations that we are actually interested in in the integration, basically, and the Glance image discovery. So we want to list the images that are provided by the Glance service and basically, when you select the Glance storage domain in the UI, you will have a list of images that are available or that you can access on that Glance domain. What happens behind the scene is the OVR-Tangent that goes to Keystone to request the authentication, gets a token and then goes to Glance, the Glance external provider that you defined earlier to get the image list. There's some kind of caching involved here and then it's displayed in the UI, as I showed you before. So once you list these images that are available in the Glance service, you probably want to import them. So what you do, you can select one of the images and you can basically click the new button that is import and what happens is that you will be prompted with a dialogue where you can select what data center to use and in which domain you want the image to be imported to and what quota to use for that image. And what happens behind the scene is Engine again going to Keystone to request a token. It goes and tries and discovers the image metadata to Glance so that it can create the internal representation of these images inside the Engine. And after we have that representation of the image inside the Engine, we go and issue the comments to be the same to create a new volume. So that's the container where we will store the image and then we will issue a download image that will start the data transfer from Glance to VDSM. So VDSM will go to Glance and download the image data into the volume that we just created. So there's a special case where basically what Glance didn't provide was the image virtual size. So as I said before, basically what Glance gives you is the size of the image. This means that you are not able to discover in advance how large, how big is the image once you attach it to the VM. So how large is the disk that the VM will see. This is needed for the internal representation that we keep of the disk inside the Engine. So we also need this information. And at the moment, what we do is we go and download the initial part of the image and we discover the Q-Coader and we peek for the virtual size of the disk. So Glance might provide some additional information about the virtual size in the future, but this basically works also for regular HTTP. So this is more compatible just with also other HTTP servers that are serving an image. And we will see later that we can support also that. How this imported image looks in OVRT. It's basically, it can be found in the disks tab and basically the metadata is maintained, most of it. And then some other information are forged with defaults, like for example, the interface that is VRT-U. And basically at that point, you can create a VM on it or create a template. In 3.4, we automated the process so it can be imported right away as a template. And so at this point, we can also look at the other operation that is symmetrical to this, that is exporting disks to Glance. It's pretty much the opposite. So now you go to the disk tab and you select one of the disks and you can export them to a Glance storage domain. You will be prompted again with a dialogue where you can select the Glance domain. And that behind the scene will pretty much do the same. Engine will go to Keystone and well, it will queue the image. As I mentioned before, basically we prepare all the metadata about the image in Glance, but the real upload is done by VDSM. In fact, the engine sends an upload image request to VDSM that then streams the data from the volume that we have in our shared storage into Glance. In Glance, these will look like as a regular image. Some of the metadata is maintained like the name, for example. And basically these is based on the VDSM support for sharing images that has been added specifically for Glance, but it can be leveraged for other methods of transfer of images. And one, so we have two new APIs that we use in VDSM that are download image and upload image. And we can issue different methods for the transfer. And one of these is HTTP that is the one that is used for Glance. And we can also specify additional headers to it. So, well, as I said, in this way we can support both for Glance and also for all the other HTTP servers. There's another special case that we have to cover that is when we download an image that is QCO on a block domain. So this is team provision means that we create volumes that are, well, on block domains we use LVM. And we create volumes that are not entirely large as the virtual size of the image. We just create them with chunks that then are extended as the VMs start using it. In fact, to implement basically team provision on block devices. So what happens is that the volume that is created is just probably one gigabyte in size. And what happens is that VDSM has to go to the HTTP server or Glance and download and peak for the, in this case, the actual size of the file that will be transferred and it will extend the volume to the correct size before downloading it. In those, in all these mechanisms we have few limitations. We are at the moment limited to not being able to export images with multiple volumes. And this means that we cannot export this that have snapshot or that are based team provision on a template. And this is because basically we want to export one one image that is full contained while we are using external snapshot for volumes. Right. And so it means that if we want to export these these images, we would have to collapse them, but I have one slide about that later. There is no live VM disk export. Obviously the VM should be down. But uploading templates is always possible. There's no sparse support on file domains for format. The images are always preallocated. Means that we are not punching holes in zeros in series of zeros at the moment. So we download them. Obviously compression would would help in this case. And we cannot resume partial download of the image. So we are moving now to the future. And in fact, these are the ideas for the future improvements of glance. We can add a few simple operations like deleting images, the chain online squash. That is what I was speaking about. So to support this that have a snapshot, upload image compression to save bandwidth and also supports sparse. That's probably while integrated upload and download via web admin and use report. So you can upload images or download images from your desktop. And they will be streamed into the volume. As I mentioned earlier, store ISO images in glance and use them natively in Oviart as ISO domains basically. And import and export full VMs and templates. So just few words about the squashing and compression of multiple volumes images that we have in Oviart. So as we see here, we have an image that has two snapshots. And basically the base volume can be either raw or Q-code. It doesn't matter about snapshots one and snapshots two or two Q-code volumes. And in order to basically squash the image and see just the latest version we have to compute the map of the clusters that are scattered around these three volumes. And there will be the support for this in QMU image. It will give us a map of blocks that are scattered around in these volumes. And then we will read them sequentially. And after bufferizing them, we can compress them and stream them. So this is just one of the idea on how to deal with the problem without using some additional space where we basically store the image just for the upload. Other improvements in the era of Keystone are, well, in Oviart 3.4 we introduced a large refactoring of authentication and directory services. Authentication gives you the identity of the user and the directory service provides a set of information about the user. These have been decoupled. So now you can use them mixing and matching. Basically, you can use the Kerberos authentication with the LDAP directory service if you want to or any other combination. And Keystone, the Keystone authentication has been sketched as one of these backends. But at the moment we have patches upstream. And if anyone wants to contribute or take them and finish them, is welcome too. So but this is the current status and we'll probably have it in the future somehow. The interesting use cases for this integration is that we can consolidate the authentication in Keystone for both data centers, Oviart and OpenStack. We can also associate Keystone users and tenants to Oviart entities and well, basically give specific permissions and roles to objects that we have in Oviart like VMs or images or disks. And reuse the same Keystone identities when we are interfacing with these services, with the OpenStack services. So this is probably how it will look like. Authentication goes to Keystone and you will be granted the access to the web portal in this case for this picture but to the REST API or anything. And then supposedly later on you can go to the services, reusing those authentication credentials and the token probably. Another service that in the storage area that we want to integrate with is the Cinder service that provides basically an infrastructure for managing volumes since Folsom because previously it was part of the compute node of Nova. Now since Folsom has been separated into a specific project itself that is Cinder. And volumes are persistent read write block storage devices that most commonly are used through ice cask, right? Now we have some other that are slightly different, for example, glass surface that are attached as a shared, are mounted actually as shares volumes. So and they have a life cycle that is independent from the VM instances. So you can create VMs that are using these volumes and destroy them and create other new instances that are using it. But they are the coupled, right? Supports a snapshot and this snapshot can be used for new volumes. And backups are generally archived in Zwift. The use cases in over 12 week we can think of importing and exporting images from Cinder. But probably the most interesting one is sharing Cinder volumes for the interoperability with OpenStack. And in that way we will leverage the Cinder volume drivers that they have for the support of storage appliances for IBM NetApp, hardware, Dell, EMC and in this way gain also the storage of loading capabilities that are coming with the Cinder volumes. And we can also think to unify, snapshot and backup strategies in your data center also gain for both Oviart and OpenStack probably. One part of the integration would be to again going to keystone for the authentication and do some simple operation like listing, creating and deleting volumes in Cinder. And later on when we actually want to use them, we will after we created or well identified the volumes that we want to use with some Oviart VM, we will either set up the connection or create VM, we'll embed some way of connecting to the storage that is provided by Cinder. So this is pretty much what we are planning as future integration with OpenStack. I want to mention that we also have a talk tomorrow about networking, integration between Oviart and OpenStack in networking. So that will complete the picture. And I have useful links for you in my link list that if you're interested. And there's work in progress of having GlanceOviart.org as a requisitary for images that you could start downloading yourself for your Oviart instance, right? So basically we will have images of the most important distribution there and you will be able to from your installation to download these templates using Glance. Any question? Sorry, wait for the mic. Hello. Hello, you do think the integration with Cinder will take time? We are planning it for the Oviart 4 release, seems to be. So that's pretty much the time frame. The Oviart 4 release. That's a function in Cinder for example called Cinder backup. Are you trying to go on to support such things? We have not specific details exactly of how much of that work. So basically how much time do we have? Not much. Okay. So basically the problem in the integration with Cinder is that we have many flows of complex operation that we do on storage that are specific to Oviart. Like for example, live snapshots or live storage migrations. These are in the current implementation are really tailored to how the images are stored in the storage and how they look like in Oviart. And all these flows might, they don't map at all to Cinder. So an easy integration with Cinder would be to leverage what we have already today that are direct lands. So we already support direct lands and we have some operations there that we support. But that's the easiest integration. So you basically can use Cinder volumes as direct lands. So that's the easiest one. For all the other complex flows, it will require time. Definitely. Thank you. Okay. Okay. Talk about 4.0, the release 4.0. Is it related to Red Hat Linux 7 or does the schedules match or is it not allowed to speak public about that? So for EL7 support, we're planning to add it in Oviart 3.5 actually. So as using an EL7 host, REL7 or CENL7, as the host is planned for Oviart 3.5, for the engine itself to run, probably it will take a bit more time. The interesting part is probably using it as a host. Okay. But can we expect that it's in the Red Hat way like it used to be where you do a lot of back porting like with the kernel or stuff like that, that you get some features from the 4.0 release back ported to the actual Red Hat package of Oviart? Usually it's not an issue so much for Oviart or Rev, which is the Red Hat version of it because we usually rebase each minor version so we don't have to do a lot of back ports for features. Most of the back ports are for stabilization and we're doing a lot of them in upstream Oviart as well. We just have Oviart 3.3.3 stabilization release for the current Oviart release. So a lot of back ports are done both upstream and downstream. That's too far to say. I don't know the schedule. I joined a bit late but I missed the thing about the LDP integration and all those things but I've got a lot of customers which are still, please don't beat me up, which are still running yellow pages through NIS which are on a plain Unix user backend. Without any LDP integration we got, I did some POSIX ACLs on that to extend the possibilities of groupings and stuff like that. Is there any integration plan for just simple Unix user backend which are a bit extended regarding POSIX ACLs? You can use, as Federico mentioned, there's a lot of organ refactoring, the authentication backend. You can write a plugin for anything now basically. So now it's done, right? Yes, we're ready to go ahead E, we're pulling all of our stuff down here because it looks
 Hi. My name is Federico and I'm working for Red Hat in the Overt Storage group.  I'm here to present you the current integration between Overt and OpenStack storage.  So the presentation is mostly about the integration between Overt and OpenStack,  but I will give you a short introduction about Overt and OpenStack just to get you started on what they are.  Then I'll go over the present current integration.  So what we have today with the Overt and Glance integration, always in the storage side,  it's important as part of Glance images and current limitations, and then I'll go over what we will have in the future  with the Glance, future integration, new things that we can add and improve there,  keystone authentication and how that is also involved with storage somehow,  Overt and the similar integration in the coming future.  So just to start, what is Overt?  This is the definition that you can find around pretty much everywhere.  Overt is the virtualization management application that manages hardware nodes,  storage and network resources in your data center in order to deploy virtual machines.  It's open source release under the terms of the Apache license,  and this is a quite old diagram that you can find, but nothing like we have some new things going on,  but this is pretty much the idea.  We have two different web interfaces, the administration portal and the user portal to interact with it.  Rest API, then a JBus application that is the engine that controls the data centers,  and then on each node of the cluster, you have VDSM that takes care of controlling those nodes  and make them available and usable from the engine to manage basically everything from storage's network,  anything that the virtual machine would need to actually run.  What is OpenStack?  Well, it's cloud computing project that provides an infrastructure as a service  and also controls large pools of compute, storage and networking resources.  Apache license is governed by a foundation that was established in September 2012.  There might be some overlap in the two projects.  They are tailored for different workloads, so today it makes sense to make them living together in the same infrastructure,  so that is why we need to integrate them.  I won't go much further into the differences, but because the time is really limited, so this is the idea.  So at the present time, you need some interaction between the two.  And as we see OpenStack can have three different areas of projects, compute, networking and storage.  We will focus on storage obviously in the scope of this presentation,  and more specifically, we'll look at Glance and how that can benefit in the integration with OVR.  So what is Glance? Glance provides services for discovering, registering and retrieving virtual machine images.  It has a RESTful API for querying VM images metadata and actually downloading that image.  These images can be thought as templates if you're familiar with that concept in OVR.  It can also be used as backup and has different backends eventually, ranging from the simplified system to Zwift.  It supports several disks formats and containers formats.  Disk formats, as raw, Qco, ISO and container formats as bare and OVF.  You're probably familiar with these if you already use also OVR.  It supports image metadata.  Basically, these are some additional information that you can have on the images that are stored in Glance.  You can pretty much go over them yourself.  I just mentioned two of them because they're kind of important in the integration.  One is the size. The size has to be intended as the real size of the image of the file that is transferred, uploaded or downloaded from Glance.  The status, there's a special status that is queued and it is when you have the metadata that is raiding Glance, but the image is not there yet.  These are important for the integration.  We also have some additional properties that are now more standardized in version two about the some additional information about the image as the architecture,  the hypervisor type and some other information.  We decided not to use these common properties to store OVR-specific information because we wanted to actually have full integration with OpenStack.  That information wouldn't have been consumable by OpenStack.  We are not storing any additional properties in Glance for now.  The interesting use cases for OVR that we wanted to integrate with are importing and exporting single images or templates from and to Glance for the interoperability with OpenStack.  We can be used for backups of images of VMs and basically also use it as ISO domain. They overtest something specific that is called ISO domains that are used to store ISO images for the VMs,  but we can try to leverage Glance also for that.  The final goal that is really ambitious is to import and export full VMs and templates supporting complete VM definition, multiple disks and snapshots.  For the initial phase, we just focused on the first point here, which is importing and exporting single images.  Basically, that integration has been implemented using something that came along in OVR-33 that are called external providers.  In OVR-33, we introduced the concept of external providers that are services that we are able to understand and integrate with. Basically, both OpenStack, image, Glance and network and also Forman have been integrated as external providers in OVR.  We have a new tab in the web admin UI and this is where you can add new external providers and this is how it looks like when you have Glance integration here.  The Glance external provider, when you define it, you have several fields that you have to fill in, name, description, the URL of the service and the authentication.  You can also test the connection at that point. This pretty much gets you started with it and as soon as you add this Glance external provider, you will also find a new storage domain in the storage tab that is exactly the Glance domain that you just added.  They are somewhat special. They basically are unattached to a storage pool. Up until now, we always had storage domains that were attached to a certain data center.  In this case, they're not attached to any specific data center and you can use them, in fact, to import and export images between different data centers.  For some operation that we do from the OVR perspective, we needed to interface with OpenStack services, but OpenStack provides, at the moment, only Python bindings for that and Engine in OVR is written in Java.  So we also started contributing to OpenStack Java SDK as a mean of communication between the Engine and the OpenStack services.  We tried to stabilize it and add the support for things that we needed.  So we can dive in one of the operations that we are actually interested in in the integration, basically, and the Glance image discovery.  So we want to list the images that are provided by the Glance service and basically, when you select the Glance storage domain in the UI, you will have a list of images that are available or that you can access on that Glance domain.  What happens behind the scene is the OVR-Tangent that goes to Keystone to request the authentication, gets a token and then goes to Glance, the Glance external provider that you defined earlier to get the image list.  There's some kind of caching involved here and then it's displayed in the UI, as I showed you before.  So once you list these images that are available in the Glance service, you probably want to import them.  So what you do, you can select one of the images and you can basically click the new button that is import and what happens is that you will be prompted with a dialogue where you can select what data center to use and in which domain you want the image to be imported to and what quota to use for that image.  And what happens behind the scene is Engine again going to Keystone to request a token.  It goes and tries and discovers the image metadata to Glance so that it can create the internal representation of these images inside the Engine.  And after we have that representation of the image inside the Engine, we go and issue the comments to be the same to create a new volume.  So that's the container where we will store the image and then we will issue a download image that will start the data transfer from Glance to VDSM.  So VDSM will go to Glance and download the image data into the volume that we just created.  So there's a special case where basically what Glance didn't provide was the image virtual size.  So as I said before, basically what Glance gives you is the size of the image.  This means that you are not able to discover in advance how large, how big is the image once you attach it to the VM.  So how large is the disk that the VM will see.  This is needed for the internal representation that we keep of the disk inside the Engine.  So we also need this information.  And at the moment, what we do is we go and download the initial part of the image and we discover the Q-Coader and we peek for the virtual size of the disk.  So Glance might provide some additional information about the virtual size in the future, but this basically works also for regular HTTP.  So this is more compatible just with also other HTTP servers that are serving an image.  And we will see later that we can support also that.  How this imported image looks in OVRT.  It's basically, it can be found in the disks tab and basically the metadata is maintained, most of it.  And then some other information are forged with defaults, like for example, the interface that is VRT-U.  And basically at that point, you can create a VM on it or create a template.  In 3.4, we automated the process so it can be imported right away as a template.  And so at this point, we can also look at the other operation that is symmetrical to this, that is exporting disks to Glance.  It's pretty much the opposite.  So now you go to the disk tab and you select one of the disks and you can export them to a Glance storage domain.  You will be prompted again with a dialogue where you can select the Glance domain.  And that behind the scene will pretty much do the same.  Engine will go to Keystone and well, it will queue the image.  As I mentioned before, basically we prepare all the metadata about the image in Glance, but the real upload is done by VDSM.  In fact, the engine sends an upload image request to VDSM that then streams the data from the volume that we have in our shared storage into Glance.  In Glance, these will look like as a regular image.  Some of the metadata is maintained like the name, for example.  And basically these is based on the VDSM support for sharing images that has been added specifically for Glance,  but it can be leveraged for other methods of transfer of images.  And one, so we have two new APIs that we use in VDSM that are download image and upload image.  And we can issue different methods for the transfer.  And one of these is HTTP that is the one that is used for Glance.  And we can also specify additional headers to it.  So, well, as I said, in this way we can support both for Glance and also for all the other HTTP servers.  There's another special case that we have to cover that is when we download an image that is QCO on a block domain.  So this is team provision means that we create volumes that are, well, on block domains we use LVM.  And we create volumes that are not entirely large as the virtual size of the image.  We just create them with chunks that then are extended as the VMs start using it.  In fact, to implement basically team provision on block devices.  So what happens is that the volume that is created is just probably one gigabyte in size.  And what happens is that VDSM has to go to the HTTP server or Glance and download and peak for the,  in this case, the actual size of the file that will be transferred and it will extend the volume to the correct size before downloading it.  In those, in all these mechanisms we have few limitations.  We are at the moment limited to not being able to export images with multiple volumes.  And this means that we cannot export this that have snapshot or that are based team provision on a template.  And this is because basically we want to export one one image that is full contained while we are using external snapshot for volumes.  Right.  And so it means that if we want to export these these images,  we would have to collapse them, but I have one slide about that later.  There is no live VM disk export.  Obviously the VM should be down.  But uploading templates is always possible.  There's no sparse support on file domains for format.  The images are always preallocated.  Means that we are not punching holes in zeros in series of zeros at the moment.  So we download them.  Obviously compression would would help in this case.  And we cannot resume partial download of the image.  So we are moving now to the future.  And in fact, these are the ideas for the future improvements of glance.  We can add a few simple operations like deleting images,  the chain online squash.  That is what I was speaking about.  So to support this that have a snapshot,  upload image compression to save bandwidth and also supports sparse.  That's probably while integrated upload and download via web admin and use report.  So you can upload images or download images from your desktop.  And they will be streamed into the volume.  As I mentioned earlier, store ISO images in glance and  use them natively in Oviart as ISO domains basically.  And import and export full VMs and templates.  So just few words about the squashing and compression of  multiple volumes images that we have in Oviart.  So as we see here, we have an image that has two snapshots.  And basically the base volume can be either raw or Q-code.  It doesn't matter about snapshots one and snapshots two or two Q-code volumes.  And in order to basically squash the image and  see just the latest version we have to compute the map of the clusters  that are scattered around these three volumes.  And there will be the support for this in QMU image.  It will give us a map of blocks that are scattered around in these volumes.  And then we will read them sequentially.  And after bufferizing them, we can compress them and stream them.  So this is just one of the idea on how to deal with the problem without  using some additional space where we basically store the image just for the upload.  Other improvements in the era of Keystone are,  well, in Oviart 3.4 we introduced a large refactoring of  authentication and directory services.  Authentication gives you the identity of the user and  the directory service provides a set of information about the user.  These have been decoupled.  So now you can use them mixing and matching.  Basically, you can use the Kerberos authentication with the LDAP directory  service if you want to or any other combination.  And Keystone, the Keystone authentication has been sketched as one of these backends.  But at the moment we have patches upstream.  And if anyone wants to contribute or take them and finish them, is welcome too.  So but this is the current status and we'll probably have it in the future somehow.  The interesting use cases for this integration is that we can consolidate  the authentication in Keystone for both data centers, Oviart and OpenStack.  We can also associate Keystone users and  tenants to Oviart entities and well,  basically give specific permissions and  roles to objects that we have in Oviart like VMs or images or disks.  And reuse the same Keystone identities when we are interfacing with  these services, with the OpenStack services.  So this is probably how it will look like.  Authentication goes to Keystone and  you will be granted the access to the web portal in this case for  this picture but to the REST API or anything.  And then supposedly later on you can go to the services,  reusing those authentication credentials and the token probably.  Another service that in the storage area that we want to integrate with  is the Cinder service that provides basically an infrastructure for  managing volumes since Folsom because previously it was part of  the compute node of Nova.  Now since Folsom has been separated into a specific project itself that is Cinder.  And volumes are persistent read write block storage devices  that most commonly are used through ice cask, right?  Now we have some other that are slightly different, for  example, glass surface that are attached as a shared,  are mounted actually as shares volumes.  So and they have a life cycle that is independent from the VM instances.  So you can create VMs that are using these volumes and  destroy them and create other new instances that are using it.  But they are the coupled, right?  Supports a snapshot and this snapshot can be used for new volumes.  And backups are generally archived in Zwift.  The use cases in over 12 week we can think of importing and  exporting images from Cinder.  But probably the most interesting one is sharing Cinder volumes for  the interoperability with OpenStack.  And in that way we will leverage the Cinder volume drivers that they have  for the support of storage appliances for IBM NetApp, hardware, Dell,  EMC and in this way gain also the storage of loading capabilities  that are coming with the Cinder volumes.  And we can also think to unify, snapshot and  backup strategies in your data center also gain for both Oviart and  OpenStack probably.  One part of the integration would be to again going to keystone for  the authentication and do some simple operation like listing,  creating and deleting volumes in Cinder.  And later on when we actually want to use them,  we will after we created or well identified the volumes that we  want to use with some Oviart VM, we will either set up the connection or  create VM, we'll embed some way of connecting to the storage that is provided by Cinder.  So this is pretty much what we are planning as future integration with OpenStack.  I want to mention that we also have a talk tomorrow about networking,  integration between Oviart and OpenStack in networking.  So that will complete the picture.  And I have useful links for you in my link list that if you're interested.  And there's work in progress of having GlanceOviart.org as a  requisitary for images that you could start downloading yourself for  your Oviart instance, right?  So basically we will have images of the most important distribution there and  you will be able to from your installation to download these templates using Glance.  Any question?  Sorry, wait for the mic.  Hello.  Hello, you do think the integration with Cinder will take time?  We are planning it for the Oviart 4 release, seems to be.  So that's pretty much the time frame.  The Oviart 4 release.  That's a function in Cinder for example called Cinder backup.  Are you trying to go on to support such things?  We have not specific details exactly of how much of that work.  So basically how much time do we have?  Not much.  Okay.  So basically the problem in the integration with Cinder is that we  have many flows of complex operation that we do on storage that are specific to Oviart.  Like for example, live snapshots or live storage migrations.  These are in the current implementation are really tailored to how the images are stored  in the storage and how they look like in Oviart.  And all these flows might, they don't map at all to Cinder.  So an easy integration with Cinder would be to leverage what we have already today  that are direct lands.  So we already support direct lands and we have some operations there that we support.  But that's the easiest integration.  So you basically can use Cinder volumes as direct lands.  So that's the easiest one.  For all the other complex flows, it will require time.  Definitely.  Thank you.  Okay.  Okay.  Talk about 4.0, the release 4.0.  Is it related to Red Hat Linux 7 or does the schedules match or is it not allowed to speak  public about that?  So for EL7 support, we're planning to add it in Oviart 3.5 actually.  So as using an EL7 host, REL7 or CENL7, as the host is planned for Oviart 3.5, for the  engine itself to run, probably it will take a bit more time.  The interesting part is probably using it as a host.  Okay.  But can we expect that it's in the Red Hat way like it used to be where you do a lot  of back porting like with the kernel or stuff like that, that you get some features from  the 4.0 release back ported to the actual Red Hat package of Oviart?  Usually it's not an issue so much for Oviart or Rev, which is the Red Hat version of it  because we usually rebase each minor version so we don't have to do a lot of back ports  for features.  Most of the back ports are for stabilization and we're doing a lot of them in upstream  Oviart as well.  We just have Oviart 3.3.3 stabilization release for the current Oviart release.  So a lot of back ports are done both upstream and downstream.  That's too far to say.  I don't know the schedule.  I joined a bit late but I missed the thing about the LDP integration and all those things  but I've got a lot of customers which are still, please don't beat me up, which are  still running yellow pages through NIS which are on a plain Unix user backend.  Without any LDP integration we got, I did some POSIX ACLs on that to extend the possibilities  of groupings and stuff like that.  Is there any integration plan for just simple Unix user backend which are a bit extended  regarding POSIX ACLs?  You can use, as Federico mentioned, there's a lot of organ refactoring, the authentication  backend.  You can write a plugin for anything now basically.  So now it's done, right?  Yes, we're ready to go ahead E, we're pulling all of our stuff down here because it looks
_FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_0_179.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_180_503.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_504_551.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_552_1055.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_1056_2123.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_2124_9875.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_9876_10019.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_10020_10439.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_10440_18647.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_18648_24587.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_24588_26507.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_26508_31043.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_31044_31151.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_31152_32159.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_32160_32315.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_32316_34427.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_34428_35807.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_35808_36071.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_36072_36587.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_36588_37463.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_37464_40751.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_40752_42179.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_42180_42755.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_42756_43235.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_43236_43439.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_43440_43631.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_43632_43715.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_43716_44615.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_44616_44759.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_44760_45323.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_45324_46355.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_46356_46403.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_46404_46463.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_46464_46943.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_46944_47531.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_47532_47999.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_48000_48203.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_48204_48431.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_48432_49667.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_49668_49787.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_49788_49835.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_49836_49895.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_49896_50135.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_50136_50963.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_50964_51179.png _FOSDEM_2014__oVirt_and_OpenStack_Storage__present_and_future__49uwhVSuJKw_51180_51393.png
Hi. My name is Federico and I'm working for Red Hat in the Overt Storage group. I'm here to present you the current integration between Overt and OpenStack storage. So the presentation is mostly about the integration between Overt and OpenStack, but I will give you a short introduction about Overt and OpenStack just to get you started on what they are. Then I'll go over the present current integration. So what we have today with the Overt and Glance integration, always in the storage side, it's important as part of Glance images and current limitations, and then I'll go over what we will have in the future with the Glance, future integration, new things that we can add and improve there, keystone authentication and how that is also involved with storage somehow, Overt and the similar integration in the coming future. So just to start, what is Overt? This is the definition that you can find around pretty much everywhere. Overt is the virtualization management application that manages hardware nodes, storage and network resources in your data center in order to deploy virtual machines. It's open source release under the terms of the Apache license, and this is a quite old diagram that you can find, but nothing like we have some new things going on, but this is pretty much the idea. We have two different web interfaces, the administration portal and the user portal to interact with it. Rest API, then a JBus application that is the engine that controls the data centers, and then on each node of the cluster, you have VDSM that takes care of controlling those nodes and make them available and usable from the engine to manage basically everything from storage's network, anything that the virtual machine would need to actually run. What is OpenStack? Well, it's cloud computing project that provides an infrastructure as a service and also controls large pools of compute, storage and networking resources. Apache license is governed by a foundation that was established in September 2012. There might be some overlap in the two projects. They are tailored for different workloads, so today it makes sense to make them living together in the same infrastructure, so that is why we need to integrate them. I won't go much further into the differences, but because the time is really limited, so this is the idea. So at the present time, you need some interaction between the two. And as we see OpenStack can have three different areas of projects, compute, networking and storage. We will focus on storage obviously in the scope of this presentation, and more specifically, we'll look at Glance and how that can benefit in the integration with OVR. So what is Glance? Glance provides services for discovering, registering and retrieving virtual machine images. It has a RESTful API for querying VM images metadata and actually downloading that image. These images can be thought as templates if you're familiar with that concept in OVR. It can also be used as backup and has different backends eventually, ranging from the simplified system to Zwift. It supports several disks formats and containers formats. Disk formats, as raw, Qco, ISO and container formats as bare and OVF. You're probably familiar with these if you already use also OVR. It supports image metadata. Basically, these are some additional information that you can have on the images that are stored in Glance. You can pretty much go over them yourself. I just mentioned two of them because they're kind of important in the integration. One is the size. The size has to be intended as the real size of the image of the file that is transferred, uploaded or downloaded from Glance. The status, there's a special status that is queued and it is when you have the metadata that is raiding Glance, but the image is not there yet. These are important for the integration. We also have some additional properties that are now more standardized in version two about the some additional information about the image as the architecture, the hypervisor type and some other information. We decided not to use these common properties to store OVR-specific information because we wanted to actually have full integration with OpenStack. That information wouldn't have been consumable by OpenStack. We are not storing any additional properties in Glance for now. The interesting use cases for OVR that we wanted to integrate with are importing and exporting single images or templates from and to Glance for the interoperability with OpenStack. We can be used for backups of images of VMs and basically also use it as ISO domain. They overtest something specific that is called ISO domains that are used to store ISO images for the VMs, but we can try to leverage Glance also for that. The final goal that is really ambitious is to import and export full VMs and templates supporting complete VM definition, multiple disks and snapshots. For the initial phase, we just focused on the first point here, which is importing and exporting single images. Basically, that integration has been implemented using something that came along in OVR-33 that are called external providers. In OVR-33, we introduced the concept of external providers that are services that we are able to understand and integrate with. Basically, both OpenStack, image, Glance and network and also Forman have been integrated as external providers in OVR. We have a new tab in the web admin UI and this is where you can add new external providers and this is how it looks like when you have Glance integration here. The Glance external provider, when you define it, you have several fields that you have to fill in, name, description, the URL of the service and the authentication. You can also test the connection at that point. This pretty much gets you started with it and as soon as you add this Glance external provider, you will also find a new storage domain in the storage tab that is exactly the Glance domain that you just added. They are somewhat special. They basically are unattached to a storage pool. Up until now, we always had storage domains that were attached to a certain data center. In this case, they're not attached to any specific data center and you can use them, in fact, to import and export images between different data centers. For some operation that we do from the OVR perspective, we needed to interface with OpenStack services, but OpenStack provides, at the moment, only Python bindings for that and Engine in OVR is written in Java. So we also started contributing to OpenStack Java SDK as a mean of communication between the Engine and the OpenStack services. We tried to stabilize it and add the support for things that we needed. So we can dive in one of the operations that we are actually interested in in the integration, basically, and the Glance image discovery. So we want to list the images that are provided by the Glance service and basically, when you select the Glance storage domain in the UI, you will have a list of images that are available or that you can access on that Glance domain. What happens behind the scene is the OVR-Tangent that goes to Keystone to request the authentication, gets a token and then goes to Glance, the Glance external provider that you defined earlier to get the image list. There's some kind of caching involved here and then it's displayed in the UI, as I showed you before. So once you list these images that are available in the Glance service, you probably want to import them. So what you do, you can select one of the images and you can basically click the new button that is import and what happens is that you will be prompted with a dialogue where you can select what data center to use and in which domain you want the image to be imported to and what quota to use for that image. And what happens behind the scene is Engine again going to Keystone to request a token. It goes and tries and discovers the image metadata to Glance so that it can create the internal representation of these images inside the Engine. And after we have that representation of the image inside the Engine, we go and issue the comments to be the same to create a new volume. So that's the container where we will store the image and then we will issue a download image that will start the data transfer from Glance to VDSM. So VDSM will go to Glance and download the image data into the volume that we just created. So there's a special case where basically what Glance didn't provide was the image virtual size. So as I said before, basically what Glance gives you is the size of the image. This means that you are not able to discover in advance how large, how big is the image once you attach it to the VM. So how large is the disk that the VM will see. This is needed for the internal representation that we keep of the disk inside the Engine. So we also need this information. And at the moment, what we do is we go and download the initial part of the image and we discover the Q-Coader and we peek for the virtual size of the disk. So Glance might provide some additional information about the virtual size in the future, but this basically works also for regular HTTP. So this is more compatible just with also other HTTP servers that are serving an image. And we will see later that we can support also that. How this imported image looks in OVRT. It's basically, it can be found in the disks tab and basically the metadata is maintained, most of it. And then some other information are forged with defaults, like for example, the interface that is VRT-U. And basically at that point, you can create a VM on it or create a template. In 3.4, we automated the process so it can be imported right away as a template. And so at this point, we can also look at the other operation that is symmetrical to this, that is exporting disks to Glance. It's pretty much the opposite. So now you go to the disk tab and you select one of the disks and you can export them to a Glance storage domain. You will be prompted again with a dialogue where you can select the Glance domain. And that behind the scene will pretty much do the same. Engine will go to Keystone and well, it will queue the image. As I mentioned before, basically we prepare all the metadata about the image in Glance, but the real upload is done by VDSM. In fact, the engine sends an upload image request to VDSM that then streams the data from the volume that we have in our shared storage into Glance. In Glance, these will look like as a regular image. Some of the metadata is maintained like the name, for example. And basically these is based on the VDSM support for sharing images that has been added specifically for Glance, but it can be leveraged for other methods of transfer of images. And one, so we have two new APIs that we use in VDSM that are download image and upload image. And we can issue different methods for the transfer. And one of these is HTTP that is the one that is used for Glance. And we can also specify additional headers to it. So, well, as I said, in this way we can support both for Glance and also for all the other HTTP servers. There's another special case that we have to cover that is when we download an image that is QCO on a block domain. So this is team provision means that we create volumes that are, well, on block domains we use LVM. And we create volumes that are not entirely large as the virtual size of the image. We just create them with chunks that then are extended as the VMs start using it. In fact, to implement basically team provision on block devices. So what happens is that the volume that is created is just probably one gigabyte in size. And what happens is that VDSM has to go to the HTTP server or Glance and download and peak for the, in this case, the actual size of the file that will be transferred and it will extend the volume to the correct size before downloading it. In those, in all these mechanisms we have few limitations. We are at the moment limited to not being able to export images with multiple volumes. And this means that we cannot export this that have snapshot or that are based team provision on a template. And this is because basically we want to export one one image that is full contained while we are using external snapshot for volumes. Right. And so it means that if we want to export these these images, we would have to collapse them, but I have one slide about that later. There is no live VM disk export. Obviously the VM should be down. But uploading templates is always possible. There's no sparse support on file domains for format. The images are always preallocated. Means that we are not punching holes in zeros in series of zeros at the moment. So we download them. Obviously compression would would help in this case. And we cannot resume partial download of the image. So we are moving now to the future. And in fact, these are the ideas for the future improvements of glance. We can add a few simple operations like deleting images, the chain online squash. That is what I was speaking about. So to support this that have a snapshot, upload image compression to save bandwidth and also supports sparse. That's probably while integrated upload and download via web admin and use report. So you can upload images or download images from your desktop. And they will be streamed into the volume. As I mentioned earlier, store ISO images in glance and use them natively in Oviart as ISO domains basically. And import and export full VMs and templates. So just few words about the squashing and compression of multiple volumes images that we have in Oviart. So as we see here, we have an image that has two snapshots. And basically the base volume can be either raw or Q-code. It doesn't matter about snapshots one and snapshots two or two Q-code volumes. And in order to basically squash the image and see just the latest version we have to compute the map of the clusters that are scattered around these three volumes. And there will be the support for this in QMU image. It will give us a map of blocks that are scattered around in these volumes. And then we will read them sequentially. And after bufferizing them, we can compress them and stream them. So this is just one of the idea on how to deal with the problem without using some additional space where we basically store the image just for the upload. Other improvements in the era of Keystone are, well, in Oviart 3.4 we introduced a large refactoring of authentication and directory services. Authentication gives you the identity of the user and the directory service provides a set of information about the user. These have been decoupled. So now you can use them mixing and matching. Basically, you can use the Kerberos authentication with the LDAP directory service if you want to or any other combination. And Keystone, the Keystone authentication has been sketched as one of these backends. But at the moment we have patches upstream. And if anyone wants to contribute or take them and finish them, is welcome too. So but this is the current status and we'll probably have it in the future somehow. The interesting use cases for this integration is that we can consolidate the authentication in Keystone for both data centers, Oviart and OpenStack. We can also associate Keystone users and tenants to Oviart entities and well, basically give specific permissions and roles to objects that we have in Oviart like VMs or images or disks. And reuse the same Keystone identities when we are interfacing with these services, with the OpenStack services. So this is probably how it will look like. Authentication goes to Keystone and you will be granted the access to the web portal in this case for this picture but to the REST API or anything. And then supposedly later on you can go to the services, reusing those authentication credentials and the token probably. Another service that in the storage area that we want to integrate with is the Cinder service that provides basically an infrastructure for managing volumes since Folsom because previously it was part of the compute node of Nova. Now since Folsom has been separated into a specific project itself that is Cinder. And volumes are persistent read write block storage devices that most commonly are used through ice cask, right? Now we have some other that are slightly different, for example, glass surface that are attached as a shared, are mounted actually as shares volumes. So and they have a life cycle that is independent from the VM instances. So you can create VMs that are using these volumes and destroy them and create other new instances that are using it. But they are the coupled, right? Supports a snapshot and this snapshot can be used for new volumes. And backups are generally archived in Zwift. The use cases in over 12 week we can think of importing and exporting images from Cinder. But probably the most interesting one is sharing Cinder volumes for the interoperability with OpenStack. And in that way we will leverage the Cinder volume drivers that they have for the support of storage appliances for IBM NetApp, hardware, Dell, EMC and in this way gain also the storage of loading capabilities that are coming with the Cinder volumes. And we can also think to unify, snapshot and backup strategies in your data center also gain for both Oviart and OpenStack probably. One part of the integration would be to again going to keystone for the authentication and do some simple operation like listing, creating and deleting volumes in Cinder. And later on when we actually want to use them, we will after we created or well identified the volumes that we want to use with some Oviart VM, we will either set up the connection or create VM, we'll embed some way of connecting to the storage that is provided by Cinder. So this is pretty much what we are planning as future integration with OpenStack. I want to mention that we also have a talk tomorrow about networking, integration between Oviart and OpenStack in networking. So that will complete the picture. And I have useful links for you in my link list that if you're interested. And there's work in progress of having GlanceOviart.org as a requisitary for images that you could start downloading yourself for your Oviart instance, right? So basically we will have images of the most important distribution there and you will be able to from your installation to download these templates using Glance. Any question? Sorry, wait for the mic. Hello. Hello, you do think the integration with Cinder will take time? We are planning it for the Oviart 4 release, seems to be. So that's pretty much the time frame. The Oviart 4 release. That's a function in Cinder for example called Cinder backup. Are you trying to go on to support such things? We have not specific details exactly of how much of that work. So basically how much time do we have? Not much. Okay. So basically the problem in the integration with Cinder is that we have many flows of complex operation that we do on storage that are specific to Oviart. Like for example, live snapshots or live storage migrations. These are in the current implementation are really tailored to how the images are stored in the storage and how they look like in Oviart. And all these flows might, they don't map at all to Cinder. So an easy integration with Cinder would be to leverage what we have already today that are direct lands. So we already support direct lands and we have some operations there that we support. But that's the easiest integration. So you basically can use Cinder volumes as direct lands. So that's the easiest one. For all the other complex flows, it will require time. Definitely. Thank you. Okay. Okay. Talk about 4.0, the release 4.0. Is it related to Red Hat Linux 7 or does the schedules match or is it not allowed to speak public about that? So for EL7 support, we're planning to add it in Oviart 3.5 actually. So as using an EL7 host, REL7 or CENL7, as the host is planned for Oviart 3.5, for the engine itself to run, probably it will take a bit more time. The interesting part is probably using it as a host. Okay. But can we expect that it's in the Red Hat way like it used to be where you do a lot of back porting like with the kernel or stuff like that, that you get some features from the 4.0 release back ported to the actual Red Hat package of Oviart? Usually it's not an issue so much for Oviart or Rev, which is the Red Hat version of it because we usually rebase each minor version so we don't have to do a lot of back ports for features. Most of the back ports are for stabilization and we're doing a lot of them in upstream Oviart as well. We just have Oviart 3.3.3 stabilization release for the current Oviart release. So a lot of back ports are done both upstream and downstream. That's too far to say. I don't know the schedule. I joined a bit late but I missed the thing about the LDP integration and all those things but I've got a lot of customers which are still, please don't beat me up, which are still running yellow pages through NIS which are on a plain Unix user backend. Without any LDP integration we got, I did some POSIX ACLs on that to extend the possibilities of groupings and stuff like that. Is there any integration plan for just simple Unix user backend which are a bit extended regarding POSIX ACLs? You can use, as Federico mentioned, there's a lot of organ refactoring, the authentication backend. You can write a plugin for anything now basically. So now it's done, right? Yes, we're ready to go ahead E, we're pulling all of our stuff down here because it looks
part of Glance images and current limitations, keystone authentication and how that is also integrate with. Basically, both OpenStack, image, transferred and it will extend the volume to the ideas for the future improvements of glance. We combination. And Keystone, the Keystone this is the current status and we'll probably networking, integration between Oviart and you do think the integration with Cinder will