perhaps its not as clear cut as i have always understood as you are right this does come up every time we add new extra spec but from me expericence we do allow conflcit on boolean flag between teh image and flavor and raise an exception in this event.
if you would like i can try and add a new doc to the referecne section to describe what i belive the convention has been to date to document the tribeal knowladge i perceive to be true and we can discuss if this is actully the policy we want to enforce. if we decide that we want the policy to be we assess on a case by case basis that is fine too.i
by the way the reason i mention liberty is a release or two after we added cpu pinning and numa in juno i remember a case where we change the behavior of one specific conflict to be a hard fail with an exception but i have tried to find it and i cant. we also had a summit sesson on evolving flaovrs and image propeties in vancouver https://etherpad.openstack.org/p/YVR-nova-flavors-and-image-properties where we were discussing https://review.opendev.org/#/c/178628/5/doc/source/flavors_and_images.rst but i think the convention we have used with all the epa/numa stuff predates that.
its unfortunate that that devref was never completed but i think we would benefit form having one in tree.
i had expected this to be detailed in https:/ /github. com/openstack/ nova/blob/ master/ doc/source/ reference/ scheduler- hints-vs- flavor- extra-specs. rst
i dont know if this pattern is only used in the nova.virt.hardware module /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1511- L1516 /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1530- L1532 /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1539- L1540 /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1543- L1546
https:/
https:/
https:/
https:/
but have a significant number of check that enforce the image cannot exceed limits defined in the
flavor or override values set by the flavor.
there are quantitavie case like the serial port count where we allow an image to requsted fewer /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L171- L211
serial ports then the flavor allows and raise an excpetion otherwise
https:/
for the numa_* values we raise an exception if both the image and flavor try to set the value /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1215- L1298
https:/
for cpu pinning we are slightly smarter and only raise exception if values confilict. /github. com/openstack/ nova/blob/ master/ nova/virt/ hardware. py#L1301- L1378
https:/
perhaps its not as clear cut as i have always understood as you are right this does come up every time we add new extra spec but from me expericence we do allow conflcit on boolean flag between teh image and flavor and raise an exception in this event.
if you would like i can try and add a new doc to the referecne section to describe what i belive the convention has been to date to document the tribeal knowladge i perceive to be true and we can discuss if this is actully the policy we want to enforce. if we decide that we want the policy to be we assess on a case by case basis that is fine too.i
by the way the reason i mention liberty is a release or two after we added cpu pinning and numa in juno i remember a case where we change the behavior of one specific conflict to be a hard fail with an exception but i have tried to find it and i cant. we also had a summit sesson on evolving flaovrs and image propeties in vancouver https:/ /etherpad. openstack. org/p/YVR- nova-flavors- and-image- properties where we were discussing https:/ /review. opendev. org/#/c/ 178628/ 5/doc/source/ flavors_ and_images. rst but i think the convention we have used with all the epa/numa stuff predates that.
its unfortunate that that devref was never completed but i think we would benefit form having one in tree.