)]}'
{"ironic/api/controllers/v1/port.py":[{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"b2b8f4389781a018c505214bc6b35328c0dad971","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_ee998cc3","line":553,"updated":"2017-06-06 16:00:34.000000000","message":"Although I haven\u0027t tested this (yet), I am fairly sure this will not work during a rolling upgrade. The scenario where it will break is when the API service is running the new release N+1, but is pinned to N (via config option pin_release_version \u003d N). When pinned to ocata, this API service will NOT be able to send this new RPC request, because when pinned (assuming the code works), it will only send RPC requests up to 1.40; this new one is in 1.41. (/me going to test to verify that the code works as planned...)\nThe way to fix it is to add code around this; we need to support both old behaviour and new behaviour. There\u0027s no API version bump for this, too bad. And looking quickly, we don\u0027t have any utility function that makes it easy to get the RPC version cap (see [1]).\nHaving said all the above... maybe we are OK with port creation failing during the rolling upgrade? What do people think? If we are, then the only thing we might change here is to catch the error (whatever it is) and return some more meaningful msg...\n\n[1] https://github.com/openstack/ironic/blob/d8438df350c044ca2992822a888c20f21f1c2ea1/ironic/conductor/rpcapi.py#L110-L111","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5be31d5a947abb332f51a4da3e333fd66e9e9214","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_ab48efcb","line":553,"in_reply_to":"7f231b9d_2883c5ce","updated":"2017-06-12 14:26:17.000000000","message":"@Sam. yes to what Mark sez. And don\u0027t even go down the path of asking why we can\u0027t add more smarts to know if a conductor is running new and unpinned. If we have some conductors pinned and some unpinned, there could be some \u0027thrashing\u0027 in the DB, cuz if each of these conductors saves the same object (assuming object has two diff versions), the object could be saved in new version by unpinned-conductor, then later saved in old version by pinned-conductor. So we cannot allow new features until after unpinning of all conductors -- which we detect via unpinning of API.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6637,"name":"Sam Betts","email":"sam@code-smash.net","username":"sambetts"},"change_message_id":"b41eeb967e05ad4d88909b52be144cfd7999428e","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_ee127558","line":553,"in_reply_to":"7f231b9d_ab48efcb","updated":"2017-06-12 14:37:58.000000000","message":"Its probably my ignorance regarding the rolling upgrade workflow, but my understanding is that none of API services should be upgraded until all the conductors are upgraded and unpinned, and that API services shouldn\u0027t care if they are talking to a new conductor or an old conductor they just keep working as usual and have no idea the conductors have upgraded under them because they are requesting the older RPC version. Therefore we shouldn\u0027t get RPC errors from the API services about these new RPC APIs because all the conductors have been upgraded and unpinned before any new API services that are going to use them are started.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"184eab70e9d129e470059896c478d804c405685f","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_2883c5ce","line":553,"in_reply_to":"7f231b9d_cb456e72","updated":"2017-06-12 13:58:46.000000000","message":"I\u0027ve added a TODO here.\n\n@sambetts, how will the API servers know that all the conductors have been upgraded and unpinned? Until the API service has been unpinned it has to assume that the conductors are pinned and therefore can\u0027t send them post-upgrade RPCs.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"128a6aaea4372e189e4865326cd9f2a837f105e1","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_eecb9550","line":553,"in_reply_to":"7f231b9d_ee127558","updated":"2017-06-12 14:50:08.000000000","message":"@Sam. Rolling upgrades hasn\u0027t landed yet, but take a look at step 5 in [1]. As long as API is pinned to a lower RPC version, we\u0027ll get RPC errors if try to access higher version. I can discuss with you on irc if you want.\n\n[1]: http://specs.openstack.org/openstack/ironic-specs/specs/approved/support-rolling-upgrade.html#rolling-upgrade-process","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":19593,"name":"Anup Navare","email":"anup.d.navare@intel.com","username":"anup"},"change_message_id":"a8a2a76852e938f5b1dc195af9c023d331d42546","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_d3754bfc","line":553,"in_reply_to":"bf091321_d4663f52","updated":"2017-06-09 23:54:42.000000000","message":"+1 for TODO.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"41a0b5c8843857140a3304cfe4401ad971ac25b0","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_a993695c","line":553,"in_reply_to":"df140735_0dce0183","updated":"2017-06-07 13:50:53.000000000","message":"Having thought about this for a while, I think we can handle this in the RPCAPI. I made a proof of concept[1] of the logic required to determine when validation is required.\n\nOnce in place, the get_target_version() method could be useful to catch users specifying physical_network ASAP but I *think* that it alone does not cover all bases. Consider the following:\n\n* Two ironic API services - one is pinned, the other is not.\n* One existing port.\n* API call 1 sets physical_network and lands on the unpinned API server.\n* API call 2 sets portgroup_uuid and lands on the pinned API server.\n\nWe need to ensure that the second API call is rejected as it cannot validate the portgroup\u0027s ports\u0027 physical network fields. [1] will do this.\n\n[1] https://review.openstack.org/#/c/471779/1","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"557139e69482ae33c3efb1536ea1bfb9c4b4be9a","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_0dce0183","line":553,"in_reply_to":"df140735_62ec6c29","updated":"2017-06-06 18:48:24.000000000","message":"if we really want the validation being done in conductor, maybe we should just bail out instead of allowing the port creations in the API. That won\u0027t prevent older API service from creating a port, but it will do that here. I\u0027ll try to look at your other patches later today to get a better idea...\n\nwrt API microversion -- yes, that is true, no pinning of API microversion. All requests go via the api service, so the code in api service can check for API microversion + pinning. See eg [1] (this is not a real feature, just a POC to show how we\u0027d add a new feature). And i see that what hasn\u0027t landed yet, is IronicObject.get_target_version() -- which is what you\u0027d ideally call here. I wonder if you can call IronicObject._get_target_version() for now. I mean you can call it, but will reviewers allow it...\n\n[1] https://review.openstack.org/#/c/455811/6/ironic/api/controllers/v1/utils.py","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"234c8af32063c3b0575533cf9dc12a4236069b8e","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_997b7bbd","line":553,"in_reply_to":"df140735_7929c7f0","updated":"2017-06-06 17:07:58.000000000","message":"Me again. If we feel that the right thing to do is allow the port create, then the way to fix it is to:\n\n1. check the version cap explicitly, if version cap \u003e\u003d 1.41, call conductor to create port; otherwise fall back to original code to create port from API service.\n2. add a try/except exception.RPCVersionCapError around L552, and fall back to orig behaviour","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"00bdcc79051524fa5bfb8c82788ad0adc4cc3f18","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_62ec6c29","line":553,"in_reply_to":"df140735_997b7bbd","updated":"2017-06-06 18:08:27.000000000","message":"This is a good point Ruby. It would be good to allow port creation during upgrades where possible.\n\nOne corner case I see is when we need to perform validation in the conductor. In the next patch in this series we add validation of the physical network of ports in a portgroup during port create and update operations. If we just create the port in the API server as was done previously we\u0027ll skip that check.\n\nIf there is some way to determine whether a port object needs validation by the conductor, then we could safely create it in the API server in some cases. Perhaps we could use the user\u0027s requested API microversion? Or maybe check for set physical_network and portgroup_id fields. This is starting to feel brittle and sensitive to further changes to the conductor\u0027s create_port method.\n\nLooking through the ironic code, it appears that we only pin the RPC and object versions during an upgrade, not the API microversion - is that correct?","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"d98bb633ebcc585421df85d9e95abe818189760e","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_e83a7296","line":553,"in_reply_to":"df140735_a993695c","updated":"2017-06-07 17:55:03.000000000","message":"wrt the rolling upgrades stuff. I don\u0027t want to hold up this feature cuz of that since rolling upgrades hasn\u0027t all landed yet. I am fine if this goes in without handling it \u0027beautifully\u0027; maybe just add a NOTE or TODO here, saying that during rolling upgrade (whatever i mentioned before)..","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"a3b1658a4f35115715c22c771478ddc9e6b49b39","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"bf091321_d4663f52","line":553,"in_reply_to":"df140735_e83a7296","updated":"2017-06-08 11:02:26.000000000","message":"+1 for TODO here","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6637,"name":"Sam Betts","email":"sam@code-smash.net","username":"sambetts"},"change_message_id":"e13823156aabcca1f9a533ad92099b8fd630690b","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"7f231b9d_cb456e72","line":553,"in_reply_to":"df140735_e83a7296","updated":"2017-06-12 13:29:20.000000000","message":"During rolling upgrades I thought that all conductors were upgraded before the API services. If that is the case then adding a new RPC API shouldn\u0027t cause a problem because all the conductors will already be upgraded and have that API available when the API services which are going to use it come up right??","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"cbb074f253b7ac4a3e3f545acc0ecf37b77057c6","unresolved":false,"context_lines":[{"line_number":550,"context_line":"                                              **notify_extra):"},{"line_number":551,"context_line":"            topic \u003d pecan.request.rpcapi.get_topic_for(rpc_node)"},{"line_number":552,"context_line":"            new_port \u003d pecan.request.rpcapi.create_port(context, rpc_port,"},{"line_number":553,"context_line":"                                                        topic)"},{"line_number":554,"context_line":"        notify.emit_end_notification(context, new_port, \u0027create\u0027,"},{"line_number":555,"context_line":"                                     **notify_extra)"},{"line_number":556,"context_line":"        # Set the HTTP Location Header"}],"source_content_type":"text/x-python","patch_set":3,"id":"df140735_7929c7f0","line":553,"in_reply_to":"df140735_ee998cc3","updated":"2017-06-06 17:01:29.000000000","message":"I just tested this out (ironic-api \u0026 ironic-conductor running this code, with pin_release_version\u003docata). When I tried to create a port I got this error. If we\u0027re good with this error, then the patch is ok, although this might be gibberish to the operator/user that issued the port-create :-):\n\nRequested message version, 1.41 is incompatible.  It needs to be equal in major version and less than or equal in minor version as the specified version cap 1.40. (HTTP 500)","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"}],"releasenotes/notes/create-port-on-conductor-b921738b4b2a5def.yaml":[{"author":{"_account_id":19593,"name":"Anup Navare","email":"anup.d.navare@intel.com","username":"anup"},"change_message_id":"a8a2a76852e938f5b1dc195af9c023d331d42546","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_d391cbf3","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"updated":"2017-06-09 23:54:42.000000000","message":"Including version bump here will be good.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5be31d5a947abb332f51a4da3e333fd66e9e9214","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_ab76af05","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"in_reply_to":"7f231b9d_08836955","updated":"2017-06-12 14:26:17.000000000","message":"You cannot include a version bump here, the code hasn\u0027t landed yet. I suspect this release note will get updated/amalgamated/maybe-reworded? with (I\u0027m assuming there is one) release note associated with the REST API patch.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"11f71a2e72600e597d329ee28bcdd4469a3a42cb","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_851bd719","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"in_reply_to":"7f231b9d_724523b3","updated":"2017-06-12 18:03:09.000000000","message":"We specify the REST API version in release notes, but there\u0027s no REST API version change here. Or did you mean the RPC version change? I don\u0027t think that\u0027s useful since there is no way to specify that version outside of the code. (What would the operator do with that information?)","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":19593,"name":"Anup Navare","email":"anup.d.navare@intel.com","username":"anup"},"change_message_id":"03d48980e5068e425edc51bc91c983dcd79c1560","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_24ad1e31","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"in_reply_to":"7f231b9d_851bd719","updated":"2017-06-12 23:32:08.000000000","message":"yeah i just felt as we include REST API version should the RPC version bump also be included. Thanks for clearing that it is not required. :)","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":19593,"name":"Anup Navare","email":"anup.d.navare@intel.com","username":"anup"},"change_message_id":"c059bee20b6319e4e7963f2ec7708107b7d0ad61","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_724523b3","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"in_reply_to":"7f231b9d_ab76af05","updated":"2017-06-12 17:47:12.000000000","message":"I see, I thought we specify the version change in the release note to tell users from when the feature is supported.","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"184eab70e9d129e470059896c478d804c405685f","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_08836955","line":2,"range":{"start_line":2,"start_character":0,"end_line":2,"end_character":7},"in_reply_to":"7f231b9d_d391cbf3","updated":"2017-06-12 13:58:46.000000000","message":"This is covered by an RPC API version bump. Do we advertise that to users?","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"d98bb633ebcc585421df85d9e95abe818189760e","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"},{"line_number":6,"context_line":"    this change, port creation may take longer, and this may limit the number"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"df140735_285d33e9","line":3,"updated":"2017-06-07 17:55:03.000000000","message":"nit, no need for s/In this release port/Port/","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"184eab70e9d129e470059896c478d804c405685f","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"upgrade:"},{"line_number":3,"context_line":"  - In this release port creation logic was moved from the API service to the"},{"line_number":4,"context_line":"    conductor service. This is more consistent with port update operations and"},{"line_number":5,"context_line":"    opens opportunities for conductor-side validations on ports.  However, with"},{"line_number":6,"context_line":"    this change, port creation may take longer, and this may limit the number"}],"source_content_type":"text/x-yaml","patch_set":3,"id":"7f231b9d_e8970d90","line":3,"in_reply_to":"df140735_285d33e9","updated":"2017-06-12 13:58:46.000000000","message":"Done","commit_id":"9450e2205ee23022b0f123f544e548fb33fffbaa"}]}