Re: [openstack-dev] ova support in glance
On 07/30/2014 12:57 AM, Bhandaru, Malini K wrote: > Hello Everyone! > > We were discussing the following blueprint in Glance: > Enhanced-Platform-Awareness-OVF-Meta-Data-Import > :https://review.openstack.org/#/c/104904/ > > The OVA format is very rich and the proposal here in its first incarnation is > to essentially Untar the ova package, andimport the first disk image therein > and parse the ovf file and attach meta data to the disk image. > There is a nova effort in a similar vein that supports OVA, limiting its > availability to the VMWare hypervisor. Our efforts will combine. > > The issue that is raised is how many openstack users and OpenStack cloud > providers tackle OVA data with multiple disk images, using them as an > application. > Do your users using OVA with content other than 1 disk image + OVF? > That is does it have other files that are used? Do any of you use OVAs with > snapshot chains? > Would this solution path break your system, result in unhappy users? > > > If the solution will at least address 50% of the use cases, a low bar, and > ease deploying NFV applications, this would be worthy. > If so, how would we message around this so as not to imply that OpenStack > supports OVA in its full glory? > > Down the road the Artefacts blueprint will provide a place holder for OVA. > Perhaps even the OVA format may be transformed into a Heat template to work > in OpenStack. > > Please do prov ide us your feedback. Hey, Thanks for your efforts and interest in this area. We've discussed this in the past - sorry, I don't have linking to the previous discussions - and the results of these discussions led to just wait until we have a better "template" management in Glance. Artifacts were also indirectly supported by this idea of having a better way to store these multi-image templates in Glance. After taking a look at the proposed spec, I'm even more hesitant to letting it land. The reason being that changes proposed there would fit in the work going on in the Artifacts blueprint. Moreover, the proposed spec suggests extending the ImageProperty model, which I'd really prefer not to extend. In the future - probably L - we'd like to convert images to artifacts, which means the work related to this blueprint will be gone and we'll have to translate it to artifacts anyway. With all that said, there's the other issue you mentioned in your email. People will expect it to be fully implemented and environments depending on multi-disk OVAs will find it useless. Don't get me wrong, I do want to see OVF support in Glance, I just don't think a custom support for it is the right way to do it. Thoughts? Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ova support in glance
Hello Everyone! We were discussing the following blueprint in Glance: Enhanced-Platform-Awareness-OVF-Meta-Data-Import :https://review.openstack.org/#/c/104904/ The OVA format is very rich and the proposal here in its first incarnation is to essentially Untar the ova package, andimport the first disk image therein and parse the ovf file and attach meta data to the disk image. There is a nova effort in a similar vein that supports OVA, limiting its availability to the VMWare hypervisor. Our efforts will combine. The issue that is raised is how many openstack users and OpenStack cloud providers tackle OVA data with multiple disk images, using them as an application. Do your users using OVA with content other than 1 disk image + OVF? That is does it have other files that are used? Do any of you use OVAs with snapshot chains? Would this solution path break your system, result in unhappy users? If the solution will at least address 50% of the use cases, a low bar, and ease deploying NFV applications, this would be worthy. If so, how would we message around this so as not to imply that OpenStack supports OVA in its full glory? Down the road the Artefacts blueprint will provide a place holder for OVA. Perhaps even the OVA format may be transformed into a Heat template to work in OpenStack. Please do prov ide us your feedback. Regards Malini ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ova support in glance
Hi, Please take a look at this document: http://www.dmtf.org/sites/default/files/standards/documents/DSP0265_1.0.0.pdf . There are clarifications of what is OVF and how it should be used. Check section 9 for use cases. >From our experience OVA\OVF are used to deliver applications in form of pre-backed images + deployment options to successfully deploy this application. OVF format is close to TOSCA and can define not only resources but network configuration, startup scripts, software installation and license agreement for proprietary software. I want to highlight that OVA import procedure in VMWare ends with actual instance creation rather then keeping disk images. And there is a reason for that as OVF defines the deployment procedures and VMWare even will generate UI to ask specific deployment parameters like IP addresses, hostnames and Application specific options. We had OVA experience in Murano project. We had a customer who uses virtual appliances distributed in form of OVA. We had to convert them to a set of image+heat-template+murano workflow/UI. I think we are going to support Applications in OVA format in Murano as we already plan to support other formats like TOSCA and APS (Parallels application standard). Thanks Georgy On Sat, Jul 26, 2014 at 7:19 AM, Mark Washenberger < mark.washenber...@markwash.net> wrote: > Thanks for sending out this message Malini. > > I'm really pleased that the "image import" mechanism we've been working on > in Glance for a while is going to be helpful for supporting this kind of > use case. > > The problem that I see is one of messaging. If we tell end users that > "OpenStack can import and run OVAs" I think we're probably setting > ourselves up for a serious problem with expectations. Since an OVA is *not* > an image, and actually could be much broader in scope or more constrained, > I'm worried that this import will fail for most users most of the time. > This just creates a negative impression of our cloud, and may cause a > significant support headache for some of our deployers. > > The plan I propose to respond to this challenge is as follows: > > 1) develop the initial OVA image import out of tree > - the basic functionality is just to grab the root disk out of the ova > and to set image properties based on some of the ovf metadata > 2) assess what the median level of OVA complexity is out there in the wild > among OVA users > 3) make sufficient progress with artifacts to ensure we can cover the > median level of OVA complexity in an OpenStack accessible way > - openstack accessible to me means there probably has to be qemu-image > / libvirt / heat support for a given OVA concept > 4) Bring OVA import into the main tree as part of the "General Import" [1] > operation once that artifact progress has been made > > However, I'm very interested to know if there are some folks more embedded > with operators and deployers who can reassure me that this OVA messaging > problem can be dealt with another way. > > Thanks! > > > [1] As a reminder, the "General Import" item on our hazy future backlog is > different from "Image Import" in the following way. For an image import, > you are explicitly trying to create an image. For the general import, you > show up to the cloud with some information and just ask for it to be > imported, the import task itself will inspect the data you provide to > determine what, if anything, can be created for it. This works well for > OVAs because we may want to produce a disk image, a block device mapping > artifact, or even up to the level of a heat template. > > > On Fri, Jul 25, 2014 at 7:08 PM, Bhandaru, Malini K < > malini.k.bhand...@intel.com> wrote: > >> Hello Everyone! >> >> We were discussing the following blueprint in Glance: >> Enhanced-Platform-Awareness-OVF-Meta-Data-Import : >> https://review.openstack.org/#/c/104904/ >> >> The OVA format is very rich and the proposal here in its first >> incarnation is to essentially >> Untar the ova package, andimport the first disk image therein and parse >> the ovf file and attach meta data to the disk image. >> There is a nova effort in a similar vein that supports OVA, limiting its >> availability to the VMWare hypervisor. Our efforts will combine. >> >> The issue that is raised is how many openstack users and OpenStack cloud >> providers tackle OVA data with multiple disk images, using them as an >> application. >> Do your users using OVA with content other than 1 disk image + OVF? >> That is does it have other files that are used? Do any of you use OVAs >> with snapshot chains? >> Would this solution path break your system, result in unhappy users? >> >> >> If the solution will at least address 50% of the use cases, a low bar, >> and ease deploying NFV applications, this would be worthy. >> If so, how would we message around this so as not to imply that OpenStack >> supports OVA in its full glory? >> >> Down the road the Artefacts blueprint will provide a place holder for
Re: [openstack-dev] ova support in glance
Thanks for sending out this message Malini. I'm really pleased that the "image import" mechanism we've been working on in Glance for a while is going to be helpful for supporting this kind of use case. The problem that I see is one of messaging. If we tell end users that "OpenStack can import and run OVAs" I think we're probably setting ourselves up for a serious problem with expectations. Since an OVA is *not* an image, and actually could be much broader in scope or more constrained, I'm worried that this import will fail for most users most of the time. This just creates a negative impression of our cloud, and may cause a significant support headache for some of our deployers. The plan I propose to respond to this challenge is as follows: 1) develop the initial OVA image import out of tree - the basic functionality is just to grab the root disk out of the ova and to set image properties based on some of the ovf metadata 2) assess what the median level of OVA complexity is out there in the wild among OVA users 3) make sufficient progress with artifacts to ensure we can cover the median level of OVA complexity in an OpenStack accessible way - openstack accessible to me means there probably has to be qemu-image / libvirt / heat support for a given OVA concept 4) Bring OVA import into the main tree as part of the "General Import" [1] operation once that artifact progress has been made However, I'm very interested to know if there are some folks more embedded with operators and deployers who can reassure me that this OVA messaging problem can be dealt with another way. Thanks! [1] As a reminder, the "General Import" item on our hazy future backlog is different from "Image Import" in the following way. For an image import, you are explicitly trying to create an image. For the general import, you show up to the cloud with some information and just ask for it to be imported, the import task itself will inspect the data you provide to determine what, if anything, can be created for it. This works well for OVAs because we may want to produce a disk image, a block device mapping artifact, or even up to the level of a heat template. On Fri, Jul 25, 2014 at 7:08 PM, Bhandaru, Malini K < malini.k.bhand...@intel.com> wrote: > Hello Everyone! > > We were discussing the following blueprint in Glance: > Enhanced-Platform-Awareness-OVF-Meta-Data-Import : > https://review.openstack.org/#/c/104904/ > > The OVA format is very rich and the proposal here in its first incarnation > is to essentially > Untar the ova package, andimport the first disk image therein and parse > the ovf file and attach meta data to the disk image. > There is a nova effort in a similar vein that supports OVA, limiting its > availability to the VMWare hypervisor. Our efforts will combine. > > The issue that is raised is how many openstack users and OpenStack cloud > providers tackle OVA data with multiple disk images, using them as an > application. > Do your users using OVA with content other than 1 disk image + OVF? > That is does it have other files that are used? Do any of you use OVAs > with snapshot chains? > Would this solution path break your system, result in unhappy users? > > > If the solution will at least address 50% of the use cases, a low bar, and > ease deploying NFV applications, this would be worthy. > If so, how would we message around this so as not to imply that OpenStack > supports OVA in its full glory? > > Down the road the Artefacts blueprint will provide a place holder for OVA. > Perhaps even the OVA format may be transformed into a Heat template to work > in OpenStack. > > Please do prov ide us your feedback. > Regards > Malini > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
