)]}'
{"specs/train/neutron-api-versioning.rst":[{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"API versioning again again again..."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"This spec proposes to introduce a versioning to the neutron API."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":".. note::"},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_147dc7b0","line":7,"updated":"2019-05-04 14:19:41.000000000","message":"Better wording: \"This spec proposes a new versioning scheme for the neutron API\"","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"API versioning again again again..."},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"This spec proposes to introduce a versioning to the neutron API."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":".. note::"},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_ee463b22","line":7,"range":{"start_line":7,"start_character":52,"end_line":7,"end_character":59},"updated":"2019-05-16 20:10:03.000000000","message":"nit: Neutron (and it applies to all other occurrences in this document)","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Promblem Description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"The only current way to make some featuree discoverable through API is"},{"line_number":17,"context_line":"\"extension\". However, there is no convenient way to make small changes in existing"},{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_d4508f35","line":16,"range":{"start_line":16,"start_character":34,"end_line":16,"end_character":42},"updated":"2019-05-04 14:19:41.000000000","message":"nit: feature","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"The only current way to make some featuree discoverable through API is"},{"line_number":17,"context_line":"\"extension\". However, there is no convenient way to make small changes in existing"},{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"},{"line_number":20,"context_line":"(e.g., ``tag``, ``tag-ext``, ``tagging``)"},{"line_number":21,"context_line":"or continue to use an incorrect attribute name (e.g., ``max_burst_kbps`` in QoS extension."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_74452370","line":18,"range":{"start_line":18,"start_character":37,"end_line":18,"end_character":48},"updated":"2019-05-04 14:19:41.000000000","message":"decremental - as in removing things one at a time?  Or did you mean incremental?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":16,"context_line":"The only current way to make some featuree discoverable through API is"},{"line_number":17,"context_line":"\"extension\". However, there is no convenient way to make small changes in existing"},{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"},{"line_number":20,"context_line":"(e.g., ``tag``, ``tag-ext``, ``tagging``)"},{"line_number":21,"context_line":"or continue to use an incorrect attribute name (e.g., ``max_burst_kbps`` in QoS extension."},{"line_number":22,"context_line":"it should be ``max_burst_kbits``)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_ce96d795","line":19,"range":{"start_line":19,"start_character":26,"end_line":19,"end_character":37},"updated":"2019-05-16 20:10:03.000000000","message":"extensions","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":16,"context_line":"The only current way to make some featuree discoverable through API is"},{"line_number":17,"context_line":"\"extension\". However, there is no convenient way to make small changes in existing"},{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"},{"line_number":20,"context_line":"(e.g., ``tag``, ``tag-ext``, ``tagging``)"},{"line_number":21,"context_line":"or continue to use an incorrect attribute name (e.g., ``max_burst_kbps`` in QoS extension."},{"line_number":22,"context_line":"it should be ``max_burst_kbits``)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_8e90df97","line":19,"range":{"start_line":19,"start_character":56,"end_line":19,"end_character":67},"updated":"2019-05-16 20:10:03.000000000","message":"same here","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"},{"line_number":20,"context_line":"(e.g., ``tag``, ``tag-ext``, ``tagging``)"},{"line_number":21,"context_line":"or continue to use an incorrect attribute name (e.g., ``max_burst_kbps`` in QoS extension."},{"line_number":22,"context_line":"it should be ``max_burst_kbits``)."},{"line_number":23,"context_line":"Some versioning mechanism is preferred."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_d85566fb","line":21,"range":{"start_line":21,"start_character":3,"end_line":21,"end_character":31},"updated":"2019-05-16 14:15:24.000000000","message":"It seems to me we have two problems:\n\n1) the current way of providing api discoveribility is cumbersome for small changes (i.e. shim extensions)\n\n2) we do not have an established way of making backwards incompatible changes\n\nI guess we are addressing both here. It may make sense to state them separately.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":18,"context_line":"extensions.  There is no way to make decremental changes efficiently."},{"line_number":19,"context_line":"As a result, we have shim exntensions or some family of exntensions"},{"line_number":20,"context_line":"(e.g., ``tag``, ``tag-ext``, ``tagging``)"},{"line_number":21,"context_line":"or continue to use an incorrect attribute name (e.g., ``max_burst_kbps`` in QoS extension."},{"line_number":22,"context_line":"it should be ``max_burst_kbits``)."},{"line_number":23,"context_line":"Some versioning mechanism is preferred."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_2ef773f8","line":21,"range":{"start_line":21,"start_character":89,"end_line":21,"end_character":90},"updated":"2019-05-16 20:10:03.000000000","message":"nitty nit: this dot is not needed probably","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":29,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_545c9f4a","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":2},"updated":"2019-05-04 14:19:41.000000000","message":"By \"it\" I think you mean \"this proposal\"; it would probably be clearer to say so.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":29,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_98dfee67","line":32,"range":{"start_line":32,"start_character":0,"end_line":32,"end_character":56},"updated":"2019-05-16 14:15:24.000000000","message":"Since we\u0027re about to change the version discovery mechanism itself we need to make that difference discoverable. How do we do that? Do we introduce API major version 3.0?\n\nI see this is discussed below. Will continue there.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"},{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_f4583357","line":34,"range":{"start_line":34,"start_character":19,"end_line":34,"end_character":22},"updated":"2019-05-04 14:19:41.000000000","message":"*API (capitalize the \"i\")","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"},{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_18ec5e28","line":34,"range":{"start_line":34,"start_character":4,"end_line":34,"end_character":69},"updated":"2019-05-16 14:15:24.000000000","message":"In order to do this we need to introduce an extension for the core part of the API. Random name ideas for it: \u0027neutron\u0027, \u0027core\u0027, \u0027neutron-core\u0027","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"},{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Handling of experimental features is an open issue."},{"line_number":39,"context_line":"They aree experimental and tend to be changed frequently (even with backward"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_7413e367","line":36,"range":{"start_line":34,"start_character":69,"end_line":36,"end_character":16},"updated":"2019-05-04 14:19:41.000000000","message":"Is the core Neutron API considered just another extension, and so the umbrella Neutron API version would be calculated based on revisions in core + all extensions?  Or would the neutron API be the sum of the versions of all extensions plus a manual bump for core api changes?\n\nAnother consideration: What if I am a customer that doesn\u0027t use DVR but we bump the version of the DVR extension, which bumps the version of the Neutron API in general.  I then have a version bump that signifies nothing for me.  Or is the version autocalculated locally to each cloud?\n\nLast question: if we have discoverable versions for all extensions as well as of the core API functionality, then does an umbrella API version really get us anything?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"},{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Handling of experimental features is an open issue."},{"line_number":39,"context_line":"They aree experimental and tend to be changed frequently (even with backward"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_4e3667b7","line":36,"range":{"start_line":34,"start_character":69,"end_line":36,"end_character":16},"in_reply_to":"dfbec78f_28be5165","updated":"2019-05-16 20:10:03.000000000","message":"I agree with Ryan here. We should avoid providing \"umbrella API version\" which would be calculated somehow (how exactly?). We should IMO simply limit number of extensions for max one extension per service plugin and each of those extensions should have own version.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4a5cd2b87b61b6cfb51d09adcff98e6895669074","unresolved":false,"context_lines":[{"line_number":31,"context_line":"The neutron API is a collection of API extensions in general."},{"line_number":32,"context_line":"It will introduce versioning into individual extensions."},{"line_number":33,"context_line":"All extensions without explicit version is assumed as 1.0"},{"line_number":34,"context_line":"and define Neutron APi version as a collection of extension versions."},{"line_number":35,"context_line":"The neutron API version will be calculated automatically or"},{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Handling of experimental features is an open issue."},{"line_number":39,"context_line":"They aree experimental and tend to be changed frequently (even with backward"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_28be5165","line":36,"range":{"start_line":34,"start_character":69,"end_line":36,"end_character":16},"in_reply_to":"dfbec78f_7413e367","updated":"2019-05-06 22:56:52.000000000","message":"Perhaps, but in practice I don\u0027t think we\u0027ve changed the neutron core API since Juno (perhaps earlier than that). Because of this extension craze, what you really have is a static neutron core API, with API extensions that need versioning. The way I see the world is with a core neutron plugin API that just sits at version 2 and an ecosystem of versioned extensions, each of which has a simple version that is incremented with every change to the extension.\n\nI don\u0027t see the use for an umbrella API version, it\u0027s too complex. In my mind this doesn\u0027t mean we stop adding extensions, I just see us simply see us using simple versioning to provide discoverability of iterations on a given extension rather than creating an extension descriptor for every iteration on an existing extensions.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":36,"context_line":"manually bumped."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Handling of experimental features is an open issue."},{"line_number":39,"context_line":"They aree experimental and tend to be changed frequently (even with backward"},{"line_number":40,"context_line":"incompatible changes). They should not affect Neutron API version."},{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_9418d781","line":39,"range":{"start_line":39,"start_character":5,"end_line":39,"end_character":9},"updated":"2019-05-04 14:19:41.000000000","message":"*are","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Handling of experimental features is an open issue."},{"line_number":39,"context_line":"They aree experimental and tend to be changed frequently (even with backward"},{"line_number":40,"context_line":"incompatible changes). They should not affect Neutron API version."},{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."},{"line_number":43,"context_line":"version \u0027\u003c1.0\u0027 in such extension might work?"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_ce72577d","line":40,"range":{"start_line":40,"start_character":23,"end_line":40,"end_character":65},"updated":"2019-05-16 20:10:03.000000000","message":"as mentioned above, IMHO we shouldn\u0027t have one \"main\" API version which would depend on any extensions.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":40,"context_line":"incompatible changes). They should not affect Neutron API version."},{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."},{"line_number":43,"context_line":"version \u0027\u003c1.0\u0027 in such extension might work?"},{"line_number":44,"context_line":"Out-of-tree extensions are considered as \"experimental\" and"},{"line_number":45,"context_line":"they do not affect the neutron API version."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_340d6b3e","line":43,"range":{"start_line":43,"start_character":0,"end_line":43,"end_character":44},"updated":"2019-05-04 14:19:41.000000000","message":"That aligns with traditional SemVer nicely","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":40,"context_line":"incompatible changes). They should not affect Neutron API version."},{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."},{"line_number":43,"context_line":"version \u0027\u003c1.0\u0027 in such extension might work?"},{"line_number":44,"context_line":"Out-of-tree extensions are considered as \"experimental\" and"},{"line_number":45,"context_line":"they do not affect the neutron API version."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_d826c668","line":43,"range":{"start_line":43,"start_character":0,"end_line":43,"end_character":44},"in_reply_to":"dfbec78f_340d6b3e","updated":"2019-05-16 14:15:24.000000000","message":"Using versions lesser than 1.0 sounds really good for experiments made from scratch. It won\u0027t really work though is someone wants to experiment with the further development of an extension already at version greater than 1.0 (e.g. 2.3).\n\nIn this scheme that is going to need a new extension like this:\n\nfoo 2.3\nfoo-experimental 0.9\n\nWhere foo-experimental semantically overrides foo. This is not necessarily bad, I just want to call the attention to it.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":40,"context_line":"incompatible changes). They should not affect Neutron API version."},{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."},{"line_number":43,"context_line":"version \u0027\u003c1.0\u0027 in such extension might work?"},{"line_number":44,"context_line":"Out-of-tree extensions are considered as \"experimental\" and"},{"line_number":45,"context_line":"they do not affect the neutron API version."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_aefe03ac","line":43,"range":{"start_line":43,"start_character":0,"end_line":43,"end_character":44},"in_reply_to":"dfbec78f_d826c668","updated":"2019-05-16 20:10:03.000000000","message":"I\u0027m not sure if we should allow to merge something like that. If \"foo-experimental\" is going to change API provided by \"foo\" already, that means that \"foo\" should be changed instead of adding new extension :)","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":41,"context_line":"Some feature is experimental and the interface may be changed."},{"line_number":42,"context_line":"Some experimental mode would be nice."},{"line_number":43,"context_line":"version \u0027\u003c1.0\u0027 in such extension might work?"},{"line_number":44,"context_line":"Out-of-tree extensions are considered as \"experimental\" and"},{"line_number":45,"context_line":"they do not affect the neutron API version."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Extensions and API versions"},{"line_number":48,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_98ce0e61","line":45,"range":{"start_line":44,"start_character":0,"end_line":45,"end_character":43},"updated":"2019-05-16 14:15:24.000000000","message":"Why? What do we gain by treating out-of-tree extensions special?\n\nUnless we have some clear gain I\u0027d argue to treat them just like in-tree extensions.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":47,"context_line":"Extensions and API versions"},{"line_number":48,"context_line":"---------------------------"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Neutron API version defines a whole set of APIs"},{"line_number":51,"context_line":"(regardless of some extension is enabled or not)."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"\"extension list\" will be a kind of capability list."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_cf03160d","line":50,"range":{"start_line":50,"start_character":30,"end_line":50,"end_character":35},"updated":"2019-05-04 14:19:41.000000000","message":"nit: The word \u0027whole\u0027 is unnecessary here.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":48,"context_line":"---------------------------"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Neutron API version defines a whole set of APIs"},{"line_number":51,"context_line":"(regardless of some extension is enabled or not)."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"\"extension list\" will be a kind of capability list."},{"line_number":54,"context_line":"It shows what features are enabled to API consumers."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_6f08ea27","line":51,"range":{"start_line":51,"start_character":1,"end_line":51,"end_character":14},"updated":"2019-05-04 14:19:41.000000000","message":"regardless of whether","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":48,"context_line":"---------------------------"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Neutron API version defines a whole set of APIs"},{"line_number":51,"context_line":"(regardless of some extension is enabled or not)."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"\"extension list\" will be a kind of capability list."},{"line_number":54,"context_line":"It shows what features are enabled to API consumers."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_2ee1b3ff","line":51,"range":{"start_line":51,"start_character":1,"end_line":51,"end_character":47},"updated":"2019-05-16 20:10:03.000000000","message":"what is exactly goal of such version? will it tell anything to users?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"\"extension list\" will be a kind of capability list."},{"line_number":54,"context_line":"It shows what features are enabled to API consumers."},{"line_number":55,"context_line":"The extension framework will be kept as-is."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"API layer implementation"},{"line_number":58,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_2eba13de","line":55,"range":{"start_line":55,"start_character":0,"end_line":55,"end_character":43},"updated":"2019-05-16 20:10:03.000000000","message":"technically speaking we will have to add \"version\" attribute to extension resource. So we will need new extension for that ;D","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":58,"context_line":"------------------------"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We need to maintain attribute maps per version"},{"line_number":61,"context_line":"and generate attribute maps corersponding to a requested version"},{"line_number":62,"context_line":"(if we introduce the microversion mechanism)."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"API definitions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_2f12f259","line":61,"range":{"start_line":61,"start_character":28,"end_line":61,"end_character":41},"updated":"2019-05-04 14:19:41.000000000","message":"*corresponding","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We need to maintain attribute maps per version"},{"line_number":61,"context_line":"and generate attribute maps corersponding to a requested version"},{"line_number":62,"context_line":"(if we introduce the microversion mechanism)."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"API definitions"},{"line_number":65,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_ef1b7a70","line":62,"range":{"start_line":62,"start_character":1,"end_line":62,"end_character":43},"updated":"2019-05-04 14:19:41.000000000","message":"Noting for the record: In the PTG discussion we killed the microversion concept.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"We need to maintain attribute maps per version"},{"line_number":61,"context_line":"and generate attribute maps corersponding to a requested version"},{"line_number":62,"context_line":"(if we introduce the microversion mechanism)."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"API definitions"},{"line_number":65,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_982a8ed8","line":62,"range":{"start_line":62,"start_character":1,"end_line":62,"end_character":43},"in_reply_to":"dfbec78f_ef1b7a70","updated":"2019-05-16 14:15:24.000000000","message":"Extending the record: Microversions enable a client to choose between multiple API syntaxes and behaviors whose implementations must concurrently live in the server-side code base. That is the complexity we want to avoid.\n\nInstead we preferred a versioning that describes what to expect from the API, but does *not* provide choices of multiple API syntax and behavior. That is also in-line with the current extension behavior where you cannot select which extensions you want as a client.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":70,"context_line":"We currently have the API definitions in neutron-lib repository,"},{"line_number":71,"context_line":"but it does not define the API behavior."},{"line_number":72,"context_line":"Individual stadium projects implements individual API extensions."},{"line_number":73,"context_line":"This raises a question where we should maintain the API version as a whole."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The API layer resolves neutron API version number into corresponding"},{"line_number":76,"context_line":"extension version numbers. Validation of API request and validation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_6f21ca9f","line":73,"range":{"start_line":73,"start_character":0,"end_line":73,"end_character":75},"updated":"2019-05-04 14:19:41.000000000","message":"I think we need to examine what value an \"API version as a whole\" gives us when you can get a list like:\n\nextension      version\n-----------    -------\nneutron-core    2.11\nqos             1.5\ntag             1.0\nnetworking-ovn  3.6\netc.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":70,"context_line":"We currently have the API definitions in neutron-lib repository,"},{"line_number":71,"context_line":"but it does not define the API behavior."},{"line_number":72,"context_line":"Individual stadium projects implements individual API extensions."},{"line_number":73,"context_line":"This raises a question where we should maintain the API version as a whole."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The API layer resolves neutron API version number into corresponding"},{"line_number":76,"context_line":"extension version numbers. Validation of API request and validation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_d8e8067d","line":73,"range":{"start_line":73,"start_character":0,"end_line":73,"end_character":75},"in_reply_to":"dfbec78f_6f21ca9f","updated":"2019-05-16 14:15:24.000000000","message":"I don\u0027t see a reason to provide an aggregate API version other than the whole extension map itself. Actually it would make the life of out-of-tree plugin maintainers quite hard (assuming they can have non-experimental extensions).","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":70,"context_line":"We currently have the API definitions in neutron-lib repository,"},{"line_number":71,"context_line":"but it does not define the API behavior."},{"line_number":72,"context_line":"Individual stadium projects implements individual API extensions."},{"line_number":73,"context_line":"This raises a question where we should maintain the API version as a whole."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The API layer resolves neutron API version number into corresponding"},{"line_number":76,"context_line":"extension version numbers. Validation of API request and validation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_ee907b51","line":73,"range":{"start_line":73,"start_character":0,"end_line":73,"end_character":75},"in_reply_to":"dfbec78f_d8e8067d","updated":"2019-05-16 20:10:03.000000000","message":"I agree here, IMO there is no need to provide such \"main API version\"","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":72,"context_line":"Individual stadium projects implements individual API extensions."},{"line_number":73,"context_line":"This raises a question where we should maintain the API version as a whole."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The API layer resolves neutron API version number into corresponding"},{"line_number":76,"context_line":"extension version numbers. Validation of API request and validation"},{"line_number":77,"context_line":"of responses from plugins will be done based on attribute maps"},{"line_number":78,"context_line":"of the requested API version."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Plugin interface"},{"line_number":81,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_4e898724","line":78,"range":{"start_line":75,"start_character":0,"end_line":78,"end_character":29},"updated":"2019-05-16 20:10:03.000000000","message":"Isn\u0027t this something like micro versioning which is e.g. in nova? I think that we agreed in Denver that we shouldn\u0027t do it this way.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4a5cd2b87b61b6cfb51d09adcff98e6895669074","unresolved":false,"context_lines":[{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Each plugin should declare supported extension versions."},{"line_number":84,"context_line":"It would be an enhancement of ``supported_extension_aliases``."},{"line_number":85,"context_line":"If no version is declared, it will be considered as 1.0 (default)"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Plugins should process and return based passed version number"},{"line_number":88,"context_line":"method interfaces would be like nova:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_e8b7d985","line":85,"range":{"start_line":85,"start_character":0,"end_line":85,"end_character":65},"updated":"2019-05-06 22:56:52.000000000","message":"I wonder if each plugin should be forced to explicitly declare versions rather than assuming a default. It\u0027s not that much work to attach a version number. Just a thought.....","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Each plugin should declare supported extension versions."},{"line_number":84,"context_line":"It would be an enhancement of ``supported_extension_aliases``."},{"line_number":85,"context_line":"If no version is declared, it will be considered as 1.0 (default)"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Plugins should process and return based passed version number"},{"line_number":88,"context_line":"method interfaces would be like nova:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_b88672b8","line":85,"range":{"start_line":85,"start_character":0,"end_line":85,"end_character":65},"in_reply_to":"dfbec78f_e8b7d985","updated":"2019-05-16 14:15:24.000000000","message":"+1\n\nOr if we want to have a default, make it a version number that\u0027s experimental (\u003c1.0).","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":88,"context_line":"method interfaces would be like nova:"},{"line_number":89,"context_line":"https://docs.openstack.org/nova/latest/contributor/microversions.html#in-code."},{"line_number":90,"context_line":"Requested version numbers are passed as part of \"Context\" object."},{"line_number":91,"context_line":"It is needed so that a plugin behaves differently based on API versionn"},{"line_number":92,"context_line":"(e.g., exception code change)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If a plugin does not support a requested version, the API layer will"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_8e769f3e","line":91,"range":{"start_line":91,"start_character":63,"end_line":91,"end_character":71},"updated":"2019-05-16 20:10:03.000000000","message":"nit: version","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":84,"context_line":"It would be an enhancement of ``supported_extension_aliases``."},{"line_number":85,"context_line":"If no version is declared, it will be considered as 1.0 (default)"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Plugins should process and return based passed version number"},{"line_number":88,"context_line":"method interfaces would be like nova:"},{"line_number":89,"context_line":"https://docs.openstack.org/nova/latest/contributor/microversions.html#in-code."},{"line_number":90,"context_line":"Requested version numbers are passed as part of \"Context\" object."},{"line_number":91,"context_line":"It is needed so that a plugin behaves differently based on API versionn"},{"line_number":92,"context_line":"(e.g., exception code change)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If a plugin does not support a requested version, the API layer will"},{"line_number":95,"context_line":"return NotImplementedError to API callers."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_cf51d610","line":92,"range":{"start_line":87,"start_character":0,"end_line":92,"end_character":29},"updated":"2019-05-04 14:19:41.000000000","message":"I think this was all superceded when we junked microversion support.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":91,"context_line":"It is needed so that a plugin behaves differently based on API versionn"},{"line_number":92,"context_line":"(e.g., exception code change)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If a plugin does not support a requested version, the API layer will"},{"line_number":95,"context_line":"return NotImplementedError to API callers."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Discussions"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_6f56aa09","line":95,"range":{"start_line":94,"start_character":0,"end_line":95,"end_character":42},"updated":"2019-05-04 14:19:41.000000000","message":"Probably unnecessary, since the versions are now for discovery not validation.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":91,"context_line":"It is needed so that a plugin behaves differently based on API versionn"},{"line_number":92,"context_line":"(e.g., exception code change)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"If a plugin does not support a requested version, the API layer will"},{"line_number":95,"context_line":"return NotImplementedError to API callers."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Discussions"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_cedb5c4c","line":95,"range":{"start_line":94,"start_character":0,"end_line":95,"end_character":42},"in_reply_to":"dfbec78f_6f56aa09","updated":"2019-05-16 14:15:24.000000000","message":"+1 Unless we want to completely and deeply revamp our version discovery (for example via HTTP content negotiation so we\u0027d have versions in each request and response) this is unnecessary.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4a5cd2b87b61b6cfb51d09adcff98e6895669074","unresolved":false,"context_lines":[{"line_number":100,"context_line":"Do we use microversion?"},{"line_number":101,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"Ideally microversion would be better, but I think we can start it from"},{"line_number":104,"context_line":"\"simple versioning\" like keystone does."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Introducing the microversion mechanism would increase the maintenance cost"},{"line_number":107,"context_line":"because we need to continue to provide old behaviors."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_68e449ad","line":104,"range":{"start_line":103,"start_character":0,"end_line":104,"end_character":39},"updated":"2019-05-06 22:56:52.000000000","message":"I agree, start with simple versioning.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":100,"context_line":"Do we use microversion?"},{"line_number":101,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"Ideally microversion would be better, but I think we can start it from"},{"line_number":104,"context_line":"\"simple versioning\" like keystone does."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Introducing the microversion mechanism would increase the maintenance cost"},{"line_number":107,"context_line":"because we need to continue to provide old behaviors."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_4e8e6728","line":104,"range":{"start_line":103,"start_character":0,"end_line":104,"end_character":39},"in_reply_to":"dfbec78f_68e449ad","updated":"2019-05-16 20:10:03.000000000","message":"+1","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"2146da309c3d64159476f6148510ef9c79a0d5fc","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_ef493a60","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"updated":"2019-05-04 14:19:41.000000000","message":"I think we need to contemplate this deeply.  Incrementing the API major version imposes a non-trivial load on anything that has integrated with Neutron.  Look at how long and difficult the battle Keystone had to get version 3 everywhere was.  I don\u0027t think this is a decision to make lightly, and if it is possible to implement this while still remaining within \"Networking API v2.0\" I think we should.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"955f715709eee64976c324b02dc0b5b608fc3b0c","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_e86868bb","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"in_reply_to":"bfb3d3c7_8eabff73","updated":"2019-05-17 09:16:28.000000000","message":"Yes, a \u0027versioned-extensions\u0027 extension would tell well-maintained clients they can use the versioned extensions. But what do we do with legacy (long-time unchanged) clients? We cannot expect them to check that the \u0027versioned-extensions\u0027 extension is *not* present, right? They will keep looking at the unversioned extension list (which we don\u0027t plan to maintain after this spec I think) and assume nothing changed. When in fact we will introduce changes to the API. At some point in the future we will break them - silently.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"8339e3308aa90d23ae14d74a82c204898198ab42","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_5ed1bcfa","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"in_reply_to":"bfb3d3c7_e86868bb","updated":"2019-05-23 21:56:24.000000000","message":"So ironic, LOL! A shim extension that helps is rid ourselves of shim extensions :)\n\nI\u0027m laughing, but also seriously contemplating this. It\u0027s actually not a bad idea.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_8eabff73","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"in_reply_to":"dfbec78f_6ebfd0a9","updated":"2019-05-16 20:10:03.000000000","message":"I know that this is funny but we can add new extension to make new behaviour discoverable ;)","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_6ebfd0a9","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"in_reply_to":"dfbec78f_a8da41e6","updated":"2019-05-16 14:15:24.000000000","message":"We can only avoid going to v3 if we make up a mechanism that allows our clients to discover the change in how extension discovery works. We can easily add something new that returns the versioned extension map. But what do we do with old and not updated clients looking at the old extension list which will not change anymore after this spec while the actual API behavior will change? Can we do that without supporting v2.0 and v3.0 concurrently? If we do that we likely want to freeze v2.0 and start with v3.0 having the same functionality than v2.0 but different extension discovery.\n\nAn alternative to avoid v3 could be to only address the problem of shim extensions. I can imagine a change so after it a new shim extension would need only a new constant entry in a list - so creating shim extensions would be easy. But that will never solve the problem of correcting API mistakes.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4a5cd2b87b61b6cfb51d09adcff98e6895669074","unresolved":false,"context_lines":[{"line_number":114,"context_line":"Does it mean neutron API v3?"},{"line_number":115,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Yes, I think it means neutron API v3."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_a8da41e6","line":117,"range":{"start_line":117,"start_character":0,"end_line":117,"end_character":37},"in_reply_to":"dfbec78f_ef493a60","updated":"2019-05-06 22:56:52.000000000","message":"I agree this needs a lot of thought before we charge ahead with neutron v3. In my opinion, the introduction of a neutron v3 API is where we try to make things like routed networks and other resources more clean re-thinking what they mean and how they relate to each other. In other words, I would not want to move to a version 3 of the API unless we can go back to the drawing board with the neutron resource model. I\u0027m not yet convinced extension versioning forces us to re-think the entire neutron resource model, so I\u0027m not in favor of this if it can be avoided.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Regardless of that we introduce microversion or not (i.e., just versioning),"},{"line_number":120,"context_line":"it means the usage of neutron API will be changed. In neutorn API v2,"},{"line_number":121,"context_line":"API consumers checks neutron extension list to know which features are available."},{"line_number":122,"context_line":"In the new scheme, API consumers checks the API version available."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"If we continue to use v2 API, we would have an extension which means"},{"line_number":125,"context_line":"API versioning is introduced, but it means API consumers need to check"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_aea84377","line":122,"range":{"start_line":122,"start_character":44,"end_line":122,"end_character":65},"updated":"2019-05-16 20:10:03.000000000","message":"shouldn\u0027t be \"API extension\u0027s version\" here?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"ad8dd8e53bca8e2ebf8aeeb06b93045487af19c0","unresolved":false,"context_lines":[{"line_number":122,"context_line":"In the new scheme, API consumers checks the API version available."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"If we continue to use v2 API, we would have an extension which means"},{"line_number":125,"context_line":"API versioning is introduced, but it means API consumers need to check"},{"line_number":126,"context_line":"two things: API version and a list of extensions."},{"line_number":127,"context_line":"It looks better to introduce a new API major instead as other projects do."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_4edc2718","line":126,"range":{"start_line":125,"start_character":30,"end_line":126,"end_character":48},"updated":"2019-05-16 20:10:03.000000000","message":"if we will not have one main API version but versioned extensions (one per service plugin) than to discover some feature client will need to do something like:\n\n    if \"versioned-extensions\" in extensions_list:\n        qos_ingress_direction_availabe \u003d extensions_list[\u0027qos\u0027][\u0027version\u0027] \u003e\u003d x.yy\n    else:\n        qos_ingress_direction_availabe \u003d \"qos_ingress_direction\" in extensions_list\n\nam I right?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"4a5cd2b87b61b6cfb51d09adcff98e6895669074","unresolved":false,"context_lines":[{"line_number":124,"context_line":"If we continue to use v2 API, we would have an extension which means"},{"line_number":125,"context_line":"API versioning is introduced, but it means API consumers need to check"},{"line_number":126,"context_line":"two things: API version and a list of extensions."},{"line_number":127,"context_line":"It looks better to introduce a new API major instead as other projects do."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_c873f5e6","line":127,"range":{"start_line":127,"start_character":0,"end_line":127,"end_character":74},"updated":"2019-05-06 22:56:52.000000000","message":"I don\u0027t agree with this assertion, I don\u0027t think it\u0027s that painful to group and collapse related extensions, then begin versioning them and forcing clients to be aware of the versioning. In the abstract I don\u0027t see this approach as being that  different than what we do today with shim extensions. Instead of adding a shim and making clients aware of it, we would simply increment a simple version and make clients aware of the new version.","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"02a61fa56517fcac99bef2cef685e7a3ff11216c","unresolved":false,"context_lines":[{"line_number":124,"context_line":"If we continue to use v2 API, we would have an extension which means"},{"line_number":125,"context_line":"API versioning is introduced, but it means API consumers need to check"},{"line_number":126,"context_line":"two things: API version and a list of extensions."},{"line_number":127,"context_line":"It looks better to introduce a new API major instead as other projects do."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_0e2e54fa","line":127,"range":{"start_line":127,"start_character":0,"end_line":127,"end_character":74},"in_reply_to":"dfbec78f_c873f5e6","updated":"2019-05-16 14:15:24.000000000","message":"That\u0027s true. I think the harder question is what do you do legacy clients?","commit_id":"4fa5b3a522cb378a2f0d0cdaf0721a7f89166dee"}]}