)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"88f00b71ec27a871b0f6871f7cb78ec3c44113c3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"94e38152_1df681b1","updated":"2022-02-15 12:56:13.000000000","message":"this is partly a procedual -2 since \nthis is clearly a feature not a bug and it need a spec to discuss the design.\n\n\ni am not conviced we shoudl actully expose these option since QXL is strongly dicusgurated upstream by qemu and downstream in rhel it has been entirly complied out of the qemu that is shipped on redhat based distros and is unsupproted.\n\nif we were to expose these option i woudl want them to be impeletned in a more protable way for all graphsics models. since this consumes adtional ram on the host it als is something ath should be contoel by flaovr extra specs and accounted for in the placment allocations.\n\ngranted teh current hw_video:ram_max_mb is not actully accounted for in placemnt but it really should be.\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/hw_video.py#L23\n\ninstead of addign 3 new parmaters for each seaction i think it would be better to use hw_video:ram_max_mb to limit all allcoations\n\nor better yet move deprecate hw_video:ram_max_mb and add a single new \nhw:video_ram_max_mb option that is used instead since we have a existing todo to move it\nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/hw_video.py#L20\n\nwe would need to make hw_video:ram_max_mb a fallback alias for hw:video_ram_max_mb for backwards compatiablity since we cannot just remove it but we should avoid adding new options to the hw_video namespaces.\n\nthere is other techdebt in this area too \nhttps://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/os.py#L38-L91\nwhere hyperv is currently not using the same extra specs and they are located in the wrong namespace.\n\ncan you please file a spec for this work so that we can discuss this before proceeding with this futher","commit_id":"0b8ae6836a1191f0b257b20b2da9842b104f0af7"},{"author":{"_account_id":34534,"name":"Manuel Bentele","email":"development@manuel-bentele.de","username":"bahnwaerter"},"change_message_id":"2e777d4f4a0d2819f9cb0ee1e4819514a123515e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6e4ba13f_f26cf1ad","in_reply_to":"94e38152_1df681b1","updated":"2022-02-15 14:14:47.000000000","message":"Thanks for this detailed feedback. I will discuss your suggestions with my colleagues before I am going to fill out any spec for a review.\n\nThanks for pointing me out that there are already some extra specs available, like os:monitors. I just overlooked those extra specs.\n\nI have also noticed that the graphics adapter settings are implemented/handled differently. That means, that a unified implementation (for all hypervisors) would be desirable for the future.\n\nFurthermore, I came across the commit https://opendev.org/openstack/nova/commit/f9eea8869eabf12d3e1a078bd48fa96f0badb1ed, which explicitly removes the accounting of graphics memory resources. That\u0027s why it was my long-term plan to also solve this problem after these small feature commits are merged. But now, I am going to fill out a spec first, since there will be a major restructuring and code extension necessary.","commit_id":"0b8ae6836a1191f0b257b20b2da9842b104f0af7"}]}