)]}'
{"specs/queens/approved/migration-allocations.rst":[{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7df6cd9444d4af9d85e09e780b78754f455bee50","unresolved":false,"context_lines":[{"line_number":184,"context_line":"References"},{"line_number":185,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"See the mess in pike."},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"History"},{"line_number":190,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f287b81_02963e94","line":187,"range":{"start_line":187,"start_character":0,"end_line":187,"end_character":21},"updated":"2017-08-28 16:07:07.000000000","message":"Heh","commit_id":"d7383d10c2734e7af534155609b329fbc6365cd6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Migration Allocations"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"https://blueprints.launchpad.net/nova/+spec/migration-allocations"},{"line_number":14,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_4bd55d43","line":11,"range":{"start_line":11,"start_character":0,"end_line":11,"end_character":44},"updated":"2017-08-29 21:27:39.000000000","message":"remove the template text","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":24,"context_line":"scenarios. Things are further complicated by the potential for"},{"line_number":25,"context_line":"same-host migrations."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The problem we have is that currently the scheduler must know that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_6bfc99b4","line":27,"updated":"2017-08-29 21:27:39.000000000","message":"Another problem, which isn\u0027t a real world problem yet, is that if we have the quota code use the placement usages API to calculate instance usage for vcpus/ram/disk_gb across cells, we\u0027d be double accounting quota usage for an instance while it\u0027s moving since it has allocations on both the source and destination node.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d092e50062c5a733d25761f66cd66d3aaf89a73f","unresolved":false,"context_lines":[{"line_number":24,"context_line":"scenarios. Things are further complicated by the potential for"},{"line_number":25,"context_line":"same-host migrations."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The problem we have is that currently the scheduler must know that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_538fba22","line":27,"in_reply_to":"7f287b81_5f53c6e2","updated":"2017-09-05 20:31:28.000000000","message":"OK, we need to be clear about this behavior change somewhere somehow then, because today during a resize we just count quota against the upsize values of the two flavors, we don\u0027t sum them and count that against your quota limit.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b07b7ad2d120f58e3dbf6ece6954974709ebfe9c","unresolved":false,"context_lines":[{"line_number":24,"context_line":"scenarios. Things are further complicated by the potential for"},{"line_number":25,"context_line":"same-host migrations."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The problem we have is that currently the scheduler must know that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_5f53c6e2","line":27,"in_reply_to":"7f287b81_6bfc99b4","updated":"2017-08-30 14:33:37.000000000","message":"I\u0027m not sure that would be any different here. In placement we don\u0027t know what the type of consumer is, just that there is a consumer. Unless we were to create the migration\u0027s allocation with a different user/project than the instance, then it would still count against their quota. I also don\u0027t think this is bad, since you want to prevent people from leaving a bunch of instances in resize_confirm state since they _are_ taking up double the space.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":43,"context_line":"instances are moving."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"As a nova developer, I want a clear assignment of responsibilities for"},{"line_number":46,"context_line":"each allocation in placement so that the code to allocate an"},{"line_number":47,"context_line":"deallocate for an instance is simple and straightforward."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_4b631db3","line":46,"range":{"start_line":46,"start_character":58,"end_line":46,"end_character":60},"updated":"2017-08-29 21:27:39.000000000","message":"and","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":73,"context_line":"instance, and then having to subtract the source node/flavor from that"},{"line_number":74,"context_line":"allocation on success, we can simply operate on allocations atomically"},{"line_number":75,"context_line":"(i.e. create/delete) as the design intends. This makes the math and"},{"line_number":76,"context_line":"mechanics the same for single and multi-host move operations, and"},{"line_number":77,"context_line":"avoids one compute node manipulating allocations against another."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_eb15294a","line":76,"range":{"start_line":76,"start_character":23,"end_line":76,"end_character":29},"updated":"2017-08-29 21:27:39.000000000","message":"During a resize to same host, today we sum the allocations on the node for the old and new flavor, which is why we have the new \"oh now I\u0027m charged for 2 VCPUs when really I\u0027m only using 1\" issue.\n\nWith this proposal, would we still have that? Or would the migration consume the old flavor allocation and the instance would consume the new flavor allocation against the same node?\n\nGoing back to the quota usage check thing, during resize we only check quota if the flavor is being \"up-sized\", which makes sense. So if we resize to the same host and the migration gets the old flavor allocation and the instance gets the new flavor allocation, and we use the placement usages API for the instance quota usage, things would be wrong for a bit if the new flavor is actually a downsize in something like vcpu or ram.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b07b7ad2d120f58e3dbf6ece6954974709ebfe9c","unresolved":false,"context_lines":[{"line_number":73,"context_line":"instance, and then having to subtract the source node/flavor from that"},{"line_number":74,"context_line":"allocation on success, we can simply operate on allocations atomically"},{"line_number":75,"context_line":"(i.e. create/delete) as the design intends. This makes the math and"},{"line_number":76,"context_line":"mechanics the same for single and multi-host move operations, and"},{"line_number":77,"context_line":"avoids one compute node manipulating allocations against another."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_faa600c1","line":76,"range":{"start_line":76,"start_character":23,"end_line":76,"end_character":29},"in_reply_to":"7f287b81_eb15294a","updated":"2017-08-30 14:33:37.000000000","message":"Right, this will fix the max_unit thing because that restriction applies to any single allocation. With what we have now, we just have to inflate the size of your one allocation to include the sum, which is where we run afoul of that limit. With the migration owning the old allocation, one instance will own two allocations, each below the limit, although the migration is technically holding one of them for it (like escrow).","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":75,"context_line":"(i.e. create/delete) as the design intends. This makes the math and"},{"line_number":76,"context_line":"mechanics the same for single and multi-host move operations, and"},{"line_number":77,"context_line":"avoids one compute node manipulating allocations against another."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_dd76b470","line":78,"updated":"2017-08-29 21:27:39.000000000","message":"What are you thinking about allocations against a shared provider, like a shared storage pool? Today we\u0027ll double those up, but now would we just have the migration allocated against the shared storage pool and the instance, or one over the other (like maybe just the instance?), other?","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b07b7ad2d120f58e3dbf6ece6954974709ebfe9c","unresolved":false,"context_lines":[{"line_number":75,"context_line":"(i.e. create/delete) as the design intends. This makes the math and"},{"line_number":76,"context_line":"mechanics the same for single and multi-host move operations, and"},{"line_number":77,"context_line":"avoids one compute node manipulating allocations against another."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"Alternatives"},{"line_number":80,"context_line":"------------"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_1a92ec4c","line":78,"in_reply_to":"7f287b81_dd76b470","updated":"2017-08-30 14:33:37.000000000","message":"It\u0027s going to get a little sticky, but we could do a number of things. For the moment, I\u0027m just going to effectively change the owner on the current allocation from the instance to the migration.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":96,"context_line":"REST API impact"},{"line_number":97,"context_line":"---------------"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"No direct API impact"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Security impact"},{"line_number":102,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_fd585031","line":99,"range":{"start_line":99,"start_character":0,"end_line":99,"end_character":20},"updated":"2017-08-29 21:27:39.000000000","message":"Don\u0027t we need some kind of atomic swap change to the Placement API for this so that we can update allocations on a given resource provider to switch from the instance allocation consumer to the migration allocation consumer on the source node?\n\nThere is no PUT operation on /resource_providers/rp_uuid/allocations:\n\nhttps://developer.openstack.org/api-ref/placement/#resource-provider-allocations\n\nAnd PUT /allocations/consumer_uuid would be separate non-atomic calls.\n\n----\n\nUnrelated, but I think another thing we\u0027d want here is to expose the migration UUID out of the compute REST API, which is I guess this at this point, which sucks:\n\nhttps://developer.openstack.org/api-ref/compute/#id318\n\nThe reason that sucks is it only shows *in-progress live migrations* for a given instance.\n\nWe have this other generic os-migrations API which shows all migrations, in-progress or not, and regardless of being live migrations:\n\nhttps://developer.openstack.org/api-ref/compute/#migrations-os-migrations-frozen\n\nBut that was marked \"frozen\" when the \u0027cancel live migration\u0027 stuff happened and GET /servers/server_id/migrations API was added. I think that\u0027s a mess:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2017-April/115494.html\n\nAnyway, point is, I think we\u0027ll want to be able to get the migration uuid out of the API so we can use those to look up allocation/usage information in placement, if we need that at some point. I guess it could be a separate spec if we wanted, but seems like something we always want in the API after the fact (the uuid being exposed that is), especially with multi-cell.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d092e50062c5a733d25761f66cd66d3aaf89a73f","unresolved":false,"context_lines":[{"line_number":96,"context_line":"REST API impact"},{"line_number":97,"context_line":"---------------"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"No direct API impact"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Security impact"},{"line_number":102,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_d33e0a28","line":99,"range":{"start_line":99,"start_character":0,"end_line":99,"end_character":20},"in_reply_to":"7f287b81_7ace905a","updated":"2017-09-05 20:31:28.000000000","message":"\u003e I figured we\u0027d do another spec for that specifically, which cdent just signed up for. So when that is posted I can put it in the deps below.\n\nhttps://review.openstack.org/#/c/499259/\n\n\u003e Since only admins can query placement I\u0027m not sure normal users would be able to do anything with the uuid.\n\nI don\u0027t think it matters if it\u0027s end users or admins, it\u0027s a user of the REST API, and they\u0027ll likely want to be able to correlate resources by UUID between compute and placement REST APIs at some point - by default that would just be the admin user. I don\u0027t have a specific use case in mind, but it\u0027s one of those REST API things that we\u0027ll wish we had later probably.\n\n\u003e If we\u0027re going to, surely that should be its own API spec and a dependency here right?\n\nIt could be. That would help with granularity of efforts at least.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b07b7ad2d120f58e3dbf6ece6954974709ebfe9c","unresolved":false,"context_lines":[{"line_number":96,"context_line":"REST API impact"},{"line_number":97,"context_line":"---------------"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"No direct API impact"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Security impact"},{"line_number":102,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_7ace905a","line":99,"range":{"start_line":99,"start_character":0,"end_line":99,"end_character":20},"in_reply_to":"7f287b81_fd585031","updated":"2017-08-30 14:33:37.000000000","message":"I don\u0027t _have_ to have the atomic operation to do this, but it would be nice. I figured we\u0027d do another spec for that specifically, which cdent just signed up for. So when that is posted I can put it in the deps below.\n\nI guess exposing the migration uuid is useful, although only admins can see anything about migrations anyway by default. Since only admins can query placement I\u0027m not sure normal users would be able to do anything with the uuid.\n\nIf we\u0027re going to, surely that should be its own API spec and a dependency here right?","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31211d1551d56aacfb0a44c1f9399a4f39a59b56","unresolved":false,"context_lines":[{"line_number":178,"context_line":"Documentation Impact"},{"line_number":179,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"Since this should ideally be invisible from the outside, no"},{"line_number":182,"context_line":"documentation impact is expected."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"References"},{"line_number":185,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_7dfc60b4","line":182,"range":{"start_line":181,"start_character":0,"end_line":182,"end_character":33},"updated":"2017-08-29 21:27:39.000000000","message":"Unless we update the API reference for placement and/or compute.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b07b7ad2d120f58e3dbf6ece6954974709ebfe9c","unresolved":false,"context_lines":[{"line_number":178,"context_line":"Documentation Impact"},{"line_number":179,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"Since this should ideally be invisible from the outside, no"},{"line_number":182,"context_line":"documentation impact is expected."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"References"},{"line_number":185,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_1a09cc94","line":182,"range":{"start_line":181,"start_character":0,"end_line":182,"end_character":33},"in_reply_to":"7f287b81_7dfc60b4","updated":"2017-08-30 14:33:37.000000000","message":"Yeah, but as above, I would expect each of those efforts to have their own spec to call this out.","commit_id":"c73533c68fc34b21e7a315ad966b25ac5ff8a66c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7b2946f51285fa55f32879a181abbdfe921b5775","unresolved":false,"context_lines":[{"line_number":84,"context_line":"will end up with the migration owning the original allocation and the"},{"line_number":85,"context_line":"instance owning the new one, which will work because they are separate"},{"line_number":86,"context_line":"allocations."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Alternatives"},{"line_number":89,"context_line":"------------"},{"line_number":90,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_73a63656","line":87,"updated":"2017-09-05 20:37:37.000000000","message":"It would be good to describe any thoughts about tracking migrations with shared resource providers, but since that\u0027s not something we support today anyway, and probably deserves it\u0027s own spec to think about, it\u0027s probably OK to omit it here.","commit_id":"82ca0ad214c574b01535dd93e72662489a2304a9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7b2946f51285fa55f32879a181abbdfe921b5775","unresolved":false,"context_lines":[{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"* To optimize our behavior, we need an additional API in placement to"},{"line_number":174,"context_line":"  allow us to submit multiple allocations for different consumers in a"},{"line_number":175,"context_line":"  single atomic operation."},{"line_number":176,"context_line":"* Ideally we would expose the migration uuid from the os-migrations"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_13ea5274","line":173,"updated":"2017-09-05 20:37:37.000000000","message":"Link to https://blueprints.launchpad.net/nova/+spec/post-allocations","commit_id":"82ca0ad214c574b01535dd93e72662489a2304a9"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"82ff6e12fd8736ce17fce965fc55a1a5278238aa","unresolved":false,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":"As a nova developer, I want a clear assignment of responsibilities for"},{"line_number":44,"context_line":"each allocation in placement so that the code to allocate and"},{"line_number":45,"context_line":"deallocate for an instance is simple and straightforward."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Proposed change"},{"line_number":48,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f287b81_42ab4d1c","line":45,"updated":"2017-09-06 17:50:37.000000000","message":"Amen.","commit_id":"394ea9a695f750581e21c2ac4629fa7746231969"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"82ff6e12fd8736ce17fce965fc55a1a5278238aa","unresolved":false,"context_lines":[{"line_number":165,"context_line":"* Make the compute node code able to handle either the doubled"},{"line_number":166,"context_line":"  allocation strategy (pike) or the split allocation strategy (queens)"},{"line_number":167,"context_line":"* Make the scheduler create allocations using either strategy,"},{"line_number":168,"context_line":"  determined by whether or not there are pike nodes in the deployment"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Dependencies"},{"line_number":171,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7f287b81_81892ccb","line":168,"updated":"2017-09-06 17:50:37.000000000","message":"Nothing major, just a quick note here for posterity\u0027s sake that we now have a user and project associated with consumers in the placement database. So, when constructing the PUT /allocations/{migration_uuid} call, we should remember to add the user and project like we do for instances...","commit_id":"394ea9a695f750581e21c2ac4629fa7746231969"}]}