Open Stack

> -----Original Message-----
> From: Jim Fehlig [mailto:jfehlig at suse.com]
> Sent: Tuesday, July 17, 2012 11:37 AM
> To: Jiang, Yunhong
> Cc: jsuh at isi.edu; openstack at lists.launchpad.net
> Subject: Re: [Openstack] One question on the compute_filter
> 
> Jiang, Yunhong wrote:
> >
> > Hi, Joseph
> >
> >          I’m working on the patch for blueprints
> > https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value,
> > to add/delete the extra_specs for flavor through nova-manage. I’m
> > still setting up my environment to push the patch.
> >
> >
> >
> >          However, when I was testing my patch, I noticed that
> > compute_filter assume it will handle all of the “extra_specs”. If it
> > can’t find corresponding key in the capabilities, it will fail to pass
> > the host. IMHO, this is a bit overkill. For example, currently the
> > trusted_filter.py will use the extra_specs to check if trusted_host is
> > required, that means compute filter and trusted filter can’t be used
> > at the same time.
> >
> >          I think compute filter should define explicitly all keys that
> > it takes care, like cpu_info, cpu_arch, xpu_arch, and only check the
> > corresponding extra_specs key/value pair? After all, extra_specs is
> > not compute_extra_specs?
> >
> >          I noticed the patch in
> > https://review.openstack.org/#/c/8089/, but seems this patch will not
> > fix this issue still.
> >
> >
> >
> > Any idea or suggestion? I’m glad to create patch if any conclusion on
> > this issue.
> >
> 
> I have been working on a patch [1] that allows the ComputeFilter to filter on
> (architecture, hypervisor_type, vm_mode) triplet as specified in the *instance
> properties*.  In the blueprint you mention, I see cpu_type=itanium as an
> example of a key/value in the extra_specs of instance types.  Are architecture,
> preferred hypervisor, and vm_mode (PV vs HVM) properties of the image
> (which are used to populate the
> instance_properties) or properties of a flavor (used to populate instance_type)?
> IMO, they are properties of an image.

Jim, thanks for your input very much.

I agree with you that architecture is better through instance_property. 
For vm_mode or hypervisor_type, I'm not sure what will happen if an image can be used
in both Xen/KVM environment (I'm not familiar with the image code yet). But I agree that at least
it's better to be in instance_property than in flavor. 

The blueprint in http://wiki.openstack.org/HeterogeneousInstanceTypes gives 
some example of extra_specs, seems it includes cpu_info, cpu_arch etc. Although
 I'm not sure if this blueprint is valid still.


> 
> What are the other commonly used extra_specs that are being checked by the
> ComputeFilter?  Are they properties of an image or a flavor?

Seems currently the ComputeFilter check extra_spec according to the host capability.
And the TrustedFilter check extra_spec for trusted host.

--jyh

> Perhaps the checks for extra_specs can be removed from the ComputeFilter
> entirely and done by other filters as you mention.
> 
> Regards,
> Jim
> 
> [1] https://lists.launchpad.net/openstack/msg14121.html