)]}'
{"specs/ussuri/approved/flavor-extra-spec-validators.rst":[{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"ee5c248be1dc417c5e173a0b8a569a8304e6d900","unresolved":false,"context_lines":[{"line_number":18,"context_line":"Flavor extra specs are one of the Wild West aspects of nova. There are a number"},{"line_number":19,"context_line":"of issues we\u0027d like to address:"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"- Lack of documentation for many flavor extra specs [1]_. While, Glance has"},{"line_number":22,"context_line":"  metadefs [2]_, those are generally out-of-date, incomplete, and not"},{"line_number":23,"context_line":"  consumable from nova and our user-facing documentation."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_8985f609","line":21,"range":{"start_line":21,"start_character":62,"end_line":21,"end_character":64},"updated":"2019-10-23 00:01:48.000000000","message":"Nit: Drop the comma.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fdad7aa0455c631b3d2bec0730016a810f1d3080","unresolved":false,"context_lines":[{"line_number":18,"context_line":"Flavor extra specs are one of the Wild West aspects of nova. There are a number"},{"line_number":19,"context_line":"of issues we\u0027d like to address:"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"- Lack of documentation for many flavor extra specs [1]_. While, Glance has"},{"line_number":22,"context_line":"  metadefs [2]_, those are generally out-of-date, incomplete, and not"},{"line_number":23,"context_line":"  consumable from nova and our user-facing documentation."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_e60e6cd6","line":21,"range":{"start_line":21,"start_character":62,"end_line":21,"end_character":64},"in_reply_to":"3fa7e38b_8985f609","updated":"2020-01-29 11:40:03.000000000","message":"Done","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  extra spec B be configured first. We will document the dependency but it"},{"line_number":62,"context_line":"  won\u0027t be enforced."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"- Enforcement of virt driver dependencies. Unfortunately, while flavor extra"},{"line_number":65,"context_line":"  specs should be generic, this isn\u0027t always the case. As above, we will"},{"line_number":66,"context_line":"  document this dependency but it won\u0027t be enforced."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_8280e49d","line":64,"range":{"start_line":64,"start_character":17,"end_line":64,"end_character":41},"updated":"2020-01-28 00:27:44.000000000","message":"Meaning what? We\u0027re not going to validate that extra spec A is only relevant when using virt driver X? Or we won\u0027t validate any extra specs that are specific to virt driver X? Assuming the former.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  extra spec B be configured first. We will document the dependency but it"},{"line_number":62,"context_line":"  won\u0027t be enforced."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"- Enforcement of virt driver dependencies. Unfortunately, while flavor extra"},{"line_number":65,"context_line":"  specs should be generic, this isn\u0027t always the case. As above, we will"},{"line_number":66,"context_line":"  document this dependency but it won\u0027t be enforced."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_21330ef9","line":64,"range":{"start_line":64,"start_character":17,"end_line":64,"end_character":41},"in_reply_to":"3fa7e38b_4ff525cb","updated":"2020-01-29 12:19:19.000000000","message":"example being hw:cpu_realtime_mask is only valid/supported with the libvirt driver but while we can document that we wont do any enforcement of it.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  extra spec B be configured first. We will document the dependency but it"},{"line_number":62,"context_line":"  won\u0027t be enforced."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"- Enforcement of virt driver dependencies. Unfortunately, while flavor extra"},{"line_number":65,"context_line":"  specs should be generic, this isn\u0027t always the case. As above, we will"},{"line_number":66,"context_line":"  document this dependency but it won\u0027t be enforced."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_d48be813","line":64,"range":{"start_line":64,"start_character":17,"end_line":64,"end_character":41},"in_reply_to":"3fa7e38b_8280e49d","updated":"2020-01-28 14:47:41.000000000","message":"The former, yes. We can\u0027t do that because this code runs on the controller node (nova-api), not the compute node.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":61,"context_line":"  extra spec B be configured first. We will document the dependency but it"},{"line_number":62,"context_line":"  won\u0027t be enforced."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"- Enforcement of virt driver dependencies. Unfortunately, while flavor extra"},{"line_number":65,"context_line":"  specs should be generic, this isn\u0027t always the case. As above, we will"},{"line_number":66,"context_line":"  document this dependency but it won\u0027t be enforced."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_4ff525cb","line":64,"range":{"start_line":64,"start_character":17,"end_line":64,"end_character":41},"in_reply_to":"3fa7e38b_d48be813","updated":"2020-01-28 15:09:12.000000000","message":"Ack, makes sense.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":68,"context_line":"- Hard enforcement of key validation. Eventually we will want to track all"},{"line_number":69,"context_line":"  possible extra spec names and raise a warning or error for errant values, but"},{"line_number":70,"context_line":"  this is likely to take some time to perfect. In the interim, we will merely"},{"line_number":71,"context_line":"  log these potentially errant values."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This change builds upon `Flavor extra spec image metadata validation"},{"line_number":74,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/flavor-extra-spec-image-property-validation.html\u003e`__,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_826ea4fb","line":71,"updated":"2020-01-28 00:27:44.000000000","message":"I thought the \"pluggable\" aspect of this was the ability for the deployer to lay down a file that would enumerate all the legal keys (or key patterns) that we don\u0027t explicitly know about already in nova. That way we *could* do strict enforcement like this.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":68,"context_line":"- Hard enforcement of key validation. Eventually we will want to track all"},{"line_number":69,"context_line":"  possible extra spec names and raise a warning or error for errant values, but"},{"line_number":70,"context_line":"  this is likely to take some time to perfect. In the interim, we will merely"},{"line_number":71,"context_line":"  log these potentially errant values."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This change builds upon `Flavor extra spec image metadata validation"},{"line_number":74,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/flavor-extra-spec-image-property-validation.html\u003e`__,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_a175be98","line":71,"in_reply_to":"3fa7e38b_54693823","updated":"2020-01-29 12:19:19.000000000","message":"well there is a different plugable aspect to this spec. by defining a stevadore entry point we also allow other projects like cyborg to package a validator for there extra specs if they chose too.\n\nfor operators we a file might be simpler to use but for other project i think it makes sense to allow them to implement it in python.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f1fbfe8ca85c2c6b23ba0ca71d38f5dc07656616","unresolved":false,"context_lines":[{"line_number":68,"context_line":"- Hard enforcement of key validation. Eventually we will want to track all"},{"line_number":69,"context_line":"  possible extra spec names and raise a warning or error for errant values, but"},{"line_number":70,"context_line":"  this is likely to take some time to perfect. In the interim, we will merely"},{"line_number":71,"context_line":"  log these potentially errant values."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This change builds upon `Flavor extra spec image metadata validation"},{"line_number":74,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/flavor-extra-spec-image-property-validation.html\u003e`__,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_54693823","line":71,"in_reply_to":"3fa7e38b_7fae962f","updated":"2020-01-28 14:54:48.000000000","message":"Well, that would be the advantage to having a conf opt like I suggest on L240. By default it\u0027s off (you just get warnings), but you can dial it up to enforce known keys, and then further to restrict to only known keys. That\u0027s a gradual introduction plan that\u0027s in the user\u0027s control.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":68,"context_line":"- Hard enforcement of key validation. Eventually we will want to track all"},{"line_number":69,"context_line":"  possible extra spec names and raise a warning or error for errant values, but"},{"line_number":70,"context_line":"  this is likely to take some time to perfect. In the interim, we will merely"},{"line_number":71,"context_line":"  log these potentially errant values."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This change builds upon `Flavor extra spec image metadata validation"},{"line_number":74,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/flavor-extra-spec-image-property-validation.html\u003e`__,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_74c3143a","line":71,"in_reply_to":"3fa7e38b_826ea4fb","updated":"2020-01-28 14:47:41.000000000","message":"\u003e I thought the \"pluggable\" aspect of this was the ability for the\n \u003e deployer to lay down a file that would enumerate all the legal keys\n \u003e (or key patterns) that we don\u0027t explicitly know about already in\n \u003e nova. That way we *could* do strict enforcement like this.\n\nYup, that\u0027s what I was hoping to go for. However, we discussed this in Denver and mriedem and dansmith (I think) said it was too high a bar to clear and that I\u0027d be better off focusing on the value side first. I\u0027d personally like to change do both at once but I guess I need a critical mass of support for the idea to be able to do it","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f3faf503e3aa5d5a2abc20898b6ac266d1cc8b83","unresolved":false,"context_lines":[{"line_number":68,"context_line":"- Hard enforcement of key validation. Eventually we will want to track all"},{"line_number":69,"context_line":"  possible extra spec names and raise a warning or error for errant values, but"},{"line_number":70,"context_line":"  this is likely to take some time to perfect. In the interim, we will merely"},{"line_number":71,"context_line":"  log these potentially errant values."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"This change builds upon `Flavor extra spec image metadata validation"},{"line_number":74,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/flavor-extra-spec-image-property-validation.html\u003e`__,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_7fae962f","line":71,"in_reply_to":"3fa7e38b_826ea4fb","updated":"2020-01-28 09:05:48.000000000","message":"If we want to do that then we need a gradual introduction plan. It would be a pain for the deployer to see that after Ussuri upgrade very flavor create with some deloyment specific spec key would suddenly fail. I think this gradual approach is what Stephen suggests. We warn about unknown specs to let the deployer know that she needs to lay down definition files.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"- Name or *key* of the extra spec, e.g. ``cpu_policy`` for the above example"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"- Namespace of the extra spec, e.g. ``hw`` for the above example"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"- Description of the extra spec"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_e2167858","line":90,"range":{"start_line":90,"start_character":2,"end_line":90,"end_character":11},"updated":"2020-01-28 00:27:44.000000000","message":"Do all extra specs have a namespace?\n\nFor extra specs describing granular request groups (assuming we\u0027re going to allow those at all, which I guess is still under discussion) this would need to be patternable somehow.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"- Name or *key* of the extra spec, e.g. ``cpu_policy`` for the above example"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"- Namespace of the extra spec, e.g. ``hw`` for the above example"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"- Description of the extra spec"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_dbf54953","line":90,"range":{"start_line":90,"start_character":2,"end_line":90,"end_character":11},"in_reply_to":"3fa7e38b_b4e2ecd1","updated":"2020-01-29 10:36:11.000000000","message":"Turns out there\u0027s one in-tree extra spec that does not. There\u0027s probably a few out-of-tree ones too. Will update","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":87,"context_line":""},{"line_number":88,"context_line":"- Name or *key* of the extra spec, e.g. ``cpu_policy`` for the above example"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"- Namespace of the extra spec, e.g. ``hw`` for the above example"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"- Description of the extra spec"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_b4e2ecd1","line":90,"range":{"start_line":90,"start_character":2,"end_line":90,"end_character":11},"in_reply_to":"3fa7e38b_e2167858","updated":"2020-01-28 14:47:41.000000000","message":"To the best of my knowledge, yes.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"ee5c248be1dc417c5e173a0b8a569a8304e6d900","unresolved":false,"context_lines":[{"line_number":102,"context_line":"- Extra spec dependencies; this is only for documentation purposes and will not"},{"line_number":103,"context_line":"  be enforced"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"For many extra specs namespaces, we propose maintaining the definitions"},{"line_number":106,"context_line":"in-tree. To do this, we propose adding a new module,"},{"line_number":107,"context_line":"``nova.api.validation.extra_specs``, which will contain definitions for *flavor"},{"line_number":108,"context_line":"validators*. These will be defined using two new base objects,"},{"line_number":109,"context_line":"``BaseValidator`` and ``BaseExtraSpec``. ``BaseValidator`` will be subclassed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_29cf2258","line":106,"range":{"start_line":105,"start_character":0,"end_line":106,"end_character":7},"updated":"2019-10-23 00:01:48.000000000","message":"AFAICS, the exact list of these namespaces is not spelt out in this spec. Only some examples are mentioned below. It may be better to state the list for Ussuri, so contain the scope.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":102,"context_line":"- Extra spec dependencies; this is only for documentation purposes and will not"},{"line_number":103,"context_line":"  be enforced"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"For many extra specs namespaces, we propose maintaining the definitions"},{"line_number":106,"context_line":"in-tree. To do this, we propose adding a new module,"},{"line_number":107,"context_line":"``nova.api.validation.extra_specs``, which will contain definitions for *flavor"},{"line_number":108,"context_line":"validators*. These will be defined using two new base objects,"},{"line_number":109,"context_line":"``BaseValidator`` and ``BaseExtraSpec``. ``BaseValidator`` will be subclassed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_fb9e05f8","line":106,"range":{"start_line":105,"start_character":0,"end_line":106,"end_character":7},"in_reply_to":"3fa7e38b_0ffbadbe","updated":"2020-01-29 10:36:11.000000000","message":"Nope, no new microversions. It doesn\u0027t really make sense. We could do microversions for new extra specs added in-tree but what about custom extra specs used by operators? They could add (or even remove) extra specs but they couldn\u0027t create a new microversion. The microversion will exist to turn on validation. After that, we can add additional extra specs as required","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"35d0cc5576b4b25f3051beefacd34707d351bf75","unresolved":false,"context_lines":[{"line_number":102,"context_line":"- Extra spec dependencies; this is only for documentation purposes and will not"},{"line_number":103,"context_line":"  be enforced"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"For many extra specs namespaces, we propose maintaining the definitions"},{"line_number":106,"context_line":"in-tree. To do this, we propose adding a new module,"},{"line_number":107,"context_line":"``nova.api.validation.extra_specs``, which will contain definitions for *flavor"},{"line_number":108,"context_line":"validators*. These will be defined using two new base objects,"},{"line_number":109,"context_line":"``BaseValidator`` and ``BaseExtraSpec``. ``BaseValidator`` will be subclassed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_42866cb9","line":106,"range":{"start_line":105,"start_character":0,"end_line":106,"end_character":7},"in_reply_to":"3fa7e38b_29cf2258","updated":"2020-01-27 17:16:55.000000000","message":"The scope is every extra spec I can find registered in nova, right now :) I might miss some which we\u0027ll resolve with bugfixes and deployment-specific YAML files.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":102,"context_line":"- Extra spec dependencies; this is only for documentation purposes and will not"},{"line_number":103,"context_line":"  be enforced"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"For many extra specs namespaces, we propose maintaining the definitions"},{"line_number":106,"context_line":"in-tree. To do this, we propose adding a new module,"},{"line_number":107,"context_line":"``nova.api.validation.extra_specs``, which will contain definitions for *flavor"},{"line_number":108,"context_line":"validators*. These will be defined using two new base objects,"},{"line_number":109,"context_line":"``BaseValidator`` and ``BaseExtraSpec``. ``BaseValidator`` will be subclassed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_0ffbadbe","line":106,"range":{"start_line":105,"start_character":0,"end_line":106,"end_character":7},"in_reply_to":"3fa7e38b_42866cb9","updated":"2020-01-28 15:09:12.000000000","message":"Not, as suggested on L326, subsequent microversions, right?","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":109,"context_line":"``BaseValidator`` and ``BaseExtraSpec``. ``BaseValidator`` will be subclassed"},{"line_number":110,"context_line":"to represent a namespace while ``BaseExtraSpec`` will be subclassed to"},{"line_number":111,"context_line":"represent an individual extra spec. ``BaseExtraSpec`` subclasses will be"},{"line_number":112,"context_line":"registered again a namespace."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"For example:"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_fd4cd975","line":112,"range":{"start_line":112,"start_character":11,"end_line":112,"end_character":16},"updated":"2020-01-28 00:27:44.000000000","message":"against","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":111,"context_line":"represent an individual extra spec. ``BaseExtraSpec`` subclasses will be"},{"line_number":112,"context_line":"registered again a namespace."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"For example:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. code-block:: python"},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_78fb1415","line":114,"updated":"2020-01-28 00:27:44.000000000","message":"I\u0027ll just note that, while I appreciate seeing this implementation detail, it may be counterproductive to getting the spec merged, since it\u0027s inviting \"code review\" to happen now.\n\nTo that end...","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. code-block:: python"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"    class HWValidator(BaseValidator):"},{"line_number":119,"context_line":"        \"\"\"A validator for the ``hw`` namespace.\"\"\""},{"line_number":120,"context_line":"        name \u003d \u0027hw\u0027"},{"line_number":121,"context_line":"        description \u003d ("}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_8b0f9c2d","line":118,"range":{"start_line":118,"start_character":10,"end_line":118,"end_character":21},"updated":"2020-01-28 00:27:44.000000000","message":"I know it could get mealy, but it would be nice to be able to distinguish this as a namespace validator without having to look at the inheritance (esp if things get more nested in the future). So, HWNamespaceValidator.\n\nThat said, what\u0027s Validator-y about this? I guess maybe I could tell by seeing BaseValidator (which should also have \u0027Namespace\u0027 in its name).\n\nGotta say, I\u0027m not understanding the value of splitting out the representation of the namespace into its own class. What\u0027s the justification for that?","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. code-block:: python"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"    class HWValidator(BaseValidator):"},{"line_number":119,"context_line":"        \"\"\"A validator for the ``hw`` namespace.\"\"\""},{"line_number":120,"context_line":"        name \u003d \u0027hw\u0027"},{"line_number":121,"context_line":"        description \u003d ("}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_94549057","line":118,"range":{"start_line":118,"start_character":10,"end_line":118,"end_character":21},"in_reply_to":"3fa7e38b_8b0f9c2d","updated":"2020-01-28 14:47:41.000000000","message":"\u003e I know it could get mealy, but it would be nice to be able to\n \u003e distinguish this as a namespace validator without having to look at\n \u003e the inheritance (esp if things get more nested in the future). So,\n \u003e HWNamespaceValidator.\n \u003e\n \u003e That said, what\u0027s Validator-y about this? I guess maybe I could\n \u003e tell by seeing BaseValidator (which should also have \u0027Namespace\u0027 in\n \u003e its name).\n\nIn the PoC I\u0027m drafting locally, this is totally changed. The base is called \u0027BaseNamespace\u0027 and the subclasses are called e.g. \u0027HWNamespace\u0027\n\n \u003e Gotta say, I\u0027m not understanding the value of splitting out the\n \u003e representation of the namespace into its own class. What\u0027s the\n \u003e justification for that?\n\nI was mimicking what we do for config options, tbh. I figured this would be easier for things like documentation and it also mapped quite well to the stevedore idea since it gave me an entry point","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":123,"context_line":"            \u0027associated with instances.\u0027"},{"line_number":124,"context_line":"        )"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"    class CPUPolicy(BaseExtraSpec):"},{"line_number":127,"context_line":"        \"\"\"A validator for the ``hw:cpu_policy`` extra spec.\"\"\""},{"line_number":128,"context_line":"        name \u003d \u0027cpu_policy\u0027"},{"line_number":129,"context_line":"        description \u003d ("}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_0b25ecad","line":126,"range":{"start_line":126,"start_character":10,"end_line":126,"end_character":19},"updated":"2020-01-28 00:27:44.000000000","message":"Similarly here, CPUPolicyExtraSpec.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":123,"context_line":"            \u0027associated with instances.\u0027"},{"line_number":124,"context_line":"        )"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"    class CPUPolicy(BaseExtraSpec):"},{"line_number":127,"context_line":"        \"\"\"A validator for the ``hw:cpu_policy`` extra spec.\"\"\""},{"line_number":128,"context_line":"        name \u003d \u0027cpu_policy\u0027"},{"line_number":129,"context_line":"        description \u003d ("}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_d4ec4893","line":126,"range":{"start_line":126,"start_character":10,"end_line":126,"end_character":19},"in_reply_to":"3fa7e38b_0b25ecad","updated":"2020-01-28 14:47:41.000000000","message":"I don\u0027t use this at all anymore. Instead, I\u0027m using dataclasses [1] and just registering things locally.\n\n  extra_specs \u003d [\n      base.ExtraSpecValidator(\n          name\u003d\u0027cpu_policy\u0027,\n          ...\n      ),\n      ...\n  ]\n\n  \n  for extra_spec in extra_specs:\n      HWValidator.register(extra_spec)\n\nBut now we\u0027re properly getting into the weeds :)\n\n[1] https://docs.python.org/3/library/dataclasses.html","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":123,"context_line":"            \u0027associated with instances.\u0027"},{"line_number":124,"context_line":"        )"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"    class CPUPolicy(BaseExtraSpec):"},{"line_number":127,"context_line":"        \"\"\"A validator for the ``hw:cpu_policy`` extra spec.\"\"\""},{"line_number":128,"context_line":"        name \u003d \u0027cpu_policy\u0027"},{"line_number":129,"context_line":"        description \u003d ("}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_7b68d5f1","line":126,"range":{"start_line":126,"start_character":10,"end_line":126,"end_character":19},"in_reply_to":"3fa7e38b_d4ec4893","updated":"2020-01-29 10:36:11.000000000","message":"This has changed again. I\u0027m going to strip out all this stuff.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":141,"context_line":"                \u0027dedicated\u0027,"},{"line_number":142,"context_line":"                \u0027shared\u0027"},{"line_number":143,"context_line":"            ],"},{"line_number":144,"context_line":"        }"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"    class NUMACPUs(BaseExtraSpec):"},{"line_number":147,"context_line":"        \"\"\"A validator for the ``hw:numa_cpu.{id}`` extra spec.\"\"\""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_6b3ee0b6","line":144,"updated":"2020-01-28 00:27:44.000000000","message":"I was expecting to see something here like\n\n namespace \u003d HWValidator\n\nto tie this back to its namespace. I assume it won\u0027t ever be useful to have an extra spec that shows up in multiple namespaces. (Wrinkle, granular request groups would technically be different namespaces, but I would expect them to be defined by their regex rather than explicitly.)","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_ce1a8269","line":177,"range":{"start_line":177,"start_character":49,"end_line":177,"end_character":58},"updated":"2020-01-28 00:27:44.000000000","message":"A thing that concerns me here is where $service, that knows about the extra specs it cares about, is running on the compute node. How do the extensions get up into the controller node? (That\u0027s where they\u0027re used, right? By n-api?)\n\nTrick question, of course, since $service can be running at different levels (or not at all) on different compute nodes, and would potentially be reporting conflicting validators at the same paths.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_61eee620","line":177,"range":{"start_line":177,"start_character":49,"end_line":177,"end_character":58},"in_reply_to":"3fa7e38b_3b6eddfd","updated":"2020-01-29 12:19:19.000000000","message":"the stevador approch should stay IMO.\n\nthis has nothing to do with what service is or is not running on the compute nodes. i proposed using stevador so that third party virt drivers or other projets like cyborg so simply export a validtor without needing to modify nova code for it to work. i think that is a much cleaner approch then requiring multiple yaml files because if nothing else it allows them to use a yaml file if that is what they choose.\nthey just need to implement a parser for it.\n\nthe only draw back to sevador is it assume that the packages would be installed in the same filesystem. so you might need to include cyborg in the nova contanier if you are doing a docker deployment. that could be an argument that the validator for other project should be in a seperate repo although for 3rd party virt driver i think it still make sese to put them together.\n\nif we must drop this so be it but not forceing people to write yaml files is a big plus to keeping it.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_3b6eddfd","line":177,"range":{"start_line":177,"start_character":49,"end_line":177,"end_character":58},"in_reply_to":"3fa7e38b_5485b8ac","updated":"2020-01-29 10:36:11.000000000","message":"Actually, what about third-part nova virt drivers? There\u0027s a chance those could include additional extra specs and we\u0027d have to be able to find those so we could validate them. The alternative is to provide the ability to use multiple YAML files and ask that third-party virt drivers provide such a file","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e438d22a8fe7a92326e07aadf6955f6d5cd6bccc","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_9936f6b2","line":177,"range":{"start_line":177,"start_character":49,"end_line":177,"end_character":58},"in_reply_to":"3fa7e38b_61eee620","updated":"2020-01-29 14:57:41.000000000","message":"Maybe I\u0027m misunderstanding what you\u0027re getting at here, but it sounds like you\u0027re implying that writing python code and stevedore plumbing and making sure the right packages are included in the controller install is somehow simpler/easier than writing a YAML file and putting it in a directory.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_5485b8ac","line":177,"range":{"start_line":177,"start_character":49,"end_line":177,"end_character":58},"in_reply_to":"3fa7e38b_ce1a8269","updated":"2020-01-28 14:47:41.000000000","message":"Hmm, good point. I didn\u0027t think about that. For this reason and the others you\u0027ve listed later, I\u0027m thinking the stevedore idea should go too","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"ee5c248be1dc417c5e173a0b8a569a8304e6d900","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_09a6e6ac","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"updated":"2019-10-23 00:01:48.000000000","message":"For Cyborg, it will literally be a single key --\n\"accel:device_profile\" -- since all other accel properties will be inside the device profile itself and not exposed to nova. That single key has a string value, and that string has a fairly simple regex. \n\nSecondly, Nova is already hardcoding that namespace and key [1]. \n\nSo, this _could_ be overkill for Cyborg, though I understand the desire for modularity.\n\n[1] https://review.opendev.org/#/c/631243/40/nova/compute/api.py@1105","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fd1f75db8ff48f4cfc0748e4e2e2c686489b54c8","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_51107c4c","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_09a6e6ac","updated":"2020-01-27 13:45:38.000000000","message":"For me it is OK to take Cyborg\u0027s extra spec validation into the nova tree.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_f4bdc466","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_1f9522e3","updated":"2020-01-28 14:47:41.000000000","message":"Fair point. Okay, let\u0027s drop the stevedore idea","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0a2aa3d34ab27ff63eb5d8d69783701c604fc78f","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_54862ab9","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_51107c4c","updated":"2020-01-27 15:23:56.000000000","message":"No, I wouldn\u0027t personnally want to have Cyborg specifics be in the Nova tree, unless we have a solid problem explanation telling us what prevents Cyborg to implement the proposal above.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"35d0cc5576b4b25f3051beefacd34707d351bf75","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_c2b33c98","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_54862ab9","updated":"2020-01-27 17:16:55.000000000","message":"Agree with Sylvain. This should be trivial for cyborg to implement and avoids us having to worry about anything if e.g. cyborg introduced new extra specs in the future.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f3faf503e3aa5d5a2abc20898b6ac266d1cc8b83","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_1f9522e3","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_8bcc7c8a","updated":"2020-01-28 09:05:48.000000000","message":"I agree with Eric here. If nova needs to understand the internals of such spec then the validation code can (should) be in nova too.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":174,"context_line":"While many of the definitions will be maintained in-tree, some namespaces will"},{"line_number":175,"context_line":"require special handling as they\u0027re owned by external services, e.g. the"},{"line_number":176,"context_line":"``traits`` namespace (owned by os-traits) or the ``accel`` namespace (proposed"},{"line_number":177,"context_line":"for use by cyborg). For these, we propose using `stevedore`_ to allow external"},{"line_number":178,"context_line":"projects to register custom validators. For example, nova would provide the"},{"line_number":179,"context_line":"following:"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":".. code-block:: ini"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_8bcc7c8a","line":178,"range":{"start_line":177,"start_character":20,"end_line":178,"end_character":38},"in_reply_to":"3fa7e38b_c2b33c98","updated":"2020-01-28 00:27:44.000000000","message":"Pretty sure I don\u0027t agree with this at all. While accel:device_profile (for example) is used in the integration with cyborg, it is discovered, parsed, and used by *nova code*, so its validator definition should live in nova.\n\nSimilarly, the \u0027trait\u0027 namespace is used to refer to os-trait-y things, but it\u0027s processed by nova, and it\u0027s only the parsed results that we feed into os-traits (including indirectly via placement) for any purpose. (Aside: this paragraph draws a ring around accel/cyborg and trait/os-traits as things that should be stevedored, but the subsequent example puts traits in the nova-provided section.)\n\nIMO the only namespace or extra spec that should be registered by an outside agent is one that is sought in the flavor, parsed, and processed by that outside agent. The act of registering them would be solely to glean the benefit of nova doing this validation.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"ee5c248be1dc417c5e173a0b8a569a8304e6d900","unresolved":false,"context_lines":[{"line_number":193,"context_line":".. code-block:: ini"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"    nova.extra_spec_validators \u003d"},{"line_number":196,"context_line":"        accel \u003d cyborg.extra_specs_validator:AccelValidator"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Finally, there are extra specs that are operator defined and therefore will not"},{"line_number":199,"context_line":"be known by a consuming service. For these, we propose introducing a schema"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_c9076e81","line":196,"updated":"2019-10-23 00:01:48.000000000","message":"A. This assumes that Cyborg should provide a module named extra_specs_validator, with an API defined by Nova, right?\n\nB. What about deployments with Nova but not Cyborg (or some other service that is listed above)?","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":193,"context_line":".. code-block:: ini"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"    nova.extra_spec_validators \u003d"},{"line_number":196,"context_line":"        accel \u003d cyborg.extra_specs_validator:AccelValidator"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Finally, there are extra specs that are operator defined and therefore will not"},{"line_number":199,"context_line":"be known by a consuming service. For these, we propose introducing a schema"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_21422e0e","line":196,"in_reply_to":"3fa7e38b_149512e3","updated":"2020-01-29 12:19:19.000000000","message":"this is an example of how any external service such as cyborg can optionaly implement a vlaidtor for the nova validation api entry point.\n\nthose two lines woudl be added to the the cyborg setup.cfg\nthe left hand side \"accel\" is declaring the namesapce it validates and the right had side is the setuptools entrypoint syntax for delcaring a class the inplmenets the interface\n\"cyborg.extra_specs_validator:AccelValidator\"\nso this is a class call AccelValiator in the cyborg.extra_specs module but the name can by any vaild class and woudl be up to cyborg to choose.\n\nif the cyborg package was not present on the contoler where the api is installed the then no validator for the accel nameapse woudl auto matically be loaded and it would fall back to the yaml validator\n\n * \u003d nova.validators.extra_specs:YAMLValidator\n\nif the accel namespace was used in a flavor then it would either raise an error because you tried to use cyborg when its not installed or follow the rules set in the yaml file if you defiend them.\n\nin either case B shoudl not be an issue.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0a2aa3d34ab27ff63eb5d8d69783701c604fc78f","unresolved":false,"context_lines":[{"line_number":193,"context_line":".. code-block:: ini"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"    nova.extra_spec_validators \u003d"},{"line_number":196,"context_line":"        accel \u003d cyborg.extra_specs_validator:AccelValidator"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Finally, there are extra specs that are operator defined and therefore will not"},{"line_number":199,"context_line":"be known by a consuming service. For these, we propose introducing a schema"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_149512e3","line":196,"in_reply_to":"3fa7e38b_c9076e81","updated":"2020-01-27 15:23:56.000000000","message":"A. yes\nB. I don\u0027t see the problem you imply. It\u0027s just configuration.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":201,"context_line":"specs available. The YAML format is chosen as it allows us to define a"},{"line_number":202,"context_line":"specification in a declarative manner while avoiding the need to write Python"},{"line_number":203,"context_line":"code. The format of this file will nonetheless mirror the format of the Python"},{"line_number":204,"context_line":"objects. For example:"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":".. code-block:: yaml"},{"line_number":207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_ee52de10","line":204,"updated":"2020-01-28 00:27:44.000000000","message":"I\u0027m kinda wondering why we would bother with the stevedore thing, which seems complex and fraught with pitfalls, rather than just doing the yaml thing across the board. I guess the stevedore mechanism would allow for more algorithmic validation, but do we really need that (yet)?\n\nIf we supported multiple files in a directory like we\u0027re doing for provider config, external services could lay them down at install time or whatever, and operators could still hand-write one (or multiple) as you\u0027re suggesting.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":201,"context_line":"specs available. The YAML format is chosen as it allows us to define a"},{"line_number":202,"context_line":"specification in a declarative manner while avoiding the need to write Python"},{"line_number":203,"context_line":"code. The format of this file will nonetheless mirror the format of the Python"},{"line_number":204,"context_line":"objects. For example:"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":".. code-block:: yaml"},{"line_number":207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_f44b8482","line":204,"in_reply_to":"3fa7e38b_ee52de10","updated":"2020-01-28 14:47:41.000000000","message":"We\u0027ve got two types of extra specs - in-tree and out-of-tree. For the former, I\u0027d much rather define these as Python objects since that\u0027s what I\u0027m used to working with expect and it prevents people thinking they can go and hack on the schema willy-nilly. For the latter, I think YAML does the job since it\u0027s far more accessible to end-users (they don\u0027t need to learn Python).","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":201,"context_line":"specs available. The YAML format is chosen as it allows us to define a"},{"line_number":202,"context_line":"specification in a declarative manner while avoiding the need to write Python"},{"line_number":203,"context_line":"code. The format of this file will nonetheless mirror the format of the Python"},{"line_number":204,"context_line":"objects. For example:"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":".. code-block:: yaml"},{"line_number":207,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_6fdee13c","line":204,"in_reply_to":"3fa7e38b_f44b8482","updated":"2020-01-28 15:09:12.000000000","message":"Yeah, totally do the in-tree stuff in code. We\u0027re in agreement here.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_6e57cef6","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"updated":"2020-01-28 00:27:44.000000000","message":"++ microversion, but I would also expect a granny switch conf opt to turn validation on or off wholesale.\n\nIn fact, I would eventually expect that conf option to allow several levels of validation. At least:\n- strict (unknown keys are bounced - I\u0027m asserting all possible legal keys have been registered)\n- loose (unknown keys are ignored)\n- off","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e438d22a8fe7a92326e07aadf6955f6d5cd6bccc","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_59a63ec1","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"in_reply_to":"3fa7e38b_260a441d","updated":"2020-01-29 14:57:41.000000000","message":"\u003e Microversions aren\u0027t an all-or-nothing affair. I can make a request\n \u003e to the \u0027/flavors/{flavor_id}/os-extra_specs\u0027 API using an older\n \u003e microversion and then use the newer one for the rest of the flow.\n\nRight, I get that. That works until we cut a new microversion that affects the flavor API.\n\n \u003e In addition, I\u0027m not sure why you\u0027d want to opt out of this\n \u003e long-term.\n\nAs noted above, I can definitely see a phase where I want to take advantage of the validation you\u0027re writing for in-tree extra specs without having to write YAML files for the outside stuff.\n\n \u003e It\u0027s a useful feature and while there may be a small bit\n \u003e of work required by operators to configure their YAML file for any\n \u003e out of tree extra specs they may have\n\nIt\u0027s not necessarily a small bit of work, depending on the situation/deployment/etc.\n\nI can also see a use case where I want to define a flavor with a truly one-off extra spec that\u0027s not appropriate to include in my long-term validation. I sure don\u0027t want to have to go lay down a YAML file so I can execute my command and then remove the file again. But I still want the other 99% of my extra specs validated according to the in-tree and YAML validators I\u0027ve taken pains to set up.\n\nAnyway, I\u0027m not going to die on a hill for this; I just think it would make some things more user friendly and it\u0027s really cheap to do.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_819d226d","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"in_reply_to":"3fa7e38b_260a441d","updated":"2020-01-29 12:19:19.000000000","message":"the intent is the validation will only be done when defining/updating a flavor so yes if you just want to disable validation then you can use an older microversion for that call however if we modify the flavor at some point in the future like remove vcpus or add composablity then you would be out of luck.\n\ni think the 3 level config option makes sesne.\n\ni would go with strict, permissive and off to mirror selinux\npersonally instead of loose","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_6f6b4185","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"in_reply_to":"3fa7e38b_540a9826","updated":"2020-01-28 15:09:12.000000000","message":"My concern is, when we introduce a subsequent microversion, you wouldn\u0027t be able to opt out of the extra spec validation and also get the benefit of the new feature.\n\nBut hm, yeah, I get what you mean about config-driven API behavior. That\u0027s a weird one. I don\u0027t suppose a qparam...?","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_540a9826","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"in_reply_to":"3fa7e38b_6e57cef6","updated":"2020-01-28 14:47:41.000000000","message":"Can\u0027t do that. That would imply config-driver API behavior, which is something we try avoid nowadays. It\u0027s possible that we could make a mistake or forget some extra specs when implementing the validators, but those issues should be fixed with bugfix patches, not by disabling validation","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":237,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":240,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":241,"context_line":"introduced for this command to avoid breaking existing tools that are"},{"line_number":242,"context_line":"inadvertently setting the wrong values."},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_260a441d","line":240,"range":{"start_line":240,"start_character":56,"end_line":240,"end_character":70},"in_reply_to":"3fa7e38b_6f6b4185","updated":"2020-01-29 10:36:11.000000000","message":"\u003e My concern is, when we introduce a subsequent microversion, you\n \u003e wouldn\u0027t be able to opt out of the extra spec validation and also\n \u003e get the benefit of the new feature.\n\nMicroversions aren\u0027t an all-or-nothing affair. I can make a request to the \u0027/flavors/{flavor_id}/os-extra_specs\u0027 API using an older microversion and then use the newer one for the rest of the flow. In addition, I\u0027m not sure why you\u0027d want to opt out of this long-term. It\u0027s a useful feature and while there may be a small bit of work required by operators to configure their YAML file for any out of tree extra specs they may have, that\u0027s a once off and no different from e.g. having to migrate off deprecated features.\n\nAlso note that there is precedent for these changes. A recent API microversion from gmann (I\u0027ve to dig out the exact version) introduced strict API validation. Anyone who started using this new API microversion with additional keys would suddenly start seeing failure. This seems like the exact same thing.\n\n \u003e But hm, yeah, I get what you mean about config-driven API behavior.\n \u003e That\u0027s a weird one. I don\u0027t suppose a qparam...?\n\nPer above, I don\u0027t think we need to do this. Use the older microversion if you really don\u0027t want validation","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"ee5c248be1dc417c5e173a0b8a569a8304e6d900","unresolved":false,"context_lines":[{"line_number":251,"context_line":""},{"line_number":252,"context_line":"    hw:cpu_pollllicy\u003ddedicated"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"This involves maintaining a registry of valid extra specs. Not all extra specs"},{"line_number":255,"context_line":"can be known ahead of time and for dynamic extra specs, such as those proposed"},{"line_number":256,"context_line":"in `Support filtering by forbidden aggregate membership"},{"line_number":257,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/approved/negative-aggregate-membership.html\u003e`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_094266ac","line":254,"updated":"2019-10-23 00:01:48.000000000","message":"Nova could call the external service\u0027s validator based on name space alone, and let that service validate the key as well as the value. For example, for \u0027accel:device-profile\u0027, Nova would call Cyborg based on \u0027accel\u0027, and Cyborg would reject it as it should be \u0027device_profile\u0027 . If the name space itself is mis-spelt, well, may be Nova could standardize the namespaces and enforce them.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0a2aa3d34ab27ff63eb5d8d69783701c604fc78f","unresolved":false,"context_lines":[{"line_number":251,"context_line":""},{"line_number":252,"context_line":"    hw:cpu_pollllicy\u003ddedicated"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"This involves maintaining a registry of valid extra specs. Not all extra specs"},{"line_number":255,"context_line":"can be known ahead of time and for dynamic extra specs, such as those proposed"},{"line_number":256,"context_line":"in `Support filtering by forbidden aggregate membership"},{"line_number":257,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/approved/negative-aggregate-membership.html\u003e`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_d4e53aa4","line":254,"in_reply_to":"3fa7e38b_094266ac","updated":"2020-01-27 15:23:56.000000000","message":"I don\u0027t think we should add another extra call to Cyborg on every API synchronous call for something as used as flavors validation.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c5b591e169eac6676d76ee5fa9efe9d2c12b7496","unresolved":false,"context_lines":[{"line_number":251,"context_line":""},{"line_number":252,"context_line":"    hw:cpu_pollllicy\u003ddedicated"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"This involves maintaining a registry of valid extra specs. Not all extra specs"},{"line_number":255,"context_line":"can be known ahead of time and for dynamic extra specs, such as those proposed"},{"line_number":256,"context_line":"in `Support filtering by forbidden aggregate membership"},{"line_number":257,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/approved/negative-aggregate-membership.html\u003e`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_21754e33","line":254,"in_reply_to":"3fa7e38b_0fc2cd54","updated":"2020-01-29 12:19:19.000000000","message":"right we should not proxy calls to cyborg or other service to do validation. this shoudl be self contained within the nova process. that was why i suggested stevador pugins in the first place so that if we needed to delegate validate to an virt driver or thrid party service we could load the code and execute it in process without needing to call out to another service. if we were to call out to another service we just use the glance metadefs api which already has a json based format for defineing namespaces and validation constratis.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":251,"context_line":""},{"line_number":252,"context_line":"    hw:cpu_pollllicy\u003ddedicated"},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"This involves maintaining a registry of valid extra specs. Not all extra specs"},{"line_number":255,"context_line":"can be known ahead of time and for dynamic extra specs, such as those proposed"},{"line_number":256,"context_line":"in `Support filtering by forbidden aggregate membership"},{"line_number":257,"context_line":"\u003chttp://specs.openstack.org/openstack/nova-specs/specs/stein/approved/negative-aggregate-membership.html\u003e`."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_0fc2cd54","line":254,"in_reply_to":"3fa7e38b_d4e53aa4","updated":"2020-01-28 15:09:12.000000000","message":"Agree with Sylvain, the validation should be 100% \"local\" and fast.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":258,"context_line":"For these, we can rely on a custom namespace validator or YAML specification"},{"line_number":259,"context_line":"provided by the operator. However, completing this registry both in-tree and"},{"line_number":260,"context_line":"out-of-tree is expected to be a complex endeavour and for this reason we won\u0027t"},{"line_number":261,"context_line":"enforce validation of keys as part of this spec."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"Other changes"},{"line_number":264,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_2e84765c","line":261,"updated":"2020-01-28 00:27:44.000000000","message":"Fair to say this is out of scope for this spec, but IMO it\u0027s not hard to do - use a pattern to spec the keys, as hinted above.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"faa8c569ae460dcdc3294627cae39dbb9c59ecd6","unresolved":false,"context_lines":[{"line_number":258,"context_line":"For these, we can rely on a custom namespace validator or YAML specification"},{"line_number":259,"context_line":"provided by the operator. However, completing this registry both in-tree and"},{"line_number":260,"context_line":"out-of-tree is expected to be a complex endeavour and for this reason we won\u0027t"},{"line_number":261,"context_line":"enforce validation of keys as part of this spec."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"Other changes"},{"line_number":264,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_effe5102","line":261,"in_reply_to":"3fa7e38b_2e84765c","updated":"2020-01-28 14:47:41.000000000","message":"Agreed. As noted before though, my hand was forced on this :) Happy to re-add this if enough people think it\u0027s reasonable","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":258,"context_line":"For these, we can rely on a custom namespace validator or YAML specification"},{"line_number":259,"context_line":"provided by the operator. However, completing this registry both in-tree and"},{"line_number":260,"context_line":"out-of-tree is expected to be a complex endeavour and for this reason we won\u0027t"},{"line_number":261,"context_line":"enforce validation of keys as part of this spec."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"Other changes"},{"line_number":264,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_e60f4c29","line":261,"in_reply_to":"3fa7e38b_af0a99cc","updated":"2020-01-29 10:36:11.000000000","message":"I\u0027m swinging massively the other way, having managed to enumerate what appears to be all the extra specs supported by nova in only a couple of hours. I\u0027m going to swing through it again but I don\u0027t think this is the massive ordeal we thought it would be.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d106b4d13c9bef31d1a2caba0e162f4f30a5edb6","unresolved":false,"context_lines":[{"line_number":258,"context_line":"For these, we can rely on a custom namespace validator or YAML specification"},{"line_number":259,"context_line":"provided by the operator. However, completing this registry both in-tree and"},{"line_number":260,"context_line":"out-of-tree is expected to be a complex endeavour and for this reason we won\u0027t"},{"line_number":261,"context_line":"enforce validation of keys as part of this spec."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"Other changes"},{"line_number":264,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_af0a99cc","line":261,"in_reply_to":"3fa7e38b_effe5102","updated":"2020-01-28 15:09:12.000000000","message":"Starting to remember that conversation. I think the critical factor would be whether we can give the user more granular control as discussed above. If it\u0027s truly all-or-nothing, then I agree we need to go easy.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"We also propose adding tooling to (a) render reStructuredText documentation"},{"line_number":267,"context_line":"from the definitions and (b) convert the definitions into Glance metadata"},{"line_number":268,"context_line":"definition files. Both of these tools will live within the nova tree, allowing"},{"line_number":269,"context_line":"us to remain the single source of truth for these things."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"Alternatives"},{"line_number":272,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_4e6692be","line":269,"range":{"start_line":268,"start_character":70,"end_line":269,"end_character":57},"updated":"2020-01-28 00:27:44.000000000","message":"Well, except for the bits provided externally. I suppose the tooling will be available for the admin to run in situ so they can have their customized documentation accurate for their customized environment?","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e438d22a8fe7a92326e07aadf6955f6d5cd6bccc","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"We also propose adding tooling to (a) render reStructuredText documentation"},{"line_number":267,"context_line":"from the definitions and (b) convert the definitions into Glance metadata"},{"line_number":268,"context_line":"definition files. Both of these tools will live within the nova tree, allowing"},{"line_number":269,"context_line":"us to remain the single source of truth for these things."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"Alternatives"},{"line_number":272,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_59adde80","line":269,"range":{"start_line":268,"start_character":70,"end_line":269,"end_character":57},"in_reply_to":"3fa7e38b_263324f9","updated":"2020-01-29 14:57:41.000000000","message":"Yeah, I guess that\u0027s fair. They can look at their YAML file if they get confused.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f008b7031b7e794d5f03060392f065554113aab5","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"We also propose adding tooling to (a) render reStructuredText documentation"},{"line_number":267,"context_line":"from the definitions and (b) convert the definitions into Glance metadata"},{"line_number":268,"context_line":"definition files. Both of these tools will live within the nova tree, allowing"},{"line_number":269,"context_line":"us to remain the single source of truth for these things."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"Alternatives"},{"line_number":272,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_263324f9","line":269,"range":{"start_line":268,"start_character":70,"end_line":269,"end_character":57},"in_reply_to":"3fa7e38b_4e6692be","updated":"2020-01-29 10:36:11.000000000","message":"Less relevant since we\u0027re now killing the stevedore idea. Extra specs defined by way of a YAML file would need to be documented manually though. I could probably provide a way to have the Sphinx extension do it for us but I think it\u0027s overkill and don\u0027t want to do it unless requested by an operator. Configuring flavor extra specs is usually an admin-only operation so the same admins should know about their own custom extra specs already.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":323,"context_line":"Upgrade impact"},{"line_number":324,"context_line":"--------------"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"None."},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_2ee9d617","line":326,"range":{"start_line":326,"start_character":0,"end_line":326,"end_character":4},"updated":"2020-01-28 00:27:44.000000000","message":"This should mention what happens when the control plane is updated before (some of) the computes. In such cases, the computes (where many extra specs are ultimately processed) will have a different idea of what\u0027s valid than the API. In most cases it\u0027s additive -- the API will allow things that the compute can\u0027t handle -- but in some cases it might go the other way.\n\nIf the developer of $new-thing is doing their job right, there ought to be a request filter or similar that prevents a new flavor from landing on an old compute.\n\nBut there are more complex cases to be considered. Like if we add extra/stricter validation to a key that already existed, we can\u0027t enforce that check until we\u0027re sure all the computes have been upgraded.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f3faf503e3aa5d5a2abc20898b6ac266d1cc8b83","unresolved":false,"context_lines":[{"line_number":323,"context_line":"Upgrade impact"},{"line_number":324,"context_line":"--------------"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"None."},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_9ffb5246","line":326,"range":{"start_line":326,"start_character":0,"end_line":326,"end_character":4},"in_reply_to":"3fa7e38b_2ee9d617","updated":"2020-01-28 09:05:48.000000000","message":"When we implement such stricter validation for an existing key wouldn\u0027t that be in a new microversion? If yes then the old microversion still can be used to use the old spec with old computes.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f1fbfe8ca85c2c6b23ba0ca71d38f5dc07656616","unresolved":false,"context_lines":[{"line_number":323,"context_line":"Upgrade impact"},{"line_number":324,"context_line":"--------------"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"None."},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_cfe5953f","line":326,"range":{"start_line":326,"start_character":0,"end_line":326,"end_character":4},"in_reply_to":"3fa7e38b_9ffb5246","updated":"2020-01-28 14:54:48.000000000","message":"Whoah, I hadn\u0027t picked up on the idea that we would spin a new microversion every time we added validation. That doesn\u0027t seem like a sustainable model to me. Stephen, is that what you had in mind? Seems like another thing that should be discussed in the spec.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"155d93f19004e722333850ee8ac41d8ed9b7d844","unresolved":false,"context_lines":[{"line_number":323,"context_line":"Upgrade impact"},{"line_number":324,"context_line":"--------------"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"None."},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_4f70c573","line":326,"range":{"start_line":326,"start_character":0,"end_line":326,"end_character":4},"in_reply_to":"3fa7e38b_cfe5953f","updated":"2020-01-28 15:00:59.000000000","message":"Nope, I definitely don\u0027t want to do that.","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"437597a0732c55498b18c7f029baad80cafd0ee1","unresolved":false,"context_lines":[{"line_number":371,"context_line":"Documentation Impact"},{"line_number":372,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"There will be better docs, through the power of Sphinx."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_8ee32a06","line":374,"updated":"2020-01-28 00:27:44.000000000","message":"And we need to document how to compose and where to lay down the yaml file(s).\n\nAnd, meta, we\u0027ll need to document how to generate the docs (see comment @L268).","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fdad7aa0455c631b3d2bec0730016a810f1d3080","unresolved":false,"context_lines":[{"line_number":371,"context_line":"Documentation Impact"},{"line_number":372,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"There will be better docs, through the power of Sphinx."},{"line_number":375,"context_line":""},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa7e38b_2619e421","line":374,"in_reply_to":"3fa7e38b_8ee32a06","updated":"2020-01-29 11:40:03.000000000","message":"Done","commit_id":"45e145a1da9e2ae445041d1018dd5d03c144b797"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1f3082395c15e547732a3ac1969773cc9b815279","unresolved":false,"context_lines":[{"line_number":135,"context_line":"            },"},{"line_number":136,"context_line":"        ],"},{"line_number":137,"context_line":"        value\u003d{"},{"line_number":138,"context_line":"            \u0027type\u0027: str,"},{"line_number":139,"context_line":"            \u0027description\u0027: ("},{"line_number":140,"context_line":"                \u0027The guest CPUs, in the form of a CPU map, to allocate to the \u0027"},{"line_number":141,"context_line":"                \u0027guest NUMA node identified by ``{id}``.\u0027"},{"line_number":142,"context_line":"            ),"},{"line_number":143,"context_line":"            \u0027pattern\u0027: r\u0027\\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*\u0027,"},{"line_number":144,"context_line":"        },"},{"line_number":145,"context_line":"    )"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"In addition to the extra specs defined in-tree, it is also possible for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_41f88a7c","line":144,"range":{"start_line":138,"start_character":10,"end_line":144,"end_character":10},"updated":"2020-01-29 12:32:06.000000000","message":"nope that is not what that option does\n\nhttps://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-numa-topology\n\nfor hw:numa_cpu.{id}\u003dX\n\nX is an integer and is the number of cpus to assign to that numa node. we do not expose a 1:1 mapping in a list for that.\n\ni get that you were trying to ilistrate a case of useing a regex pattern over a sting type but you should use hw:cpu_realtime_mask here instead.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f13282c1c363ca4168159e5206325aa32e377f61","unresolved":false,"context_lines":[{"line_number":135,"context_line":"            },"},{"line_number":136,"context_line":"        ],"},{"line_number":137,"context_line":"        value\u003d{"},{"line_number":138,"context_line":"            \u0027type\u0027: str,"},{"line_number":139,"context_line":"            \u0027description\u0027: ("},{"line_number":140,"context_line":"                \u0027The guest CPUs, in the form of a CPU map, to allocate to the \u0027"},{"line_number":141,"context_line":"                \u0027guest NUMA node identified by ``{id}``.\u0027"},{"line_number":142,"context_line":"            ),"},{"line_number":143,"context_line":"            \u0027pattern\u0027: r\u0027\\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*\u0027,"},{"line_number":144,"context_line":"        },"},{"line_number":145,"context_line":"    )"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"In addition to the extra specs defined in-tree, it is also possible for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_7edc3816","line":144,"range":{"start_line":138,"start_character":10,"end_line":144,"end_character":10},"in_reply_to":"3fa7e38b_3207d7ca","updated":"2020-01-29 21:36:08.000000000","message":"huh you are right https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html\n\ni was pretty sure that should also be an int\ni guess its more flexible then i taught.\nwith that in mind i am more conviced the mixed cpu case should be a mask.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"430d4059560b7aeb94e503db2caf54887d6f9826","unresolved":false,"context_lines":[{"line_number":135,"context_line":"            },"},{"line_number":136,"context_line":"        ],"},{"line_number":137,"context_line":"        value\u003d{"},{"line_number":138,"context_line":"            \u0027type\u0027: str,"},{"line_number":139,"context_line":"            \u0027description\u0027: ("},{"line_number":140,"context_line":"                \u0027The guest CPUs, in the form of a CPU map, to allocate to the \u0027"},{"line_number":141,"context_line":"                \u0027guest NUMA node identified by ``{id}``.\u0027"},{"line_number":142,"context_line":"            ),"},{"line_number":143,"context_line":"            \u0027pattern\u0027: r\u0027\\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*\u0027,"},{"line_number":144,"context_line":"        },"},{"line_number":145,"context_line":"    )"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"In addition to the extra specs defined in-tree, it is also possible for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_3207d7ca","line":144,"range":{"start_line":138,"start_character":10,"end_line":144,"end_character":10},"in_reply_to":"3fa7e38b_41f88a7c","updated":"2020-01-29 17:01:59.000000000","message":"You say that, but the code suggests otherwise [1]. The docs you linked sort of suggest the same thing too, though they\u0027re not complete (they say it has to be a list but it doesn\u0027t, per the code)\n\n[1] https://github.com/openstack/nova/blob/20.0.0/nova/virt/hardware.py#L1395-L1422","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1f3082395c15e547732a3ac1969773cc9b815279","unresolved":false,"context_lines":[{"line_number":183,"context_line":"      value:"},{"line_number":184,"context_line":"        type: string"},{"line_number":185,"context_line":"        description: \u003e"},{"line_number":186,"context_line":"          The guest CPUs, in the form of a CPU map, to allocate to the guest"},{"line_number":187,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":188,"context_line":"        pattern: \\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_a12a9ee2","line":188,"range":{"start_line":186,"start_character":7,"end_line":188,"end_character":50},"updated":"2020-01-29 12:32:06.000000000","message":"again this is wrong.\n\nits not really germain to the spec you just chose this as an example but it not correct","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"430d4059560b7aeb94e503db2caf54887d6f9826","unresolved":false,"context_lines":[{"line_number":183,"context_line":"      value:"},{"line_number":184,"context_line":"        type: string"},{"line_number":185,"context_line":"        description: \u003e"},{"line_number":186,"context_line":"          The guest CPUs, in the form of a CPU map, to allocate to the guest"},{"line_number":187,"context_line":"          NUMA node identified by ``{id}``."},{"line_number":188,"context_line":"        pattern: \\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_520a93cf","line":188,"range":{"start_line":186,"start_character":7,"end_line":188,"end_character":50},"in_reply_to":"3fa7e38b_a12a9ee2","updated":"2020-01-29 17:01:59.000000000","message":"Per above, I think this is correct","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d3b16cf3cefafb1cea35d01682fa2330c1cc699a","unresolved":false,"context_lines":[{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":192,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":193,"context_line":"setting the wrong values."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Key validation"},{"line_number":196,"context_line":"--------------"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_477c1a21","line":194,"updated":"2020-01-29 14:17:24.000000000","message":"I like the yaml syntax better than the python DSL you proposed above and in the WIP patch. Can we simply implement the in tree validators in yaml as well? We have to have the yaml interpreter anyhow so we would actually spare some complexity if we have one solution for the problem instead of two.\n\nSee some details in [1] too.\n\n[1]https://review.opendev.org/#/c/704643/2/nova/api/validation/extra_specs/hw.py@44","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"82abda2177113bfcc507c597b357e1e3d6df94b4","unresolved":false,"context_lines":[{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":192,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":193,"context_line":"setting the wrong values."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Key validation"},{"line_number":196,"context_line":"--------------"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_99d11659","line":194,"in_reply_to":"3fa7e38b_477c1a21","updated":"2020-01-29 14:44:12.000000000","message":"Discussed this earlier [1]. As I said there, I\u0027m concerned that by defining these all in YAML, we\u0027ll encourage people to go modify that YAML and will have to deal with that when updating things. It seems far less likely that people will hack on the code. In addition, we define all our other schema\u0027y stuff in Python (config options, API schemas, CLI arguments) so this is consistent at least.\n\n[1] https://review.opendev.org/#/c/682655/1/specs/ussuri/approved/flavor-extra-spec-validators.rst@204","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5a096ec30ce81d47111f12ec32962ec8d4e24312","unresolved":false,"context_lines":[{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":192,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":193,"context_line":"setting the wrong values."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Key validation"},{"line_number":196,"context_line":"--------------"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_3c9d70b9","line":194,"in_reply_to":"3fa7e38b_99d11659","updated":"2020-01-29 15:20:00.000000000","message":"16:16  * gibi drops the case for yaml only, but still would like to see an implementation \n          that does not duplicated code for intree and out of tree extra spec validation\n[snip]\n16:17 \u003c efried\u003e gibi: it won\u0027t be a lot of duplication, really. The parser will construct \n                the same kind of python objects we have in tree and then feed all of them \n                into the validation engine.\n16:18 \u003c stephenfin\u003e gibi: yeah, what efried said\n16:18 \u003c gibi\u003e OK, I rest my case then","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e438d22a8fe7a92326e07aadf6955f6d5cd6bccc","unresolved":false,"context_lines":[{"line_number":191,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":192,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":193,"context_line":"setting the wrong values."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Key validation"},{"line_number":196,"context_line":"--------------"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_19752633","line":194,"in_reply_to":"3fa7e38b_99d11659","updated":"2020-01-29 14:57:41.000000000","message":"If we maintained the in-tree YAMLs within the nova package, it would discourage/prevent people from mucking with them. The external directory is just for custom.\n\nBut I\u0027m fine either way.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1f3082395c15e547732a3ac1969773cc9b815279","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_41064a76","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"updated":"2020-01-29 12:32:06.000000000","message":"i thnk we need a config option for this too as erric said.\na microverion would be enough if an only if we never extend the flavor create and flavor update apis again.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f2906311a27955580b10f3bf8407a686abcd294e","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_6c3c9d90","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_2ca6a50e","updated":"2020-01-29 13:14:01.000000000","message":"I must be missing something here. If we get all our extra specs documented, why would a user ever want \"permissive\" mode? Surely that\u0027s an anti-pattern? The reason I suggested such a thing in earlier revisions was because I thought enumerating all the extra specs would be a lot of work, but it turns out not to have been (I\u0027ve almost everything done already in my WIP patch). Falling back to an older API microversion is expected to be a temporary workaround to allow operators update their YAML files, not something they\u0027d use long-term.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0a12be26b687aeacbab0fb96a8226280e6b06491","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_e1697622","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_41064a76","updated":"2020-01-29 12:35:25.000000000","message":"actully if we wanted to avoid a conifg option then the new microversion instead of turning on validation uncondtionally could support a new query arg which is \u0026validte\u003dstrict|permissive|off and default to strict when the new microversion is used.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e438d22a8fe7a92326e07aadf6955f6d5cd6bccc","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_994cb675","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_6c3c9d90","updated":"2020-01-29 14:57:41.000000000","message":"IMO it makes the difference between whether we can enable \"strict\" mode right out of the gate or not. A user may want the benefit of validating their flavor for in-tree stuff, but not want to go through the pain of creating a YAML file for other snowflake extra specs from external services that haven\u0027t gotten the message yet, or custom stuff for their environment. If you want to make this microversion do permissive mode and a subsequent microversion that does strict mode, I guess I\u0027m okay with that. But IMO adding a qparam is a simple way to have your cake and eat it.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c8ac45139b984bc513f1bce196b2f07d6426f929","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_be695023","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_6c3c9d90","updated":"2020-01-30 12:54:51.000000000","message":"so honestly i dont really like the yaml file idea in general.\n\n\ntoday extra specs are used with the compute capablites filter and other filters. those filter currently support non namespaced keys and namespaced keys.\n\nuse of the non namespace keys with those filter is something i would condider to be against best pratices its supported today. \ni dont really thin the operator should be forced to update a config file to added custom extra spec just to \nthe non namespaced ones can be anything so unless we update","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"104bbc360f61a53618e53aa60d9509c2ed0a43c0","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_997827c3","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_994cb675","updated":"2020-01-30 12:09:29.000000000","message":"Done","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d404371b00c993ceaa7301f0bd20205c3d058a3c","unresolved":false,"context_lines":[{"line_number":274,"context_line":"Other deployer impact"},{"line_number":275,"context_line":"---------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"Operators will now need to describe any custom flavor extra specs used in their"},{"line_number":278,"context_line":"deployment in the YAML schema file or they will see errors when using the new"},{"line_number":279,"context_line":"API microversion."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Developer impact"},{"line_number":282,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_2ca6a50e","line":279,"range":{"start_line":277,"start_character":0,"end_line":279,"end_character":17},"in_reply_to":"3fa7e38b_e1697622","updated":"2020-01-29 13:05:33.000000000","message":"i actully thing the api parmater is the best way to go as it avoids config driven api behavior and puts the contol direclty into the client hands.\n\nif the use an old clinet with an old microversion then they will get the old behavior.\n\nif they use the new microversion and dont specify the validate parmater then it would be stict by default which is what we want and then could opt out of validation by specifcying \u0026validate\u003dpermissive or \u0026validate\u003doff if they needed to use a flavor feature that is added in a later microverion but dont want validation.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"348de75c454a5a6ab0bb0a7ba1d7ac29fe389fca","unresolved":false,"context_lines":[{"line_number":307,"context_line":"Feature Liaison"},{"line_number":308,"context_line":"---------------"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"None"},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Work Items"},{"line_number":313,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_611d865f","line":310,"updated":"2020-01-29 11:47:25.000000000","message":"you can be your own","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"104bbc360f61a53618e53aa60d9509c2ed0a43c0","unresolved":false,"context_lines":[{"line_number":307,"context_line":"Feature Liaison"},{"line_number":308,"context_line":"---------------"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"None"},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Work Items"},{"line_number":313,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_b975e3cb","line":310,"in_reply_to":"3fa7e38b_52237357","updated":"2020-01-30 12:09:29.000000000","message":"Done","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"430d4059560b7aeb94e503db2caf54887d6f9826","unresolved":false,"context_lines":[{"line_number":307,"context_line":"Feature Liaison"},{"line_number":308,"context_line":"---------------"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"None"},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Work Items"},{"line_number":313,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_52237357","line":310,"in_reply_to":"3fa7e38b_611d865f","updated":"2020-01-29 17:01:59.000000000","message":"I copied this from bauzas\u0027 NUMA spec. Will update.","commit_id":"afb4ad2ae4068c8af0467a93e627c6434b7f767a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":59,"context_line":"  extra spec B be configured first. We will document the dependency but it"},{"line_number":60,"context_line":"  won\u0027t be enforced."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"  .. note:: In most cases this is already handled by virt drivers."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"- Enforcement of virt driver dependencies. Unfortunately, while flavor extra"},{"line_number":65,"context_line":"  specs should be generic, this isn\u0027t always the case. As above, we will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_e48c0f3c","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":66},"updated":"2020-01-30 15:33:12.000000000","message":"...but at the compute and after the initial scheduling pass, which is way down the road from what this spec proposes.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":114,"context_line":"        ),"},{"line_number":115,"context_line":"        value\u003d{"},{"line_number":116,"context_line":"            \u0027type\u0027: int,"},{"line_number":117,"context_line":"            \u0027description\u0027: \u0027The number of virtual NUMA nodes to allocate\u0027,"},{"line_number":118,"context_line":"            \u0027min\u0027: 1,"},{"line_number":119,"context_line":"        },"},{"line_number":120,"context_line":"    )"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_247c6721","line":117,"range":{"start_line":117,"start_character":12,"end_line":117,"end_character":74},"updated":"2020-01-30 15:33:12.000000000","message":"Again bikeshedding impl in spec, but you decided to do away with this duplication of description, right?","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5035aeed1f89f474727c1b5c067e647eb673b2","unresolved":false,"context_lines":[{"line_number":114,"context_line":"        ),"},{"line_number":115,"context_line":"        value\u003d{"},{"line_number":116,"context_line":"            \u0027type\u0027: int,"},{"line_number":117,"context_line":"            \u0027description\u0027: \u0027The number of virtual NUMA nodes to allocate\u0027,"},{"line_number":118,"context_line":"            \u0027min\u0027: 1,"},{"line_number":119,"context_line":"        },"},{"line_number":120,"context_line":"    )"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_5f060c1e","line":117,"range":{"start_line":117,"start_character":12,"end_line":117,"end_character":74},"in_reply_to":"3fa7e38b_247c6721","updated":"2020-01-30 15:38:49.000000000","message":"yeah, we can discuss this during impl","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":140,"context_line":"                \u0027The guest CPUs, in the form of a CPU map, to allocate to the \u0027"},{"line_number":141,"context_line":"                \u0027guest NUMA node identified by ``{id}``.\u0027"},{"line_number":142,"context_line":"            ),"},{"line_number":143,"context_line":"            \u0027pattern\u0027: r\u0027\\^?\\d+((-\\d+)?(,\\^?\\d+(-\\d+)?)?)*\u0027,"},{"line_number":144,"context_line":"        },"},{"line_number":145,"context_line":"    )"},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_e4c88f4f","line":143,"range":{"start_line":143,"start_character":13,"end_line":143,"end_character":20},"updated":"2020-01-30 15:33:12.000000000","message":"This is again something we can probably defer to impl time, but consider supporting a one-arg callable here instead of or in addition to a pattern. E.g. in this case it would probably be more scrutable to split the string on \u0027,\u0027 and then validate the chunks than to try to understand whether this complex regex is really correct for all possibilities. Also gives you the ability to do more complex validation like making sure the ranges don\u0027t overlap, etc etc etc. (In fact, don\u0027t we already have a function that validates CPU maps?)\n\nThis wouldn\u0027t have made quite as much sense when we were going to support YAML, but since we\u0027re no longer doing that...\n\n[Later] I suppose this could be accomplished by subclassing ExtraSpecValidator and overriding the validate() method (whatever you\u0027re calling it). Making it part of the dataclass def would arguably be a cleaner interface for the consumer. Anyway, we can discuss more later.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"50aa753b34f00fd6788ec5d821b4002c5f386388","unresolved":false,"context_lines":[{"line_number":148,"context_line":"operators to define their own extra specs that would be used by e.g. custom"},{"line_number":149,"context_line":"scheduler filters. For these, we propose providing an entry point through which"},{"line_number":150,"context_line":"operators can define their own custom definitions. This entry point should"},{"line_number":151,"context_line":"point to a list of extra spec validators. These will have lower precedence than"},{"line_number":152,"context_line":"in-tree definitions. This is not expected to be a large burden since operators"},{"line_number":153,"context_line":"already need to provide a package for the custom scheduler filters and"},{"line_number":154,"context_line":"documentation will be provided to help users add these."},{"line_number":155,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_0bf93e4e","line":152,"range":{"start_line":151,"start_character":42,"end_line":152,"end_character":20},"updated":"2020-01-30 12:58:20.000000000","message":"How do we define precedence? Is it like if there are two validators with the same \"name\" arg then the in-tree validator will be used and the out of tree validator will be skipped?\n\nWhat if there is an in-tree validator with \"name\u003d\u0027hw:numa_cpu.{id}\u0027,\" and there is an out of tree validator with \u0027name\u003d\u0027hw:numa_cpu.0\u0027,\u0027 or with \"name\u003d\u0027hw:numa_cpu.{node_id}\u0027,\" ?","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cc1b75e62d0b426c5b6f7114a036721ceb7e570b","unresolved":false,"context_lines":[{"line_number":148,"context_line":"operators to define their own extra specs that would be used by e.g. custom"},{"line_number":149,"context_line":"scheduler filters. For these, we propose providing an entry point through which"},{"line_number":150,"context_line":"operators can define their own custom definitions. This entry point should"},{"line_number":151,"context_line":"point to a list of extra spec validators. These will have lower precedence than"},{"line_number":152,"context_line":"in-tree definitions. This is not expected to be a large burden since operators"},{"line_number":153,"context_line":"already need to provide a package for the custom scheduler filters and"},{"line_number":154,"context_line":"documentation will be provided to help users add these."},{"line_number":155,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_ce86d460","line":152,"range":{"start_line":151,"start_character":42,"end_line":152,"end_character":20},"in_reply_to":"3fa7e38b_0b6cde03","updated":"2020-01-30 13:12:20.000000000","message":"I buy your argument. It is similar to my argument that yaml files in the package directory while editable we don\u0027t expect that will be edited by anybody. So while there will be ways to circumvent precedence we don\u0027t expect the deployer to do it.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"9162353041383fe4af6daadf2fefc9bf95592714","unresolved":false,"context_lines":[{"line_number":148,"context_line":"operators to define their own extra specs that would be used by e.g. custom"},{"line_number":149,"context_line":"scheduler filters. For these, we propose providing an entry point through which"},{"line_number":150,"context_line":"operators can define their own custom definitions. This entry point should"},{"line_number":151,"context_line":"point to a list of extra spec validators. These will have lower precedence than"},{"line_number":152,"context_line":"in-tree definitions. This is not expected to be a large burden since operators"},{"line_number":153,"context_line":"already need to provide a package for the custom scheduler filters and"},{"line_number":154,"context_line":"documentation will be provided to help users add these."},{"line_number":155,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_0b6cde03","line":152,"range":{"start_line":151,"start_character":42,"end_line":152,"end_character":20},"in_reply_to":"3fa7e38b_0bf93e4e","updated":"2020-01-30 13:02:58.000000000","message":"We match two different ways. First, we do a plain string lookup that handles extra specs without parameters. Since we don\u0027t allow duplicates names, that will mean this is a non-issue for this case. If that search fails, we iterate through all the registered extra specs looking for a name pattern that matches what we have. Since this is linear, we\u0027ll just sort things so that in-tree validators come first. I don\u0027t think there should be any reason to override in-tree extra specs (it\u0027s not cross-compatible) so I don\u0027t think we need to worry about the case you suggested.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":174,"context_line":"    ]"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":177,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":178,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":179,"context_line":"setting the wrong values."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_e4f16f99","line":177,"range":{"start_line":177,"start_character":42,"end_line":177,"end_character":45},"updated":"2020-01-30 15:33:12.000000000","message":"and create, right?","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5035aeed1f89f474727c1b5c067e647eb673b2","unresolved":false,"context_lines":[{"line_number":174,"context_line":"    ]"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Regardless of the source of the extra spec validator, they will be used by the"},{"line_number":177,"context_line":"API behind the :command:`openstack flavor set` command. A microversion will be"},{"line_number":178,"context_line":"introduced for this API to avoid breaking existing tools that are inadvertently"},{"line_number":179,"context_line":"setting the wrong values."},{"line_number":180,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_ff3338f7","line":177,"range":{"start_line":177,"start_character":42,"end_line":177,"end_character":45},"in_reply_to":"3fa7e38b_e4f16f99","updated":"2020-01-30 15:38:49.000000000","message":"set is called when flavor create, but let\u0027s not rathole on this one, we can fix the spec if needed.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":187,"context_line":"    hw:cpu_pollllicy\u003ddedicated"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"This involves maintaining a registry of **all** valid extra specs. Given that"},{"line_number":190,"context_line":"we\u0027re using a regex to define extra spec names and provide custom extra spec"},{"line_number":191,"context_line":"validators via the entry point, we expect to have enough power to achieve this."},{"line_number":192,"context_line":"However, there may be a scenarios where an operator wishes to disable or bypass"},{"line_number":193,"context_line":"this validation. To this end, we will add a new ``validation`` query parameter"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_a447f7a4","line":190,"range":{"start_line":190,"start_character":6,"end_line":190,"end_character":46},"updated":"2020-01-30 15:33:12.000000000","message":"nit: the sample code above is using strings with {replacement} syntax, not regexes. Again, we can worry about this in the impl, but it\u0027s not clear which you\u0027re actually going to use or how you\u0027re going to map to the other one (e.g. from a regex to something that looks sane in documentation).","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":191,"context_line":"validators via the entry point, we expect to have enough power to achieve this."},{"line_number":192,"context_line":"However, there may be a scenarios where an operator wishes to disable or bypass"},{"line_number":193,"context_line":"this validation. To this end, we will add a new ``validation`` query parameter"},{"line_number":194,"context_line":"to the ``flavors/{flavor_id}/os-extra_specs`` API. This will accept three"},{"line_number":195,"context_line":"possible values:"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"``strict`` (default)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_c4e8f3a8","line":194,"range":{"start_line":194,"start_character":7,"end_line":194,"end_character":49},"updated":"2020-01-30 15:33:12.000000000","message":"for PUT and POST, yah?","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c8ac45139b984bc513f1bce196b2f07d6426f929","unresolved":false,"context_lines":[{"line_number":206,"context_line":"``off``"},{"line_number":207,"context_line":"    Validation is disabled. No logging will occur."},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"All other values will be rejected."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Other changes"},{"line_number":212,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_8b5f6e73","line":209,"range":{"start_line":209,"start_character":0,"end_line":209,"end_character":33},"updated":"2020-01-30 12:54:51.000000000","message":"this is refering to the \"validation\" paramater right.\nif so then yes this makes sense to me as do the definitions above. the only thing that is a littel dissapointing is that osc does not default to the latest microversion so by default operators wont get this fucntionality ...","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"9162353041383fe4af6daadf2fefc9bf95592714","unresolved":false,"context_lines":[{"line_number":206,"context_line":"``off``"},{"line_number":207,"context_line":"    Validation is disabled. No logging will occur."},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"All other values will be rejected."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Other changes"},{"line_number":212,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_eb570228","line":209,"range":{"start_line":209,"start_character":0,"end_line":209,"end_character":33},"in_reply_to":"3fa7e38b_8b5f6e73","updated":"2020-01-30 13:02:58.000000000","message":"Correct.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":226,"context_line":"* We could introduce a configuration option to toggle strict API validation"},{"line_number":227,"context_line":"  instead of or in addition to the API microversion. This introduces a new"},{"line_number":228,"context_line":"  example of config-driven API behavior, which is something we\u0027re trying to"},{"line_number":229,"context_line":"  remove from nova. It is also unnecessary since users can use older API"},{"line_number":230,"context_line":"  microversions if necessary."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* We could initially log warnings for invalid keys and introduce the API change"},{"line_number":233,"context_line":"  in a later release. This is unnecessary because the use of microversions"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_44ce432d","line":230,"range":{"start_line":229,"start_character":43,"end_line":230,"end_character":29},"updated":"2020-01-30 15:33:12.000000000","message":"the qparam covers this now","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":245,"context_line":""},{"line_number":246,"context_line":"* We could use a YAML file to describe out-of-tree extra specs rather than"},{"line_number":247,"context_line":"  custom Python objects. However, this is prone to inadvertent tampering and"},{"line_number":248,"context_line":"  forces people to learn multiple ways of configuring things."},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"Data model impact"},{"line_number":251,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_a4f5b754","line":248,"updated":"2020-01-30 15:33:12.000000000","message":"We also decided it wasn\u0027t powerful enough; there are plenty of cases where writing a comprehensive regex is really hard (and perhaps still insufficient) versus writing some simple python code.","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":255,"context_line":"REST API impact"},{"line_number":256,"context_line":"---------------"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"We will add a REST API microversion to the ``POST"},{"line_number":259,"context_line":"flavors/{flavor_id}/os-extra_specs`` API to return HTTP 400 invalid flavor"},{"line_number":260,"context_line":"extra specs. We will also add support for a ``validation`` query parameter to"},{"line_number":261,"context_line":"partially or fully disable this behavior, if necessary."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_e46e4ffe","line":258,"range":{"start_line":258,"start_character":45,"end_line":258,"end_character":49},"updated":"2020-01-30 15:33:12.000000000","message":"an PUT, I think","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7998a28e59cccf0b4146c480762c770bbd21e667","unresolved":false,"context_lines":[{"line_number":256,"context_line":"---------------"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"We will add a REST API microversion to the ``POST"},{"line_number":259,"context_line":"flavors/{flavor_id}/os-extra_specs`` API to return HTTP 400 invalid flavor"},{"line_number":260,"context_line":"extra specs. We will also add support for a ``validation`` query parameter to"},{"line_number":261,"context_line":"partially or fully disable this behavior, if necessary."},{"line_number":262,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_a47857c2","line":259,"range":{"start_line":259,"start_character":60,"end_line":259,"end_character":67},"updated":"2020-01-30 15:33:12.000000000","message":"on invalid","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5035aeed1f89f474727c1b5c067e647eb673b2","unresolved":false,"context_lines":[{"line_number":322,"context_line":"Work Items"},{"line_number":323,"context_line":"----------"},{"line_number":324,"context_line":""},{"line_number":325,"context_line":"1. Produce extra spec definitions for all in-tree flavor extra specs."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Add entry point-based loading mechanism for custom extra specs and document"},{"line_number":328,"context_line":"   how operators can and should use this."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_bf42a03b","line":325,"updated":"2020-01-30 15:38:49.000000000","message":"good luck with that tho :-)","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ca5035aeed1f89f474727c1b5c067e647eb673b2","unresolved":false,"context_lines":[{"line_number":325,"context_line":"1. Produce extra spec definitions for all in-tree flavor extra specs."},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Add entry point-based loading mechanism for custom extra specs and document"},{"line_number":328,"context_line":"   how operators can and should use this."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"3. Add a new API microversion and code to validate user-provided flavor extra"},{"line_number":331,"context_line":"   specs and these definitions."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa7e38b_bf5b8021","line":328,"updated":"2020-01-30 15:38:49.000000000","message":"++","commit_id":"90f006e96c2c42d10e1ce8b78d514ec9f15b670b"}]}