Open Stack

I would like to highlight the following with respect to the suggested Blueprint:

*       All the enhancements that are being talked about are in-line with the nova constructs and works with all the features of nova.

*       What we are trying to bring out with the blueprint is to leverage the existing logical openstack construct "nova-compute".

*       We are proposing to have a Cluster or Resourcepool represented as a "nova-compute"  where all the "nova-compute's" traits are kept intact and at the same time expose the hypervisor provided capabilities like DRS / HA etc.,

*       With this BP implementation no change would be required to nova-scheduler and all the scheduler logic would work the same way as is with the added hidden advantage of leverage hypervisor features.

*       More use cases possible with the "Host-aggregates" and the "Cluster or Resource pool" represented as "nova-compute".   For eg:  Adding Tenant affinity to a particular CLUSTER / RESOURCE POOL or a group of CLUSTER / Resource pool,    Add capability to deploy new instances to a group of DRS / HA enabled Cluster etc.,
*       We have other blueprints wherein we are talking about using Glance, Cinder etc along with vCenter and has been demoed during the Havana Summit.  Following link provides additional details of the related blueprints:  Proxy Compute Service managing multiple VMware vCenter Clusters and Resource Pools<http://www.openstack.org/summit/portland-2013/session-videos/presentation/proxy-compute-service-managing-multiple-vmware-vcenter-clusters-and-resource-pools>

Hope this helps

Thanks,
Divakar

-----Original Message-----
From: Vaddi, Kiran Kumar
Sent: Thursday, May 09, 2013 8:27 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] New blueprint to make vcenter templates available as glance images
Importance: High

The bp is referring to enhancing the nova driver for vCenter *clusters* only. Agree that Openstack manages KVM hosts and not the oVirt(might change in future). However in case of ESX, a lot of features of the vCenter are built at the cluster level (DRS/HA/Templates/VDS). And therefore for admins would like to leverage these features of the management software and also have the benefits of Openstack, the nova driver should use vCenter clusters as being done by the existing nova VMwareVCDriver.

The nova driver for the individual ESX hypervisor are *not* being changed and are not impacted by this bp.

Regarding the advantages - In an existing setup where the administrator already has templates in vCenter and wants to a manage new clusters added to the datacenter using Openstack, this bp will enable the reuse of the templates. Without this, 1. The admin has to upload all the template images into glance 2. Whenever any security patches/hotfixes are applied on the templates, the same will have to be done on the glance images as well.

The admin can still continue to upload images (qcow/vmdk) and these can also be used for instance creation. This bp only gives admin additional choice.

There would not be any code changes in glance to allow this. Only the changes will be in the vCenter nova driver in which it will read the metadata of the image and decide if it is a template or not. Since a template is confined to a vCenter, the nova driver will have to publish the vcenter it belongs to in its capabilities. A new filter would be required or existing image filter can be modified to consume this capability.

We have this working as a PoC and it was demo'ed in the Havana summit as well.

I'd try to join meeting on the IRC but its at 1.30AM my time.

Thanks,
Kiran

-----Original Message-----
From: Flavio Percoco [mailto:flavio at redhat.com]
Sent: Thursday, May 09, 2013 7:19 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [glance] New blueprint to make vcenter templates available as glance images

On 09/05/13 09:10 -0400, Russell Bryant wrote:
>On 05/09/2013 02:45 AM, Vaddi, Kiran Kumar wrote:
>> Hi All,
>>
>> Request review and feedback for the blueprint
>> (https://blueprints.launchpad.net/glance/+spec/hypervisor-templates-a
>> s-glance-images)
>>
>> Rationale:
>> VMware vCenter already has the deployable images in the form of "Templates". (Other hypervisors like RHEVM also have templates) This blueprint proposes to make
>>   1. Glance to be aware the vCenter templates.
>>   2. Avoid upload of VMware templates into the image server.
>>
>> This allows users to leverage their existing vCenter templates and vCenter template deployment optimizations.
>> The same design can be extended to other hypervisors as well.
>
>You use RHEVM (oVirt) as a comparable example here.  The problem is
>that oVirt is *not* a hypervisor.  oVirt is a full-on virtualization
>management system.  oVirt uses libvirt+KVM and Nova supports *that*,
>not oVirt.
>
>It seems like we're violating layers, here.  It feels like all of this
>vCenter stuff is getting hacked in, even though it's not quite
>appropriate for our architecture.

I agree with Russell.

I'd like to see this explained a bit better and see if it really fits into the project plans. FWIW, I don't see the exact advantage of implementing this but again, I'd like to know more details about the idea.

@Vaddi Would you be able to join todays meeting and share some thoughts in the open-question time?

Cheers,
FF

--
{ name: "Flavio Percoco",
   gpg: "87112EC1",
   internal: "8261386",
   phone: "+390687502386",
   irc: ["fpercoco", "flaper87"]}

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/1a7db654/attachment.html>