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.shuk...@gmail.com] > Sent: Saturday, January 17, 2015 6:41 AM > To: openstack-dev@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- > requ...@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- > requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev