Open Stack

Hi, Travis
	Thanks for your reply. I think I'm more talking about the resource constraints instead of behavior constraints. My example like  serial_port_count,
memory_pagesize, hw_numa_nodes  etc are all requires resources.  Sorry for the confusion. If image property requires resource that's not specified in flavor, what should be the result.
	
	I'm not sure if there are blanket rule, but maybe there are some generic consideration factor?

Thanks
--jyh

> -----Original Message-----
> From: Tripp, Travis S [mailto:travis.tripp at hp.com]
> Sent: Wednesday, January 21, 2015 6:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] The constraints from flavor and image
> metadata
> 
> 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.p
> y#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.p
> y#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
> 
> 
> __________________________________________________________
> ________________
> 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