Open Stack

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 [1] 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?

[1](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.shuklin at 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-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