)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":12,"context_line":"action, done via the REST API."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Change-Id: I08c7370dee330453136931f216d2b54bf4dadc23"},{"line_number":15,"context_line":"blueprint: transfer-ownership"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_3f55c01e","line":15,"range":{"start_line":15,"start_character":11,"end_line":15,"end_character":29},"updated":"2018-09-04 14:15:26.000000000","message":"transfer-instance-ownership","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"673eafcbadf6cc077c43fe1810dbf9594e48627d","unresolved":false,"context_lines":[{"line_number":12,"context_line":"action, done via the REST API."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Change-Id: I08c7370dee330453136931f216d2b54bf4dadc23"},{"line_number":15,"context_line":"blueprint: transfer-ownership"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3f79a3b5_9317bdee","line":15,"range":{"start_line":15,"start_character":11,"end_line":15,"end_character":29},"updated":"2018-09-10 04:53:41.000000000","message":"transfer-instance-ownership","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"}],"specs/stein/approved/transfer-instance-ownership.rst":[{"author":{"_account_id":136,"name":"Tim Bell","email":"tim.bell@cern.ch","username":"tim-bell"},"change_message_id":"72c4820106d2fdb0ac1cfaf45cfbcd7fe3ac2bb2","unresolved":false,"context_lines":[{"line_number":23,"context_line":"baremetal machine resources, it\u0027s common that an organization\u0027s mission or"},{"line_number":24,"context_line":"priorities change. When missions change, often the resources that were owned by"},{"line_number":25,"context_line":"an organization need to be transferred to another organization."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Currently, when this happens, Nova provides no ability through its API to"},{"line_number":28,"context_line":"perform this transfer of ownership. Instead, the operator is required to either"},{"line_number":29,"context_line":"manually update a variety of database records or rely on external information"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_554dfb38","line":26,"updated":"2018-09-04 14:46:25.000000000","message":"Another example would be with nested projects where an additional level is inserted into the hierarchy and the operator wants to move the resources to the right child projects.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89502f641a0d0c3dd6292c17c9195b8770964f5a","unresolved":false,"context_lines":[{"line_number":23,"context_line":"baremetal machine resources, it\u0027s common that an organization\u0027s mission or"},{"line_number":24,"context_line":"priorities change. When missions change, often the resources that were owned by"},{"line_number":25,"context_line":"an organization need to be transferred to another organization."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Currently, when this happens, Nova provides no ability through its API to"},{"line_number":28,"context_line":"perform this transfer of ownership. Instead, the operator is required to either"},{"line_number":29,"context_line":"manually update a variety of database records or rely on external information"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_f0e8d516","line":26,"in_reply_to":"3f79a3b5_554dfb38","updated":"2018-09-04 15:14:58.000000000","message":"Nova doesn\u0027t support hierarchical projects as I\u0027m sure you\u0027re aware. I believe that was punted until nova started consuming keyston\u0027s unified limits API, which no one (at least within the nova core team) is working on.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"89d0266950d362694e7abe1745fa8d1287e99fe1","unresolved":false,"context_lines":[{"line_number":23,"context_line":"baremetal machine resources, it\u0027s common that an organization\u0027s mission or"},{"line_number":24,"context_line":"priorities change. When missions change, often the resources that were owned by"},{"line_number":25,"context_line":"an organization need to be transferred to another organization."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Currently, when this happens, Nova provides no ability through its API to"},{"line_number":28,"context_line":"perform this transfer of ownership. Instead, the operator is required to either"},{"line_number":29,"context_line":"manually update a variety of database records or rely on external information"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_ff184f76","line":26,"in_reply_to":"3f79a3b5_a3299d9c","updated":"2018-09-07 18:41:10.000000000","message":"Someone else was asking about this on the mailing list, which I replied to with a summary [0]. Might be relevant here, too.\n\n[0] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134458.html","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4c25460877eaabf7a040e3a2b3fc7ee4935c3188","unresolved":false,"context_lines":[{"line_number":23,"context_line":"baremetal machine resources, it\u0027s common that an organization\u0027s mission or"},{"line_number":24,"context_line":"priorities change. When missions change, often the resources that were owned by"},{"line_number":25,"context_line":"an organization need to be transferred to another organization."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Currently, when this happens, Nova provides no ability through its API to"},{"line_number":28,"context_line":"perform this transfer of ownership. Instead, the operator is required to either"},{"line_number":29,"context_line":"manually update a variety of database records or rely on external information"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_b3249dc7","line":26,"in_reply_to":"3f79a3b5_f0e8d516","updated":"2018-09-04 22:05:15.000000000","message":"Following up here - we have a few bits left to implement in oslo.limit and then we should be good to start incorporating the entire flow into a service and see how it works. Certainly not something I\u0027m expecting to be fully fleshed out, but hopefully something we can work on a little during Stein with nova.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7bef31cd026b835528556be0b4f66d8f44419a19","unresolved":false,"context_lines":[{"line_number":23,"context_line":"baremetal machine resources, it\u0027s common that an organization\u0027s mission or"},{"line_number":24,"context_line":"priorities change. When missions change, often the resources that were owned by"},{"line_number":25,"context_line":"an organization need to be transferred to another organization."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Currently, when this happens, Nova provides no ability through its API to"},{"line_number":28,"context_line":"perform this transfer of ownership. Instead, the operator is required to either"},{"line_number":29,"context_line":"manually update a variety of database records or rely on external information"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_a3299d9c","line":26,"in_reply_to":"3f79a3b5_f0e8d516","updated":"2018-09-05 15:31:28.000000000","message":"I\u0027m interested in working on using unified limits in nova -- I added an item to our PTG etherpad about it a few weeks ago. I wasn\u0027t sure though, if we\u0027d be able to get started in Stein because there are still some changes need to complete the oslo.limit side. It sounds like Lance is saying we could indeed start something in Stein once the last bits land in oslo.limit.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4c25460877eaabf7a040e3a2b3fc7ee4935c3188","unresolved":false,"context_lines":[{"line_number":67,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":68,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"},{"line_number":69,"context_line":"projects. Attempting to change the owning project/user by a non-admin will"},{"line_number":70,"context_line":"result in a ``403 Forbidden`` response."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":73,"context_line":"accept the new instance."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_76183375","line":70,"updated":"2018-09-04 22:05:15.000000000","message":"As far as I know, nova hasn\u0027t adopt the system-scope work yet, but this sounds like what system-scope was developed for (e.g. superuser).\n\nIf you\u0027d like to add phrasing into this that includes terminology for system-scope to be consistent with what we\u0027re doing in keystone, just let me know.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":76,"context_line":"trigger a ``400 Bad Request`` response."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The target instance\u0027s attached volumes must be transferred to the new target"},{"line_number":79,"context_line":"project separately using the Cinder API\u0027s `volume transfer API`_."},{"line_number":80,"context_line":"Unfortunately, that API involves a multi-step, manual acceptance process and is"},{"line_number":81,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":82,"context_line":"external orchestration system might be able to coordinate the various manual"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_ba047e15","line":79,"range":{"start_line":79,"start_character":42,"end_line":79,"end_character":65},"updated":"2018-09-04 14:15:26.000000000","message":"It\u0027s also not clear to me, from the docs at least, if this allows transferring ownership of an in-use volume which is what nova would care most about here.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"9cc11cbcc6bd9ec28d29a7848343890b4d586760","unresolved":false,"context_lines":[{"line_number":76,"context_line":"trigger a ``400 Bad Request`` response."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The target instance\u0027s attached volumes must be transferred to the new target"},{"line_number":79,"context_line":"project separately using the Cinder API\u0027s `volume transfer API`_."},{"line_number":80,"context_line":"Unfortunately, that API involves a multi-step, manual acceptance process and is"},{"line_number":81,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":82,"context_line":"external orchestration system might be able to coordinate the various manual"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_19bedd64","line":79,"range":{"start_line":79,"start_character":42,"end_line":79,"end_character":65},"in_reply_to":"3f79a3b5_79dfd165","updated":"2018-09-04 16:48:53.000000000","message":"That\u0027s easy to say today. It will come if we add the ability to nova and an auto-accept flag or something is added to the cinder API (and something is added to neutron to transfer port ownership). I\u0027m not necessarily saying we should block *this* proposal on *future* requirements for nova to orchestrate this for volumes and ports as well, or that we\u0027d actually accept those requirements, but I do believe they will naturally come our way.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":76,"context_line":"trigger a ``400 Bad Request`` response."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The target instance\u0027s attached volumes must be transferred to the new target"},{"line_number":79,"context_line":"project separately using the Cinder API\u0027s `volume transfer API`_."},{"line_number":80,"context_line":"Unfortunately, that API involves a multi-step, manual acceptance process and is"},{"line_number":81,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":82,"context_line":"external orchestration system might be able to coordinate the various manual"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_79dfd165","line":79,"range":{"start_line":79,"start_character":42,"end_line":79,"end_character":65},"in_reply_to":"3f79a3b5_ba047e15","updated":"2018-09-04 16:21:28.000000000","message":"But what this spec is proposing is specifically for nova *not* to care about whether the volume is in-use or not. The onus for transferring ownership of the volume is not on nova -- it\u0027s on the operator to do that separately.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_9a6662ed","line":90,"range":{"start_line":88,"start_character":0,"end_line":90,"end_character":54},"updated":"2018-09-04 14:15:26.000000000","message":"Yeah I guess https://developer.openstack.org/api-ref/network/v2/index.html#update-port doesn\u0027t allow changing the project_id on the port.\n\nSo if the operator changes the ownership of the instance but fails to transfer ownership of the volume(s) and port(s), any volumes (BDMs) with the delete_on_termination\u003dTrue flag are going to fail to delete those volumes when the user deletes the VM. And similarly when the user deletes the VM, we\u0027ll fail to delete any ports that nova itself created, because that\u0027s what we do today.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"9cc11cbcc6bd9ec28d29a7848343890b4d586760","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_f946817b","line":90,"range":{"start_line":88,"start_character":0,"end_line":90,"end_character":54},"in_reply_to":"3f79a3b5_19d33d3a","updated":"2018-09-04 16:48:53.000000000","message":"\u003e But I don\u0027t see the existence of those things as a reason not to give Nova and the placement service the basic ability to modify the ownership of an instance record itself\n\nJust because people will do it and things will break, they\u0027ll say it\u0027s nova\u0027s fault for delivering a half-baked feature, and it will increase the requests for nova natively orchestrating the ownership transfer for volumes and ports. Again, same reply as above about whether or not that should matter to us, but I expect it will come.\n\n\u003e and allow Nova to participate in an ownership-transfer effort by external orchestrators or scripts.\n\nYeah this is the key bit - people doing this will need to be aware it\u0027s not an end-to-end solution and for that to be clean it has to be done as part of a larger resource ownership transfer orchestration system. Admin docs and API reference would be about as good as we can do in nova today for trying to stem the tide of bugs.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_19d33d3a","line":90,"range":{"start_line":88,"start_character":0,"end_line":90,"end_character":54},"in_reply_to":"3f79a3b5_9a6662ed","updated":"2018-09-04 16:21:28.000000000","message":"\u003e Yeah I guess https://developer.openstack.org/api-ref/network/v2/index.html#update-port\n \u003e doesn\u0027t allow changing the project_id on the port.\n\nYeah, I checked with the Neutron team to see if there was some backdoor way of changing ownership of a port. There isn\u0027t. Requires manual DB mucking.\n\n \u003e So if the operator changes the ownership of the instance but fails\n \u003e to transfer ownership of the volume(s) and port(s), any volumes\n \u003e (BDMs) with the delete_on_termination\u003dTrue flag are going to fail\n \u003e to delete those volumes when the user deletes the VM. And similarly\n \u003e when the user deletes the VM, we\u0027ll fail to delete any ports that\n \u003e nova itself created, because that\u0027s what we do today.\n\nSure. I\u0027m not sure I care about this more than just noting it in the documentation, though. I\u0027m not trying to boil the ocean and I\u0027m definitely not trying to make Nova an orchestration system. There\u0027s a distinct set of things that are not possible to do without manual intervention w.r.t transferring ownership of the various resources potentially associated with an instance. But I don\u0027t see the existence of those things as a reason not to give Nova and the placement service the basic ability to modify the ownership of an instance record itself and allow Nova to participate in an ownership-transfer effort by external orchestrators or scripts.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47c48d6a505c96be53a752e4bcf881cbca3afa0e","unresolved":false,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_70c27e55","line":90,"range":{"start_line":88,"start_character":0,"end_line":90,"end_character":54},"in_reply_to":"3f79a3b5_f946817b","updated":"2018-09-04 19:26:50.000000000","message":"\u003e \u003e But I don\u0027t see the existence of those things as a reason not to\n \u003e give Nova and the placement service the basic ability to modify the\n \u003e ownership of an instance record itself\n \u003e \n \u003e Just because people will do it and things will break, they\u0027ll say\n \u003e it\u0027s nova\u0027s fault for delivering a half-baked feature, and it will\n \u003e increase the requests for nova natively orchestrating the ownership\n \u003e transfer for volumes and ports. Again, same reply as above about\n \u003e whether or not that should matter to us, but I expect it will come.\n\nI would like to see incremental progress made in this arena.  I don\u0027t buy the argument that \"we shouldn\u0027t do this because people will blame nova if it doesn\u0027t do everything involving all the other services in one operation\". More below...\n\n \u003e \u003e and allow Nova to participate in an ownership-transfer effort by\n \u003e external orchestrators or scripts.\n \u003e \n \u003e Yeah this is the key bit - people doing this will need to be aware\n \u003e it\u0027s not an end-to-end solution and for that to be clean it has to\n \u003e be done as part of a larger resource ownership transfer\n \u003e orchestration system. Admin docs and API reference would be about\n \u003e as good as we can do in nova today for trying to stem the tide of\n \u003e bugs.\n\nYes, and I\u0027m pretty clear (I hope?) about that in this spec. We\u0027re not trying to do anything more than necessary to participate in an external script that can solve the overall resource ownership transfer problem. All this spec is doing is proposing to solve the things we *do* have control over: the placement and nova-specific parts.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":136,"name":"Tim Bell","email":"tim.bell@cern.ch","username":"tim-bell"},"change_message_id":"72c4820106d2fdb0ac1cfaf45cfbcd7fe3ac2bb2","unresolved":false,"context_lines":[{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d50fcbdd","line":91,"updated":"2018-09-04 14:46:25.000000000","message":"Without wanting to make this more complicated, would there need to be matching flavors and images too? Maybe just fail in these cases.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_19bc9dda","line":91,"in_reply_to":"3f79a3b5_d50fcbdd","updated":"2018-09-04 16:21:28.000000000","message":"\u003e Without wanting to make this more complicated, would there need to\n \u003e be matching flavors and images too? Maybe just fail in these cases.\n\nI presume you\u0027re speaking about private flavors and images. I can add some text about the admin needing to \"share\" an image in Glance with the target project. As Matt said, we copy flavor details into the instance\u0027s metadata to avoid the kinds of problems we\u0027ve had in the past with changing of flavor contents over time (or deleting flavors, etc).","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"89502f641a0d0c3dd6292c17c9195b8770964f5a","unresolved":false,"context_lines":[{"line_number":88,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":89,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":90,"context_line":"exercise by the operator against the Neutron database."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Alternatives"},{"line_number":93,"context_line":"------------"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_30bbad0f","line":91,"in_reply_to":"3f79a3b5_d50fcbdd","updated":"2018-09-04 15:14:58.000000000","message":"As in, if the original project had private flavors, those would be transferred too? That\u0027s separate from a per-instance ownership transfer IMO - it\u0027d be something on the PUT /flavors/{flavor_id} API.\n\nBut the instances being transferred to another project already have their embedded flavor as part of the instance, and that\u0027s what gets returned out of the API when you show details about the server (at least starting with microversion 2.47). That allows us to continue to work with the instance, like resize it, even if the original flavor used to create the server was deleted.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":100,"context_line":"transfer as an operation to the operator-facing ``nova-manage`` CLI tool that"},{"line_number":101,"context_line":"mucks with the placement and nova cell DBs directly."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We could enforce some kind of \"lock\" on the server instance before attempting"},{"line_number":104,"context_line":"to transfer the ownership of the instance. In other words, perform a lock"},{"line_number":105,"context_line":"instance, then transfer ownership, then unlock instance. This would prevent"},{"line_number":106,"context_line":"migrations or other operations, though it\u0027s unclear whether or not those"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_9a94228d","line":103,"updated":"2018-09-04 14:15:26.000000000","message":"Changing the task_state on the instance should prevent other operations from happening to it while ownership is transferred, except for delete.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47c48d6a505c96be53a752e4bcf881cbca3afa0e","unresolved":false,"context_lines":[{"line_number":100,"context_line":"transfer as an operation to the operator-facing ``nova-manage`` CLI tool that"},{"line_number":101,"context_line":"mucks with the placement and nova cell DBs directly."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We could enforce some kind of \"lock\" on the server instance before attempting"},{"line_number":104,"context_line":"to transfer the ownership of the instance. In other words, perform a lock"},{"line_number":105,"context_line":"instance, then transfer ownership, then unlock instance. This would prevent"},{"line_number":106,"context_line":"migrations or other operations, though it\u0027s unclear whether or not those"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_f00f6edd","line":103,"in_reply_to":"3f79a3b5_990d0d40","updated":"2018-09-04 19:26:50.000000000","message":"\u003e If we care about not performing other operations on the instance\n \u003e while it\u0027s being \"transferred\" then yes, a task_state change is\n \u003e likely what we\u0027d do rather than orchestrate a lock/transfer/unlock\n \u003e routine.\n \u003e \n \u003e Today we don\u0027t set a task_state on update just because we aren\u0027t\n \u003e casting to anything, we\u0027re just updating the database record, which\n \u003e we\u0027d be doing here as well, so I don\u0027t know how much we need to\n \u003e care about locking here.\n \u003e \n \u003e Having said that, the update operation today doesn\u0027t 409 if the\n \u003e instance is undergoing some operation, and we probably should in\n \u003e this case during ownership transfer. I\u0027m actually surprised we\n \u003e don\u0027t check task_state on update today because you can change the\n \u003e auto_disk_config setting which matters for xen.\n \u003e \n \u003e Whether or not something could be screwed up because the owner\n \u003e changes while the instance is being resized, for example, I don\u0027t\n \u003e know. I wouldn\u0027t be surprised though. Although during a resize\n \u003e we\u0027re using the user\u0027s token which would be the old owner of the\n \u003e instance, and that token should then be able to get access to the\n \u003e volumes/image/ports associated with the instance to complete the\n \u003e resize even if it\u0027s transferred during the resize.\n \u003e \n \u003e I\u0027m rambling, might as well just mention \"we could also set a\n \u003e task_state\" as an alternative to the lock/unlock alternative just\n \u003e so it\u0027s recorded.\n\nNo, I like your suggestion of the task_state thing. I\u0027ll add to the next revision.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":100,"context_line":"transfer as an operation to the operator-facing ``nova-manage`` CLI tool that"},{"line_number":101,"context_line":"mucks with the placement and nova cell DBs directly."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We could enforce some kind of \"lock\" on the server instance before attempting"},{"line_number":104,"context_line":"to transfer the ownership of the instance. In other words, perform a lock"},{"line_number":105,"context_line":"instance, then transfer ownership, then unlock instance. This would prevent"},{"line_number":106,"context_line":"migrations or other operations, though it\u0027s unclear whether or not those"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_b9cc8989","line":103,"in_reply_to":"3f79a3b5_9a94228d","updated":"2018-09-04 16:21:28.000000000","message":"Are you suggesting we add a new task_state for CHANGE_OWNER or something like that?","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"9cc11cbcc6bd9ec28d29a7848343890b4d586760","unresolved":false,"context_lines":[{"line_number":100,"context_line":"transfer as an operation to the operator-facing ``nova-manage`` CLI tool that"},{"line_number":101,"context_line":"mucks with the placement and nova cell DBs directly."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We could enforce some kind of \"lock\" on the server instance before attempting"},{"line_number":104,"context_line":"to transfer the ownership of the instance. In other words, perform a lock"},{"line_number":105,"context_line":"instance, then transfer ownership, then unlock instance. This would prevent"},{"line_number":106,"context_line":"migrations or other operations, though it\u0027s unclear whether or not those"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_990d0d40","line":103,"in_reply_to":"3f79a3b5_b9cc8989","updated":"2018-09-04 16:48:53.000000000","message":"If we care about not performing other operations on the instance while it\u0027s being \"transferred\" then yes, a task_state change is likely what we\u0027d do rather than orchestrate a lock/transfer/unlock routine.\n\nToday we don\u0027t set a task_state on update just because we aren\u0027t casting to anything, we\u0027re just updating the database record, which we\u0027d be doing here as well, so I don\u0027t know how much we need to care about locking here.\n\nHaving said that, the update operation today doesn\u0027t 409 if the instance is undergoing some operation, and we probably should in this case during ownership transfer. I\u0027m actually surprised we don\u0027t check task_state on update today because you can change the auto_disk_config setting which matters for xen.\n\nWhether or not something could be screwed up because the owner changes while the instance is being resized, for example, I don\u0027t know. I wouldn\u0027t be surprised though. Although during a resize we\u0027re using the user\u0027s token which would be the old owner of the instance, and that token should then be able to get access to the volumes/image/ports associated with the instance to complete the resize even if it\u0027s transferred during the resize.\n\nI\u0027m rambling, might as well just mention \"we could also set a task_state\" as an alternative to the lock/unlock alternative just so it\u0027s recorded.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"a39d81a9e33d6db9f407684e48f765f015f1fcef","unresolved":false,"context_lines":[{"line_number":132,"context_line":"~~~~~~~~~~~~~~~~~~~~~"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"The placement service will get a brand new API endpoint for modifying a"},{"line_number":135,"context_line":"consumer\u0027s information. The new ``PUT /consumers/{consumer_id}`` endpoint will"},{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_eab6a1f9","line":135,"updated":"2018-09-04 18:14:01.000000000","message":"Not trying to scratch a scabby wound but:\n\nCould this also be accomplished by a GET /allocations/{consumer_uuid}, modify proj and user, PUT /allocations/{consumer_uuid} because, essentially the allocations URL is \"all the info about this consumer\u0027s relationship (via allocations) with placement\".\n\nI\u0027m not saying \"no\", I\u0027m simply asking if it\u0027s an option.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"2a98c2c6aec2f1a3b2cc6462660dd3c5b01b7ee8","unresolved":false,"context_lines":[{"line_number":132,"context_line":"~~~~~~~~~~~~~~~~~~~~~"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"The placement service will get a brand new API endpoint for modifying a"},{"line_number":135,"context_line":"consumer\u0027s information. The new ``PUT /consumers/{consumer_id}`` endpoint will"},{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_ca308558","line":135,"in_reply_to":"3f79a3b5_eab6a1f9","updated":"2018-09-04 18:21:22.000000000","message":"\u003e Not trying to scratch a scabby wound but:\n \u003e \n \u003e Could this also be accomplished by a GET /allocations/{consumer_uuid},\n \u003e modify proj and user, PUT /allocations/{consumer_uuid} because,\n \u003e essentially the allocations URL is \"all the info about this\n \u003e consumer\u0027s relationship (via allocations) with placement\".\n \u003e \n \u003e I\u0027m not saying \"no\", I\u0027m simply asking if it\u0027s an option.\n\nI don\u0027t see how doing that would be either a) simpler or b) cleaner.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47c48d6a505c96be53a752e4bcf881cbca3afa0e","unresolved":false,"context_lines":[{"line_number":132,"context_line":"~~~~~~~~~~~~~~~~~~~~~"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"The placement service will get a brand new API endpoint for modifying a"},{"line_number":135,"context_line":"consumer\u0027s information. The new ``PUT /consumers/{consumer_id}`` endpoint will"},{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_10378ab2","line":135,"in_reply_to":"3f79a3b5_eab6a1f9","updated":"2018-09-04 19:26:50.000000000","message":"@cdent I added this to the alternatives section in latest revision.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_bac79e98","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"updated":"2018-09-04 14:15:26.000000000","message":"Would Placement also be asserting that the user is a member of the project, as noted on L75 above?","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"70dbc8d0cb670cf59105435e5bb71624afb0801c","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d3527967","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"in_reply_to":"3f79a3b5_5050a2d5","updated":"2018-09-04 21:39:56.000000000","message":"\u003e ack. perhaps we should just leave all of the validation out\n \u003e entirely and just rely on the admin to know what they are doing\n \u003e (and have queried keystone appropriately to determine that the user\n \u003e ID is indeed in the target project).\n\nI don\u0027t know. For the longest time you could assign flavors/quotas to specific tenant IDs but we didn\u0027t validate the provided tenant ID in keystone so they could be typo\u0027d and the user would get a success response for something that didn\u0027t actually work. I\u0027d say at a minimum we should validate the project/user at least *exist*. How easy it is to determine their relationship to each other, or if nova should even do that, idk, would need to ask Lance or someone.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"9cc11cbcc6bd9ec28d29a7848343890b4d586760","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_bc66b7ec","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"in_reply_to":"3f79a3b5_79c27155","updated":"2018-09-04 16:48:53.000000000","message":"Neither does nova, right? I mean, nova has to ask the identity service, and presumably placement would too. Maybe you mean something different here though.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_79c27155","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"in_reply_to":"3f79a3b5_bac79e98","updated":"2018-09-04 16:21:28.000000000","message":"\u003e Would Placement also be asserting that the user is a member of the\n \u003e project, as noted on L75 above?\n\nNo, since placement has no idea (currently) about the relationship between a user and project membership.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47c48d6a505c96be53a752e4bcf881cbca3afa0e","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_5050a2d5","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"in_reply_to":"3f79a3b5_bc66b7ec","updated":"2018-09-04 19:26:50.000000000","message":"ack. perhaps we should just leave all of the validation out entirely and just rely on the admin to know what they are doing (and have queried keystone appropriately to determine that the user ID is indeed in the target project).","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"4c25460877eaabf7a040e3a2b3fc7ee4935c3188","unresolved":false,"context_lines":[{"line_number":136,"context_line":"accept the following request payload::"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"    {"},{"line_number":139,"context_line":"        \"project_id\": \"\u003cexternal ID of project\u003e\","},{"line_number":140,"context_line":"        \"user_id\": \"\u003cexternal ID of user\u003e\","},{"line_number":141,"context_line":"        \"generation\": \u003ccurrent generation of consumer\u003e"},{"line_number":142,"context_line":"    }"},{"line_number":143,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_563c1792","line":140,"range":{"start_line":139,"start_character":8,"end_line":140,"end_character":43},"in_reply_to":"3f79a3b5_d3527967","updated":"2018-09-04 22:05:15.000000000","message":"We have a couple different ways nova, or placement, could verify a user\u0027s membership. As the nova service user, if you know the user\u0027s ID and project ID the resource is being transferred to (which looks like it comes from the payload), you could call the roles API [0].\n\n  GET -H \"X-Auth-Token: $nova_service_token\" \\ \n  http://identity.example.com/v3/projects/{project_id}/users/{user_id}/roles\n\nIf you have a token for the user accepting the resource, you can ask keystone directly which projects that user has authorization on [1], but I\u0027m not sure you\u0027ll have that information since the request is initiated by the person transferring the resource and not the person accepting the transfer.\n\n[0] https://developer.openstack.org/api-ref/identity/v3/index.html#list-role-assignments-for-user-on-project\n[1] https://developer.openstack.org/api-ref/identity/v3/index.html#get-available-project-scopes","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82f766292d018760b92f6565b6bdb0f651f6bc10","unresolved":false,"context_lines":[{"line_number":189,"context_line":"Other end user impact"},{"line_number":190,"context_line":"---------------------"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"None"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Performance Impact"},{"line_number":195,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_da413a0c","line":192,"updated":"2018-09-04 14:15:26.000000000","message":"Assume you would update novaclient and/or openstackclient for CLI changes to server update.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[{"line_number":189,"context_line":"Other end user impact"},{"line_number":190,"context_line":"---------------------"},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"None"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Performance Impact"},{"line_number":195,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_f9abe184","line":192,"in_reply_to":"3f79a3b5_da413a0c","updated":"2018-09-04 16:21:28.000000000","message":"ack","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5c154ab1badbc32cb6a220b603eb4e07d24b875e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3f79a3b5_fa5f56e2","line":262,"updated":"2018-09-04 14:15:44.000000000","message":"Missing the History section from the template.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47c48d6a505c96be53a752e4bcf881cbca3afa0e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3f79a3b5_d03cb293","line":262,"in_reply_to":"3f79a3b5_398f192b","updated":"2018-09-04 19:26:50.000000000","message":"Done","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"981b39a332b72816dfe3dd94ff8bc34c7cbfa9d6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3f79a3b5_398f192b","line":262,"in_reply_to":"3f79a3b5_fa5f56e2","updated":"2018-09-04 16:21:28.000000000","message":"will add back with reference to the prior art.","commit_id":"1f715fe384f2b1aa8fade7cbad8eed003a508c95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"As an OpenStack user of some baremetal machines, the organization for which I"},{"line_number":42,"context_line":"work has changed direction and applications running on those baremetal machines"},{"line_number":43,"context_line":"are now under the management of a different group within my company. I wish to"},{"line_number":44,"context_line":"change the `project_id` of the instances currently under my organization to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_44741a68","line":41,"range":{"start_line":41,"start_character":29,"end_line":41,"end_character":38},"updated":"2018-09-07 18:26:31.000000000","message":"Why are you calling out baremetal here? I mean, I\u0027m sure it matters to your use case, but presumably it\u0027s immaterial to the actual functionality right?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"As an OpenStack user of some baremetal machines, the organization for which I"},{"line_number":42,"context_line":"work has changed direction and applications running on those baremetal machines"},{"line_number":43,"context_line":"are now under the management of a different group within my company. I wish to"},{"line_number":44,"context_line":"change the `project_id` of the instances currently under my organization to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_97c7bf12","line":41,"range":{"start_line":41,"start_character":29,"end_line":41,"end_character":38},"in_reply_to":"3f79a3b5_24dc7edf","updated":"2018-09-07 21:37:41.000000000","message":"Okay, but without it being specific to baremetal, it\u0027s confusing I think. Can we just remove it since it applies to any kind of instance?\n\nOtherwise this seems like some cop-out where later you\u0027ll say you only care about or recognize pet-ish behavior if it\u0027s installed on metal...\n\n/kidding\n\n\n/kinda","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"As an OpenStack user of some baremetal machines, the organization for which I"},{"line_number":42,"context_line":"work has changed direction and applications running on those baremetal machines"},{"line_number":43,"context_line":"are now under the management of a different group within my company. I wish to"},{"line_number":44,"context_line":"change the `project_id` of the instances currently under my organization to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_24dc7edf","line":41,"range":{"start_line":41,"start_character":29,"end_line":41,"end_character":38},"in_reply_to":"3f79a3b5_44741a68","updated":"2018-09-07 19:09:29.000000000","message":"It\u0027s my use case, nothing more. Also, baremetals are more pet-like, and this use case is indeed pet-centric.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7233acea55c5fe320bc87edbcce1567437465dd9","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"As an OpenStack user of some baremetal machines, the organization for which I"},{"line_number":42,"context_line":"work has changed direction and applications running on those baremetal machines"},{"line_number":43,"context_line":"are now under the management of a different group within my company. I wish to"},{"line_number":44,"context_line":"change the `project_id` of the instances currently under my organization to the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_2980c4f6","line":41,"range":{"start_line":41,"start_character":29,"end_line":41,"end_character":38},"in_reply_to":"3f79a3b5_97c7bf12","updated":"2018-09-09 14:43:13.000000000","message":"I will remove the mention of baremetal, yes.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_04edc2ee","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"updated":"2018-09-07 18:26:31.000000000","message":"The consumer_id is an instance uuid for nova, which was implicitly created when we created allocations and provided the user/project information at that time, right?\n\nI suppose another alternative is to do something similar to what we do when we atomically swap an instance allocation for a migration placeholder, in that we just put the allocation over top of the existing one, but with the new user/project info. Placement would (need to change to?) noticing that and updating the consumer record I guess.\n\nThe thing that seems more appropriate there, or maybe highlights some of why this is hard, is that what if the consumer owns allocations against a cinder-managed provider and a nova-managed provider? Nova simply changing the consumer of the allocation it manages as well as the allocation cinder manages simply by adjusting the consumer object itself seems a little weird to me. Now that I say it, I\u0027m not sure how putting the allocations over again with the new consumer makes that different, but it seems like less change to the placement API.\n\nSo even if the allocation thing is dumb, what\u0027s the thinking on changing the effective consumer information on resources that nova is not in charge of managing?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_dfd6b327","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"in_reply_to":"3f79a3b5_04edc2ee","updated":"2018-09-07 19:09:29.000000000","message":"\u003e The consumer_id is an instance uuid for nova, which was implicitly\n \u003e created when we created allocations and provided the user/project\n \u003e information at that time, right?\n\nThe consumer_id is *currently* the instance UUID from Nova, yes (and the migration UUID as you point out below).\n\nThere\u0027s been discussion about consumer types and such that would expand the current thinking around consumers being nova-centric of course.\n\n \u003e I suppose another alternative is to do something similar to what we\n \u003e do when we atomically swap an instance allocation for a migration\n \u003e placeholder, in that we just put the allocation over top of the\n \u003e existing one, but with the new user/project info. Placement would\n \u003e (need to change to?) noticing that and updating the consumer record\n \u003e I guess.\n\nWe actually don\u0027t \"swap\" the allocation any more. We create a new allocation that is associated with the migration UUID pointing at resource providers on the source node and create a new allocation that is associated with the original instance UUID pointing at the resource providers on the destination node. Then, when the migration is confirmed, we simply delete the allocation referencing the migration UUID.\n\n \u003e The thing that seems more appropriate there, or maybe highlights\n \u003e some of why this is hard, is that what if the consumer owns\n \u003e allocations against a cinder-managed provider and a nova-managed\n \u003e provider? Nova simply changing the consumer of the allocation it\n \u003e manages as well as the allocation cinder manages simply by\n \u003e adjusting the consumer object itself seems a little weird to me.\n \u003e Now that I say it, I\u0027m not sure how putting the allocations over\n \u003e again with the new consumer makes that different, but it seems like\n \u003e less change to the placement API.\n\nAs mentioned below, Cinder already has its own volume ownership transfer mechanism, built in to its own REST API. It\u0027s not ideal IMHO (due to the manual acceptance process steps involved) but it *is* evidence that the process of transferring ownership of a stateful thing is a real use case and all this spec is proposing is that Nova and the placement service provide *some* ability to participate in the overall multi-service process of transferring ownership of some resources.\n\n \u003e So even if the allocation thing is dumb, what\u0027s the thinking on\n \u003e changing the effective consumer information on resources that nova\n \u003e is not in charge of managing?\n\nI personally think having a GET|PUT /consumers/{consumer_id} endpoint in the placement REST API is the simplest and most common sense of providing the placement side of this request. While I realize the PUT /allocations/{consumer_id} endpoint already exists, it offends my delicate balance and sensibilities that that call will end up needlessly replacing the consumer\u0027s set of allocations and that the object/model that we are referring to here (and updating state for) is the consumer, not the allocations for that consumer.\n\nI\u0027m not entirely sure how to answer the question about changing consumer information on resources that nova is not in charge of managing since at this point nothing like that yet exists. We can chat about that further in Denver I guess.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_dfa473bb","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"in_reply_to":"3f79a3b5_04edc2ee","updated":"2018-09-07 19:09:51.000000000","message":"\u003e but it seems like less change to the placement API.\n\nI believe this is what Chris was getting at in earlier comments.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"03d0a9cd0dc960295d5e97c55564177ef8fe24eb","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ac5062d6","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"in_reply_to":"3f79a3b5_099e2853","updated":"2018-09-09 16:45:30.000000000","message":"\u003e In the case of migrations, we are moving the allocations from one\n \u003e consumer to another.\n \u003e \n \u003e In this spec, we aren\u0027t transferring allocations from one consumer\n \u003e to another. We are changing the project and user attributes of the\n \u003e consumer that is associated with the allocation set. It\u0027s a\n \u003e completely different thing.\n\n...and I\u0027m saying I\u0027m not sure it needs to be a different thing. Since there isn\u0027t a top-level consumer object in placement (I know, I know), the user/project association is provided via the allocation when we set it. So, I\u0027m just saying that updating the allocation with whatever has changed (in this case, just the user/project) seems to me to be the least change and the most straightforward. It also has the benefit of potentially addressing my concern about the confusion that will come from needing to update the nova part of the allocation without updating the cinder part.\n\n \u003e I don\u0027t know what you are trying to say above. Just because some\n \u003e volume may be on shared storage doesn\u0027t mean that part of the\n \u003e allocation is a different consumer. The set of allocations is an\n \u003e atomic set of allocation records, all of which are associated with\n \u003e a *single* consumer. By having a separate endpoint that allows\n \u003e changing a consumer\u0027s project and user we avoid needing to mess\n \u003e with the allocation records *at all* and avoid needing to even\n \u003e think in terms of the allocation records. You just change the\n \u003e project and user attributes of the consumer. You\u0027re not changing\n \u003e the consumer. You\u0027re changing attributes *about* the consumer.\n\nBut today, consumer isn\u0027t a thing in the placement API. I obviously get that the allocations are a single atomically-managed record, which is why I find it problematic to just implement this in one service and not all of the services. Because we\u0027re going to have to do this change, either by introducing a consumer, or by modifying the one set of user/project attributes on the allocation.\n\nWhat I\u0027m \"trying to say above\" is that implementing this in nova, and having it change the user/project of allocations that it does not own without any way to coordinate that (programmatically) across services, seems like a problem to me.\n\n \u003e What is ugly is the existing allocations APIs. I\u0027m trying to avoid\n \u003e needing to use them since what we\u0027re talking about here isn\u0027t\n \u003e allocation-related. It\u0027s consumer-related.\n\nWhat \"we\u0027re talking about here\" is changing the user and project fields, right? Speaking strictly as a placement API user who knows nothing about placement internals, there is no such thing as a consumer. There is a consumer identifier (and generation, which I agree looks a little wonky from the outside now).\n\nIf I look at the placement API ref, the user and project values are fields on the allocation, and mention nothing about being related to the consumer:\n\nhttps://developer.openstack.org/api-ref/placement/#list-allocations\n\nAnyway, sounds like discussion for in Denver.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7233acea55c5fe320bc87edbcce1567437465dd9","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_099e2853","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"in_reply_to":"3f79a3b5_17cc0f68","updated":"2018-09-09 14:43:13.000000000","message":"\u003e \u003e We actually don\u0027t \"swap\" the allocation any more. We create a new\n \u003e \u003e allocation that is associated with the migration UUID pointing at\n \u003e \u003e resource providers on the source node and create a new allocation\n \u003e \u003e that is associated with the original instance UUID pointing at\n \u003e the\n \u003e \u003e resource providers on the destination node. Then, when the\n \u003e \u003e migration is confirmed, we simply delete the allocation\n \u003e referencing\n \u003e \u003e the migration UUID.\n \u003e \n \u003e What I meant by \"swap\" is that we atomically replace the instance\u0027s\n \u003e allocation on the source with one of the same size owned by the\n \u003e migration. Chris added that atomic delete-and-post behavior in 1.13\n \u003e for the migration de-doubling work I did:\n \u003e \n \u003e https://docs.openstack.org/nova/queens/user/placement.html#post-multiple-allocations-to-allocations\n\nIn the case of migrations, we are moving the allocations from one consumer to another.\n\nIn this spec, we aren\u0027t transferring allocations from one consumer to another. We are changing the project and user attributes of the consumer that is associated with the allocation set. It\u0027s a completely different thing.\n\n \u003e \u003e I personally think having a GET|PUT /consumers/{consumer_id}\n \u003e \u003e endpoint in the placement REST API is the simplest and most\n \u003e common\n \u003e \u003e sense of providing the placement side of this request. While I\n \u003e \u003e realize the PUT /allocations/{consumer_id} endpoint already\n \u003e exists,\n \u003e \u003e it offends my delicate balance and sensibilities that that call\n \u003e \u003e will end up needlessly replacing the consumer\u0027s set of\n \u003e allocations\n \u003e \u003e and that the object/model that we are referring to here (and\n \u003e \u003e updating state for) is the consumer, not the allocations for that\n \u003e \u003e consumer.\n \u003e \n \u003e Where it lives is completely unrelated to the question of changing\n \u003e the ownership of multiple allocations by tweaking the consumer\n \u003e underneath. I guess the thing that makes more sense to me about\n \u003e posting the allocation is that you\u0027re saying \"Yep, I know that this\n \u003e is the full set of allocations I\u0027m affecting by this change.\" It\n \u003e also opens the door for us to say \"I\u0027m posting an allocation and\n \u003e changing the consumer of nova\u0027s part, but not cinder\u0027s part.\" I\u0027m\n \u003e not saying we would ever make it that fine-grained, but if we start\n \u003e out just tweaking the consumer without the allocation entirely, I\n \u003e think we\u0027re side-stepping that whole thing, which doesn\u0027t seem\n \u003e right to me.\n\nI don\u0027t know what you are trying to say above. Just because some volume may be on shared storage doesn\u0027t mean that part of the allocation is a different consumer. The set of allocations is an atomic set of allocation records, all of which are associated with a *single* consumer. By having a separate endpoint that allows changing a consumer\u0027s project and user we avoid needing to mess with the allocation records *at all* and avoid needing to even think in terms of the allocation records. You just change the project and user attributes of the consumer. You\u0027re not changing the consumer. You\u0027re changing attributes *about* the consumer. \n\n \u003e \u003e I\u0027m not entirely sure how to answer the question about changing\n \u003e \u003e consumer information on resources that nova is not in charge of\n \u003e \u003e managing since at this point nothing like that yet exists. We can\n \u003e \u003e chat about that further in Denver I guess.\n \u003e \n \u003e Sure. Seems like that\u0027s going to get fairly ugly, IMHO.\n\nWhat is ugly is the existing allocations APIs. I\u0027m trying to avoid needing to use them since what we\u0027re talking about here isn\u0027t allocation-related. It\u0027s consumer-related.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":51,"context_line":"This spec proposes to add the ability to transfer ownership of an instance via"},{"line_number":52,"context_line":"a new microversion to the placement and Compute API."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The placement REST API will get a new ``PUT /consumers/{consumer_id}``"},{"line_number":55,"context_line":"endpoint, accepting a request payload containing the new project and user along"},{"line_number":56,"context_line":"with the consumer\u0027s generation."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_17cc0f68","line":54,"range":{"start_line":54,"start_character":38,"end_line":54,"end_character":70},"in_reply_to":"3f79a3b5_dfd6b327","updated":"2018-09-07 21:37:41.000000000","message":"\u003e We actually don\u0027t \"swap\" the allocation any more. We create a new\n \u003e allocation that is associated with the migration UUID pointing at\n \u003e resource providers on the source node and create a new allocation\n \u003e that is associated with the original instance UUID pointing at the\n \u003e resource providers on the destination node. Then, when the\n \u003e migration is confirmed, we simply delete the allocation referencing\n \u003e the migration UUID.\n\nWhat I meant by \"swap\" is that we atomically replace the instance\u0027s allocation on the source with one of the same size owned by the migration. Chris added that atomic delete-and-post behavior in 1.13 for the migration de-doubling work I did:\n\nhttps://docs.openstack.org/nova/queens/user/placement.html#post-multiple-allocations-to-allocations\n\n \u003e I personally think having a GET|PUT /consumers/{consumer_id}\n \u003e endpoint in the placement REST API is the simplest and most common\n \u003e sense of providing the placement side of this request. While I\n \u003e realize the PUT /allocations/{consumer_id} endpoint already exists,\n \u003e it offends my delicate balance and sensibilities that that call\n \u003e will end up needlessly replacing the consumer\u0027s set of allocations\n \u003e and that the object/model that we are referring to here (and\n \u003e updating state for) is the consumer, not the allocations for that\n \u003e consumer.\n\nWhere it lives is completely unrelated to the question of changing the ownership of multiple allocations by tweaking the consumer underneath. I guess the thing that makes more sense to me about posting the allocation is that you\u0027re saying \"Yep, I know that this is the full set of allocations I\u0027m affecting by this change.\" It also opens the door for us to say \"I\u0027m posting an allocation and changing the consumer of nova\u0027s part, but not cinder\u0027s part.\" I\u0027m not saying we would ever make it that fine-grained, but if we start out just tweaking the consumer without the allocation entirely, I think we\u0027re side-stepping that whole thing, which doesn\u0027t seem right to me.\n\n \u003e I\u0027m not entirely sure how to answer the question about changing\n \u003e consumer information on resources that nova is not in charge of\n \u003e managing since at this point nothing like that yet exists. We can\n \u003e chat about that further in Denver I guess.\n\nSure. Seems like that\u0027s going to get fairly ugly, IMHO.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":67,"context_line":"In order to facilitate a \"lock\" on the server instance during the ownership"},{"line_number":68,"context_line":"transfer, we\u0027ll add a new ``task_state`` of ``CHANGE_OWNER``. Setting the task"},{"line_number":69,"context_line":"state to something effectively guards the instance against changes from other"},{"line_number":70,"context_line":"users."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6490364f","line":70,"updated":"2018-09-07 18:26:31.000000000","message":"I\u0027m allergic to new task states. What lock do we need exactly? Is this to cover the delay between updating the allocations and then actually re-owning the instance in our own database?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":67,"context_line":"In order to facilitate a \"lock\" on the server instance during the ownership"},{"line_number":68,"context_line":"transfer, we\u0027ll add a new ``task_state`` of ``CHANGE_OWNER``. Setting the task"},{"line_number":69,"context_line":"state to something effectively guards the instance against changes from other"},{"line_number":70,"context_line":"users."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_5f0e2332","line":70,"in_reply_to":"3f79a3b5_6490364f","updated":"2018-09-07 19:09:29.000000000","message":"@mriedem suggested to use a task_state change to lock the instance from change during the coordination with the placement service and the modification of the instance\u0027s project/user attribute in the database.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":67,"context_line":"In order to facilitate a \"lock\" on the server instance during the ownership"},{"line_number":68,"context_line":"transfer, we\u0027ll add a new ``task_state`` of ``CHANGE_OWNER``. Setting the task"},{"line_number":69,"context_line":"state to something effectively guards the instance against changes from other"},{"line_number":70,"context_line":"users."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_9f835b03","line":70,"in_reply_to":"3f79a3b5_6490364f","updated":"2018-09-07 19:09:51.000000000","message":"That, or whatever we\u0027re doing while updating the record yeah. I really hemmed and hawed on this when originally bringing it up:\n\nhttps://review.openstack.org/#/c/599598/3/specs/stein/approved/transfer-instance-ownership.rst@103\n\nI\u0027m not married to it, I just wouldn\u0027t want someone trying to migrate the damn thing while we\u0027re changing ownership.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":67,"context_line":"In order to facilitate a \"lock\" on the server instance during the ownership"},{"line_number":68,"context_line":"transfer, we\u0027ll add a new ``task_state`` of ``CHANGE_OWNER``. Setting the task"},{"line_number":69,"context_line":"state to something effectively guards the instance against changes from other"},{"line_number":70,"context_line":"users."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f7bcf3b5","line":70,"in_reply_to":"3f79a3b5_9f835b03","updated":"2018-09-07 21:37:41.000000000","message":"Yeah, I just hate adding new task states off the cuff. It\u0027s not a state machine and we suck at handling all kinds of things about it, so adding more just because we know basically any task state will cause most things to not work seems sloppy.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"},{"line_number":74,"context_line":"projects. Attempting to change the owning project/user by a non-admin will"},{"line_number":75,"context_line":"result in a ``403 Forbidden`` response."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":78,"context_line":"accept the new instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_049b8272","line":75,"updated":"2018-09-07 18:26:31.000000000","message":"Does that mean the new attributes are visible to all, but mutable only by admins, or hidden to all-but-admins?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"},{"line_number":74,"context_line":"projects. Attempting to change the owning project/user by a non-admin will"},{"line_number":75,"context_line":"result in a ``403 Forbidden`` response."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":78,"context_line":"accept the new instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_bfbc17dc","line":75,"in_reply_to":"3f79a3b5_049b8272","updated":"2018-09-07 19:09:29.000000000","message":"AFAIK, these attributes of an instance (project and user) are already visible to all?\n\nhttps://developer.openstack.org/api-ref/compute/#show-server-details","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"},{"line_number":74,"context_line":"projects. Attempting to change the owning project/user by a non-admin will"},{"line_number":75,"context_line":"result in a ``403 Forbidden`` response."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":78,"context_line":"accept the new instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_3fa327a0","line":75,"in_reply_to":"3f79a3b5_049b8272","updated":"2018-09-07 19:09:51.000000000","message":"These are new parameters in the request, not the response. By default policy only admins would be able to specify them in the request. Non-admin would get a 403 if specifying them.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":72,"context_line":"By default, an admin-only policy will be enforced on this new attribute,"},{"line_number":73,"context_line":"meaning only superuser/admins can transfer the ownership of an instance between"},{"line_number":74,"context_line":"projects. Attempting to change the owning project/user by a non-admin will"},{"line_number":75,"context_line":"result in a ``403 Forbidden`` response."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":78,"context_line":"accept the new instance."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f7d153f9","line":75,"in_reply_to":"3f79a3b5_3fa327a0","updated":"2018-09-07 21:37:41.000000000","message":"Ah, okay, it sounded to me like these were getting added, and made mutable by admins only.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fb18c29b0806c2f8e9ec500efc3edf74f570a5cc","unresolved":false,"context_lines":[{"line_number":77,"context_line":"The target project will have its quota checked to ensure it has enough quota to"},{"line_number":78,"context_line":"accept the new instance."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The target instance\u0027s attached volumes must be transferred to the new target"},{"line_number":81,"context_line":"project separately using the Cinder API\u0027s `volume transfer API`_."},{"line_number":82,"context_line":"Unfortunately, that API involves a multi-step, manual acceptance process and is"},{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_1ec071e0","line":83,"range":{"start_line":80,"start_character":0,"end_line":83,"end_character":71},"updated":"2018-09-11 16:54:36.000000000","message":"Not only that, but you can\u0027t transfer ownership of an in-use (attached) volume:\n\nhttps://github.com/openstack/cinder/blob/c0efaa1d46b762693f8fe3a09d0359ead3e097c4/cinder/transfer/api.py#L121","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_447e5a19","line":86,"updated":"2018-09-07 18:26:31.000000000","message":"So, per my comment above, nova has now transferred ownership of the allocations that cinder may be managing yeah and that will remain out of sync until they complete the cinder-side transfer process yeah?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_bfa177ab","line":86,"in_reply_to":"3f79a3b5_246ebe2b","updated":"2018-09-07 19:09:29.000000000","message":"/me bends the knee\n\nBFV has a place in this world.\n\nOK, now that I\u0027ve said that... I\u0027m going to need to rely on @mriedem and other experts in the BFV operation flows to identify areas where this might be a concern. I just don\u0027t know the intricacies of the BFV code paths unfortunately.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_bfddf714","line":86,"in_reply_to":"3f79a3b5_246ebe2b","updated":"2018-09-07 19:09:51.000000000","message":"Yeah this is what I mentioned earlier, my fear is we\u0027ll fail to detach/delete volumes and ports and such when you even delete the instance.\n\nhttps://review.openstack.org/#/c/599598/3/specs/stein/approved/transfer-instance-ownership.rst@90\n\nIf we\u0027re going with super minimal hook in the API to the nova db and make it very clear that this other side effect stuff can happen if you\u0027re not careful or have a good orchestration system on top, then that\u0027s the deal we\u0027re making.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"03d0a9cd0dc960295d5e97c55564177ef8fe24eb","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8c6326b1","line":86,"in_reply_to":"3f79a3b5_2c053210","updated":"2018-09-09 16:45:30.000000000","message":"More than just delete I would think. Maybe rebuild it?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7c496a2872da0cfd929fa98ef70c65df7269656a","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_246ebe2b","line":86,"in_reply_to":"3f79a3b5_447e5a19","updated":"2018-09-07 18:28:48.000000000","message":"Oh, also... If we switch the instance in nova, and the cinder process hasn\u0027t been completed, presumably we may fail to do a lot of nova operations on BFV instances, such as evacuate, migrate, and maybe even reboot? That seems like bad and stuff.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_7fb2ff07","line":86,"in_reply_to":"3f79a3b5_447e5a19","updated":"2018-09-07 19:09:29.000000000","message":"Yes, I believe that is correct.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"673eafcbadf6cc077c43fe1810dbf9594e48627d","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_330ee9e3","line":86,"in_reply_to":"3f79a3b5_8c6326b1","updated":"2018-09-10 04:53:41.000000000","message":"Yeah you likely lose the root volume during rebuild in that case; I\u0027d expect to see a 404 from cinder when trying to re-attach the root volume to the rebuilt guest.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed870ad9106a368ed8921aebd4d2f9c277d6c08c","unresolved":false,"context_lines":[{"line_number":83,"context_line":"not something that can be done during an instance\u0027s ownership transfer. Some"},{"line_number":84,"context_line":"external orchestration system might be able to coordinate the various manual"},{"line_number":85,"context_line":"processes involved, however, wrapping the ownership transfer of an instance and"},{"line_number":86,"context_line":"its volume(s) in a single operation."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":".. _volume transfer API: https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-transfer-3-55-or-later"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_2c053210","line":86,"in_reply_to":"3f79a3b5_bfddf714","updated":"2018-09-09 15:53:45.000000000","message":"We should be able to tease out some simple flows with this before we go too far down either path. I think it would be pretty clear what happens if you did this in devstack:\n\n1. create a volume-backed (with delete_on_termination\u003dTrue) server with the demo tenant/user\n2. transfer the instance (but not the volume or port) to the alt_demo tenant/user (via direct DB update - might need to first audit what other tables need updating as well, like the instance_mapping?)\n3. have the new owner (alt_demo) delete the server - does it work? I\u0027m assuming best case scenario is the volume and port are orphaned, worst case is we fail to delete the server because we failed to detach/delete the volume since alt_demo doesn\u0027t own it (I think nova-compute might actually just log something and continue in this case though - we\u0027re pretty happy to orphan volumes historically).\n\nhttps://github.com/openstack/nova/blob/c9b7c3577f373477d003706bb5ca748a51bbf023/nova/compute/manager.py#L2503\n\nFor ports, I\u0027m not sure we\u0027ll even log anything. We usually look up ports by device_id (server id) and project_id, so in that case we wouldn\u0027t find the port and just not try to delete it, but we\u0027ll still orphan it.\n\nhttps://github.com/openstack/nova/blob/c9b7c3577f373477d003706bb5ca748a51bbf023/nova/network/neutronv2/api.py#L1499","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_246f9e60","line":92,"updated":"2018-09-07 18:26:31.000000000","message":"What about snapshots in glance? Do they come over with the new instance?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_37234b07","line":92,"in_reply_to":"3f79a3b5_1febcba3","updated":"2018-09-07 21:37:41.000000000","message":"Yeah, I don\u0027t get where the line is. I do think it\u0027d be weird if we make admins change the ownership of the allocations, but I also think it\u0027s weird we\u0027re talking about going forward with this with:\n\n 1. Punt on glance\n 2. Punt on neutron\n 3. Meh, make them do cinder separately BEFORE any other operation happens !!1!\n 4. Oh, definitely do placement things.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_bf8f3721","line":92,"in_reply_to":"3f79a3b5_246f9e60","updated":"2018-09-07 19:09:29.000000000","message":"Hmm. I wouldn\u0027t imagine so, no. This would be something for that external orchestration/coordination script to check on I suppose, before attempting to call Nova to transfer an instance\u0027s ownership.\n\nBasically, have the external script check glance to see if there\u0027s a snapshot of this instance and if so, go ahead and update the user/project of the snapshots as needed (or hell, just bomb out and tell the admin to delete the snapshots or something)","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_1febcba3","line":92,"in_reply_to":"3f79a3b5_246f9e60","updated":"2018-09-07 19:09:51.000000000","message":"I don\u0027t think anything outside of allocations in placement does - which, one could argue, if we were being as minimalist as possible in this spec, we wouldn\u0027t even orchestrate the change of the allocations in placement, the orchestration system would. In other words, why does nova orchestrate the allocations in placement but not volumes/ports/snapshots/etc?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7233acea55c5fe320bc87edbcce1567437465dd9","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_69b8fcc6","line":92,"in_reply_to":"3f79a3b5_37234b07","updated":"2018-09-09 14:43:13.000000000","message":"I\u0027m so frustrated by this type of argument. Would you like me to propose just the placement API-specific changes in a separate repo? If I did that, I have the feeling you\u0027d both still make the argument that Glance and Neutron don\u0027t offer APIs to facilitate ownership transfer so Nova shouldn\u0027t bother either.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"03d0a9cd0dc960295d5e97c55564177ef8fe24eb","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_0ce2b601","line":92,"in_reply_to":"3f79a3b5_69b8fcc6","updated":"2018-09-09 16:45:30.000000000","message":"\u003e I\u0027m so frustrated by this type of argument. Would you like me to\n \u003e propose just the placement API-specific changes in a separate repo?\n \u003e If I did that, I have the feeling you\u0027d both still make the\n \u003e argument that Glance and Neutron don\u0027t offer APIs to facilitate\n \u003e ownership transfer so Nova shouldn\u0027t bother either.\n\nSorry, I\u0027m not trying to be difficult. I\u0027m not trying to eliminate the need for this based on the transient state of other services not having that feature.\n\nNova is different than neutron or glance, IMHO, in that it consumes other services. You can change the ownership of an image in isolation without any problem. However, an instance that has ports, images, volumes, and allocations can\u0027t just change ownership in a vacuum without either breaking links to those other resources, or without having the changes cascade to them. So my point here is just that either this is a \"tool for safer database surgery\" that is orchestrated out-of-band by an admin workflow, or it should be a complete feature that is usable via the API, and doesn\u0027t just re-own one element of a big tree.\n\nI think the admins that are looking for this want it to be a first-class feature that they can expect to use (read: could be a thing horizon can poke). Maybe horizon has to do the workflow part of coordinating this across all the related and affected services, but I kinda doubt that\u0027s going to fly.\n\nSo, I\u0027m just trying to get us to either fall back to the out-of-band \"safer database surgery\" approach, or push us towards something complete. Implementing change of ownership in cinder and nova (which work in very different ways) with no support for it in glance, neutron, etc does not seem like it gets us to a solution.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c556df557fbf63fc210d6141d29b41da1f4ec675","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"There does not seem to be a way to transfer the ownership of associated ports"},{"line_number":91,"context_line":"in Neutron\u0027s API. Doing this ownership transfer must be done as a manual"},{"line_number":92,"context_line":"exercise by the operator against the Neutron database."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Alternatives"},{"line_number":95,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ac186275","line":92,"in_reply_to":"3f79a3b5_69b8fcc6","updated":"2018-09-09 16:06:54.000000000","message":"I was just asking a question, because as I\u0027ve said before, I expect it will be used as an argument against us later for needing to fully orchestrate the other resource transfer *within* nova because people will say, \"nova is already doing this thing and knows about the other stuff, and it\u0027s doing it for the placement resources, I don\u0027t want to write a new service, blah blah blah\". Whether we go forward or not, whatever, my product people want this too, and I know it\u0027s been a request for a long time (per the old IBM spec that CERN was also interested in). I just want to make sure we\u0027re aware that this opens a door and we should be prepared for the later requests to build on top of this.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"feba54297932050bd7f09cbfed0634428755ad4f","unresolved":false,"context_lines":[{"line_number":129,"context_line":"request payload. The author of this proposal feels that using the existing"},{"line_number":130,"context_line":"``PUT /allocations/{consumer_id}`` endpoint and changing the behaviour of the"},{"line_number":131,"context_line":"server is neither a clean nor simple approach, and that having a real"},{"line_number":132,"context_line":"``/consumers`` endpoint for the consumer object/concept is more appropriate."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"Data model impact"},{"line_number":135,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a2351ef9","line":132,"updated":"2018-09-05 11:13:44.000000000","message":"This paragraph isn\u0027t really true. PUT /allocations already has desired functionality (see https://github.com/cdent/placecat/blob/master/gabbits/projectchange.yaml ). No change on the server required (assuming that gabbit is correct).\n\nAlso, given that we would need to GET /allocations/{consumer_id} to get the generation (unless we also added a GET /consumers/{consumer_id} ) we already have all the data necessary to modify that state, and PUT it back to the same URL.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"8884e7d2ee6e8d228f9ce578ec9f58ca8a23e5ea","unresolved":false,"context_lines":[{"line_number":129,"context_line":"request payload. The author of this proposal feels that using the existing"},{"line_number":130,"context_line":"``PUT /allocations/{consumer_id}`` endpoint and changing the behaviour of the"},{"line_number":131,"context_line":"server is neither a clean nor simple approach, and that having a real"},{"line_number":132,"context_line":"``/consumers`` endpoint for the consumer object/concept is more appropriate."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"Data model impact"},{"line_number":135,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4f4c7275","line":132,"in_reply_to":"3f79a3b5_a2351ef9","updated":"2018-09-05 12:19:35.000000000","message":"I should have written \"changing a consumer\u0027s project and/or user using PUT /allocations/{consumer_uuid} is overkill since it will end up deleting all of the  consumer\u0027s allocations, and re-adding all of the existing allocations unnecessarily.\"\n\nThis goes back to the fact that the concept we\u0027re attempting to change here is the consumer, not the allocation. Thus the reason I\u0027ve wanted to add a consumer endpoint and manage this information outside of the allocations round-hole that we are currently constrained to.\n\nWhile I understand and appreciate the desire to keep the placement API minimal, having a consumers endpoint that matches the concept of an actual consumer, versus an allocation, is just the most natural way of describing and manipulating this data.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e4e0c6ce","line":139,"updated":"2018-09-07 18:26:31.000000000","message":"You also need to for sure update the instance mapping in the api database. I count 15 tables in the main database and 9 in the api database that have a project_id column. Presumably all of those need to be surveyed and potentially updated?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"03d0a9cd0dc960295d5e97c55564177ef8fe24eb","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_0ccb9671","line":139,"in_reply_to":"3f79a3b5_29ae8480","updated":"2018-09-09 16:45:30.000000000","message":"\u003e \u003e Not just the api db, but the main one too. And it\u0027s not just\n \u003e \u003e multiple, it\u0027s 24. That\u0027s a lot of stuff to patch up :)\n \u003e \n \u003e It\u0027s not 24 things that refer to the *instance\u0027s project ID or user\n \u003e ID*. Are you just counting any occurrence of \"project_id\" in the DB\n \u003e models?\n \u003e \n \u003e I just checked and there are no references to instances.project_id\n \u003e in any cell DB table that aren\u0027t deprecated (nova-network tables).\n \u003e \n \u003e InstanceGroup.project_id would need to be verified but that table\n \u003e is not in the API DB.\n \u003e \n \u003e InstanceMapping.project_id in the API db would also need to be\n \u003e checked.\n \u003e \n \u003e That\u0027s it.\n\nSure, a bunch of nova-network stuff does, but there are still some people using that (like CERN). What happens if you re-own an instance that has fixed/floating IPs with nova-network and you don\u0027t update all the associated resources? I mean, I guess we could just punt on that and say that we can\u0027t do those, but we should probably call it out here (or somewhere) and make sure we fail gracefully (as much as is possible) for those until the code is fully removed.\n\nBut things like InstanceAction has a project/user stored as a column, and unless you\u0027re going to orphan those forever and break the history of an instance that gets transferred, you need to update those too. And yeah, several things in the API database as noted.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c556df557fbf63fc210d6141d29b41da1f4ec675","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8c50060c","line":139,"in_reply_to":"3f79a3b5_29ae8480","updated":"2018-09-09 16:06:54.000000000","message":"InstanceGroup.project_id is in the API DB:\n\nhttps://github.com/openstack/nova/blob/c9b7c3577f373477d003706bb5ca748a51bbf023/nova/db/sqlalchemy/api_models.py#L441\n\nInstance groups were migrated out of the cell DBs and into the API DB.\n\nServer groups definitely get weird when it comes to the quota check, because the server group has a project_id/user_id on it but the quota is based on the user_id and members:\n\nhttps://github.com/openstack/nova/blob/c9b7c3577f373477d003706bb5ca748a51bbf023/nova/quota.py#L1266\n\nWe should probably talk to Mel about this, because does this mean that we can potentially need to re-calculate group membership rules if we\u0027re transferring ownership of a server that\u0027s a member of a group? Not just quota, but like affinity rules - if I created 2 members of a strict affinity group for project/user A and then transferred one of the members to project/user B, does that violate the affinity group policy even though the servers don\u0027t move hosts?\n\nI know you don\u0027t like server groups, but it\u0027s a thing we accepted a long time ago (like BFV) so we have to deal with it, which harks back to my point above about if we accept this, it\u0027s a wrinkle we need to support throughout the API and be aware of - it\u0027s more than just trivially updating a couple of fields in the DB because of related gorp.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"03d0a9cd0dc960295d5e97c55564177ef8fe24eb","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8cbfa6ce","line":139,"in_reply_to":"3f79a3b5_8c50060c","updated":"2018-09-09 16:45:30.000000000","message":"Presumably you can\u0027t change ownership of an instance that is in a group right? You\u0027re not going to move all the members at once (right?) and having a group that references members from different tenants is going to break much of the functionality that considers groups, AFAIK.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f76dd32e","line":139,"in_reply_to":"3f79a3b5_bf065785","updated":"2018-09-07 21:37:41.000000000","message":"Not just the api db, but the main one too. And it\u0027s not just multiple, it\u0027s 24. That\u0027s a lot of stuff to patch up :)","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_bf065785","line":139,"in_reply_to":"3f79a3b5_e4e0c6ce","updated":"2018-09-07 19:09:29.000000000","message":"Yep, good points. I\u0027ll have to audit the API DB tables and make sure I list the ones that might be affected.\n\nThough I will say that having multiple tables with project_id columns is a bit worrying in general since that\u0027s indicating we\u0027re denormalizing for some reason. Anyway, I\u0027ll check it out.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7233acea55c5fe320bc87edbcce1567437465dd9","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There are no changes to the data model. We will continue to use the"},{"line_number":138,"context_line":"``instances.project_id`` and ``instances.user_id`` fields to store the \"owning"},{"line_number":139,"context_line":"project\" and \"owning user\" of the instance."},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"REST API impact"},{"line_number":142,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_29ae8480","line":139,"in_reply_to":"3f79a3b5_f76dd32e","updated":"2018-09-09 14:43:13.000000000","message":"\u003e Not just the api db, but the main one too. And it\u0027s not just\n \u003e multiple, it\u0027s 24. That\u0027s a lot of stuff to patch up :)\n\nIt\u0027s not 24 things that refer to the *instance\u0027s project ID or user ID*. Are you just counting any occurrence of \"project_id\" in the DB models?\n\nI just checked and there are no references to instances.project_id in any cell DB table that aren\u0027t deprecated (nova-network tables).\n\nInstanceGroup.project_id would need to be verified but that table is not in the API DB.\n\nInstanceMapping.project_id in the API db would also need to be checked.\n\nThat\u0027s it.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":198,"context_line":"---------------"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Keeping this functionality an admin-only operation should solve most"},{"line_number":201,"context_line":"security-related concerns."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Notifications impact"},{"line_number":204,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_24eb1ea4","line":201,"updated":"2018-09-07 18:26:31.000000000","message":"Except that if we ignore glance snapshots (as seems to be done above) you may continue to expose sensitive information in those snapshots to a project for which you\u0027ve transferred away the actual instance.\n\nAnd presumably as soon as you transfer an instance to a new project, but haven\u0027t updated the neutron information, the new project may be able to communicate with things on the old project\u0027s networks, bridging those security domains. Yes, the admin is responsible for that, but with zero way to do that on the neutron side, I think that\u0027s a potential security issue worth documenting (both here and in the caveats section of the docs on how to us this thing).","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"47cb17f6ccd7bdf5f8611d6b1d29b9c52c7aa65e","unresolved":false,"context_lines":[{"line_number":198,"context_line":"---------------"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Keeping this functionality an admin-only operation should solve most"},{"line_number":201,"context_line":"security-related concerns."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Notifications impact"},{"line_number":204,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_df1793a2","line":201,"in_reply_to":"3f79a3b5_24eb1ea4","updated":"2018-09-07 19:09:29.000000000","message":"I can add some words that transferring ownership of resources has security implications, but I would hope that is pretty well understood. In either case, I\u0027ll add something.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c556df557fbf63fc210d6141d29b41da1f4ec675","unresolved":false,"context_lines":[{"line_number":198,"context_line":"---------------"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Keeping this functionality an admin-only operation should solve most"},{"line_number":201,"context_line":"security-related concerns."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Notifications impact"},{"line_number":204,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6c76caa6","line":201,"in_reply_to":"3f79a3b5_57584788","updated":"2018-09-09 16:06:54.000000000","message":"At times like these it would be nice to punt and say we have an experimental version of the API like some other projects have done in the past (I think at least cinder and keystone).","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39b5816f4693bf61819b951db72813e16026a277","unresolved":false,"context_lines":[{"line_number":198,"context_line":"---------------"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Keeping this functionality an admin-only operation should solve most"},{"line_number":201,"context_line":"security-related concerns."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"Notifications impact"},{"line_number":204,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_57584788","line":201,"in_reply_to":"3f79a3b5_df1793a2","updated":"2018-09-07 21:37:41.000000000","message":"Well, saying \"None\" here (effectively) implies none, not \"None, other than the obvious ones the reader should know about.\" :)","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aadfd0a01d4ca9531c886c8ffeb2b9daa58efba4","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Other end user impact"},{"line_number":210,"context_line":"---------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"None"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Performance Impact"},{"line_number":215,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6764d1b9","line":212,"updated":"2018-09-06 17:58:48.000000000","message":"One thing I\u0027ve recently thought about with this, which reminds me of some other specs that have proposed changing things on the instance (in the DB) via PUT /servers/{server_id} which is config drive. If you\u0027re using the metadata service, and the project_id on the instance changes, are you going to be able to pull from the metadata API? Let\u0027s assume you can. But if you\u0027re not using the metadata API, and just rely on config drive, does this cause any issues? In other words, should we do this in the rebuild API instead or at least in addition to the update API so that the user with a guest that\u0027s using config drive (with the old project_id) has a chance to get a new config drive with the new project_id in it? I know for the most part we just tell people config drive is static and not relevant after first boot (and some images disable/remove cloud-init after boot), but I want to make sure we\u0027re not missing something here because the project_id is in the metadata / config drive so that\u0027s something users/guests need to be aware of - that it could change, and if it does, can they deal with it properly, i.e. do they need to re-register the guest in some internal system?","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c91458b1e9c2e3735aad766e792e1d11a41c867","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Other end user impact"},{"line_number":210,"context_line":"---------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"None"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Performance Impact"},{"line_number":215,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_843d528f","line":212,"in_reply_to":"3f79a3b5_07af1d7d","updated":"2018-09-07 18:26:31.000000000","message":"I\u0027m not sure why the instance wouldn\u0027t be able to pull from the metadata API after such a change. Are you concerned about it noticing that the project has changed in said metadata, or about it not working at all?\n\nAnd about configdrive, the contents won\u0027t be updated (per usual as you said) but I\u0027m not sure what else would be problematic there.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0bd55091abe6ca806c0a58b171bb0c3abacbe985","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Other end user impact"},{"line_number":210,"context_line":"---------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"None"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Performance Impact"},{"line_number":215,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_07af1d7d","line":212,"in_reply_to":"3f79a3b5_6764d1b9","updated":"2018-09-06 18:15:02.000000000","message":"This is the other spec I was thinking of:\n\nhttps://review.openstack.org/#/c/547964/","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2d7eaffa6aca4e99d6d77aeb4bd413c8750bc702","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Other end user impact"},{"line_number":210,"context_line":"---------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"None"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"Performance Impact"},{"line_number":215,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_7f7f5fde","line":212,"in_reply_to":"3f79a3b5_843d528f","updated":"2018-09-07 19:09:51.000000000","message":"\u003e Are you concerned about it noticing that the project has changed in said metadata, or about it not working at all?\n\nPrimarily the former, I\u0027m not sure what \"it\" is in the latter - the guest or the metadata API? I\u0027m mostly concerned about guests that do thing with internal systems based on the project_id which could then change underneath them and they have to figure out how to handle that.","commit_id":"dff081fb7d56f201398186c7261be46d4245c109"}]}