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/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

Reply via email to