openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14735
Re: One question on the compute_filter
> -----Original Message-----
> From: Jim Fehlig [mailto:jfehlig@xxxxxxxx]
> Sent: Tuesday, July 17, 2012 11:37 AM
> To: Jiang, Yunhong
> Cc: jsuh@xxxxxxx; openstack@xxxxxxxxxxxxxxxxxxx
> 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
References