Open Stack

Sorry for slow response, this mail is lost in the mail flood.

For the pre-datastructure code, I think there have been some discussion on it, like https://wiki.openstack.org/wiki/VirtDriverImageProperties or https://bugs.launchpad.net/nova/+bug/1275875 . But I do agree that we should enhance it to be more formal, if we do treat it as something like API.

Thanks
--jyh

> -----Original Message-----
> From: George Shuklin [mailto:george.shuklin at gmail.com]
> Sent: Saturday, January 17, 2015 6:41 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] The constraints from flavor and image
> metadata
> 
> When I played with metadata, I had have constant feeling it had mess
> together few things:
> 
> 1. H/W requirements for images.
> 2. Accounting requirements (good CPU for good price, HDD for cheap)
> 3. Licensing restrictions (run this one only on the hosts with licenses)
> 4. Administrative management (like 'flavors of tenant X should be run
> only on hosts Y')
> 5. OS information (like inherited metadata on images)
> 
> All that together is called 'metadata'. Some metadata have special
> meaning in one context (like 'availability_zone' for hosts, or CPU
> limitation), some is used by administrator in other context.
> 
> All together it looks like pre-datastructure code (if someone remembers
> that). No data types, no type restrictions, you can assign letter to
> instruction address and pointer to string to float.
> 
> Same with current metadata in nova/glance. Raw namespace of key-value
> items without any meaningful restriction and specific expression. It
> gives flexibility, but cause a huge strain on operators.
> 
> I think it needs more expressive representation.
> 
> On 01/13/2015 11:39 PM, Jiang, Yunhong wrote:
> > Hi,
> > 	There are some discussion and disagreement on the requirement
> from flavor and image metadata at nova spec
> https://review.openstack.org/#/c/138937/ and I want to get more input
> from the community.
> > 	When launch a VM, some requirements may come from image
> metadata and flavor. There are a lot of such cases like serial_port_count,
> memory_pagesize, hw_numa_nodes, hw:cpu_max_sockets etc. Most of
> them are done in nova/virt/hardware.py.
> >
> > 	Both the nova-spec and the current implementation seems agree
> that if flavor has the requirement, the image's metadata should not require
> more than the flavor requirement.
> >
> > 	However, the disagreement comes when no requirement from
> flavor, i.e. only image has the resource requirement. For example, for
> serial_port_count, "If flavor extra specs is not set, then any image meta
> value is permitted". For hw_mem_page_size, it's forbidden if only image
> request and no flavor request
> (https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L
> 873 ), and hw_numa_nodes will fail if both flavor and image metadata are
> specified
> (https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L
> 852 ).
> >
> > 	As to this nova spec at https://review.openstack.org/#/c/138937/ ,
> someone (Don, Malini) think if image requires some feature/resource that is
> not specified in flavor, it should be ok, while I think it should be forbidden.
> >
> > 	I discussed with Jay Pipe on IRC before and he thought if flavor has
> no requirement, image requirement should be failed, and I created a bug at
> https://bugs.launchpad.net/nova/+bug/1403276 at that time.  But according
> to the discussion on this BP, seems this is not always accepted by others.
> >
> > 	I hope to get feedback from the mailing list on the relationship of
> requirement from image/flavor. Possibly we should take different policy for
> different resource requirement, but some general rule and the reason for
> those rules will be helpful.
> >
> > 	BTW, This topic was sent to the operator ML yesterday by Malini at
> >   This http://lists.openstack.org/pipermail/openstack-operators/2015-
> January/005882.html and I raise it here to cover both lists.
> >
> > Thanks
> > --jyh
> >
> >
> __________________________________________________________
> ________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev