JYH, Are you asking for this to be a blanket rule? It seems to me that this could be a case by case basis, but I question making it a blanket rule.
For example, the os_shutdown_timeout property  seems very workload specific. In your proposal, this would mean that the operator would have to add that property with a max value to every single flavor in order for it to be taken advantage of, right? Is that really the desired behavior? Or what about the watchdog behavior (hw_watchdog_action)? It supports an enum of possibilities: "disabled", "reset", "poweroff", "pause", "none² If the flavor provides a default value what would it even mean for an image to specify something different? (https://review.openstack.org/#/c/89650/12) George, Regarding constraints, you should take a look at this: http://docs.openstack.org/developer/glance/metadefs-concepts.html Almost all of the available nova properties with constraint enforcement can be viewed by getting a current devstack, going into horizon, and launching the Update Metadata action on flavors / Host Aggregates, or Images. -Travis On 1/17/15, 7:41 AM, "George Shuklin" <george.shuk...@gmail.com> wrote: >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#L873 >> ), 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#L852 >> ). >> >> 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/005 >>882.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