)]}'
{"specs/pike/approved/remove-device-from-bdm-post-requests.rst":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"19e2886dfc0b48756572bbbcc8e771076e3c9cf1","unresolved":false,"context_lines":[{"line_number":31,"context_line":"backend compute driver / hypervisor layer and is better to remove it from the"},{"line_number":32,"context_line":"API. In fact, the Libvirt compute driver stopped honoring the user-supplied"},{"line_number":33,"context_line":"device name altogether in the 12.0.0 Liberty release [1]_."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"---------"},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_3f096694","line":34,"updated":"2018-03-21 19:11:15.000000000","message":"We also have device tags in the API now so if the user was using a device name to try and correlate that to what would show up in the guest, device tags are a much better way to do that now.","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"},{"author":{"_account_id":10224,"name":"Feodor Tersin","email":"ftersin@hotmail.com","username":"ftersin"},"change_message_id":"df8d0bf4aa5ec56d6718152c7c4c1ce57b55b65f","unresolved":false,"context_lines":[{"line_number":41,"context_line":"As a user, I want to attach an existing volume to an existing server, which may"},{"line_number":42,"context_line":"or may not already have other attached volumes, and trust the compute service"},{"line_number":43,"context_line":"to attach the volume correctly."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfeb2761_e87b83bb","line":44,"updated":"2017-04-02 17:05:31.000000000","message":"Also as a user, I\u0027d want to adjust volume settings, booting an instance from volume backed image, which contains several bdms.\n\nE.g. the image\u0027s bdms are: vda, 100 Gb, snap1; vdb, 200 Gb, snap2; vdc, 100 Gb, ephemeral. I want to run an instance on increased root disk, w/o vdb though. I.e. i want to have: vda, 500 Gb, snap1; vdc (in fact becomes vdb, but no matter), 100 Gb, ephemeral.","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"},{"author":{"_account_id":10224,"name":"Feodor Tersin","email":"ftersin@hotmail.com","username":"ftersin"},"change_message_id":"68a58ea735cb59033ed570d2d89ac7073ddd4f6d","unresolved":false,"context_lines":[{"line_number":41,"context_line":"As a user, I want to attach an existing volume to an existing server, which may"},{"line_number":42,"context_line":"or may not already have other attached volumes, and trust the compute service"},{"line_number":43,"context_line":"to attach the volume correctly."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfeb2761_c2089bda","line":44,"in_reply_to":"dfeb2761_4edb97ec","updated":"2017-04-03 01:41:11.000000000","message":"At the moment we have a test for that in EC2 API project. Since you\u0027re going to change the behavior, it makes no sense to write the test for Nova right now, but when the new behavior is implemented only.\n\nRight, w/o bdm id all such workarounds do not look complete, but a bit complex. Since in EC2 API we already parse image bdms and merge them with user specified parameters (if they are specified), it\u0027d look consistent to add something like \u0027ignore_image_bdms\u0027 parameter to run instance method, as i mentioned in ML.\n\nAlthough the best solution for me is to support real merging of bdms and other options which AWS and GCE support (e.g. defining volume types). As i concluded reading of users feedbacks, they see that volume backed instances are not seamless supported in Nova, and they dislike to do manual orchestration for that, and therefore dislike to use volume backed instances in favor of disk based ones. Because that they request for developing of new ephemeral backends to simplify their work with enterprise disk arrays. But disk based image do not support bdms, so in this case (if that Cinder ephemeral backend is implemented) Nova will stay worse than AWS and GCE, providing more poor features for volume backed instances.\n\nBut anyway, since \u0027no more orchestration\u0027 rule is actual, that solution has no chances.","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"},{"author":{"_account_id":10224,"name":"Feodor Tersin","email":"ftersin@hotmail.com","username":"ftersin"},"change_message_id":"bf3863f5a4dbcbf3289898d74a16597cb5948abc","unresolved":false,"context_lines":[{"line_number":41,"context_line":"As a user, I want to attach an existing volume to an existing server, which may"},{"line_number":42,"context_line":"or may not already have other attached volumes, and trust the compute service"},{"line_number":43,"context_line":"to attach the volume correctly."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfeb2761_9cd8661e","line":44,"in_reply_to":"dfeb2761_b5725ce2","updated":"2017-04-05 02:48:27.000000000","message":"Well, i\u0027m not against the Tempest test, if you have resources for that.\n\nSorry for the mess with names, i definitely mean create server operation of Nova API (POST onto /servers). So that ignore_image_bdms parameter might mean - run an instance from an image (using the image\u0027s metadata), ignoring image bdms, but using user specified only. Nothing specific for ec2api, right?\n\nThe main bad effect of this - a user may substitute root volume at all, i.e. use another snapshot, etc. This may confuse users and admin. To prevent this a check might be added to verify that root volume of user specified bdms is based on the same source (mainly snapshot). Then the parameter name might be \u0027substitute_image_bdms\u0027, because with that check Nova did not completely ignore image bdms.","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"639cbec1805e92ac0594224bd96662665f982817","unresolved":false,"context_lines":[{"line_number":41,"context_line":"As a user, I want to attach an existing volume to an existing server, which may"},{"line_number":42,"context_line":"or may not already have other attached volumes, and trust the compute service"},{"line_number":43,"context_line":"to attach the volume correctly."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfeb2761_b5725ce2","line":44,"in_reply_to":"dfeb2761_c2089bda","updated":"2017-04-03 16:14:27.000000000","message":"\u003e Since you\u0027re going to change the behavior, it makes no sense to write the test for Nova right now, but when the new behavior is implemented only.\n\nThere is still a point in writing a Tempest test to ensure the API behavior you want isn\u0027t regressed, as you said it was long ago and fixed by ndipanov. Any new behavior would be dependent on a microversion so the user has to opt into that new behavior.\n\n\u003e Since in EC2 API we already parse image bdms and merge them with user specified parameters (if they are specified), it\u0027d look consistent to add something like \u0027ignore_image_bdms\u0027 parameter to run instance method, as i mentioned in ML.\n\nI\u0027m not really following you here or the idea. Are you asking for ignore_image_bdms added to one of the internal nova.compute.api.API methods? I think run_instance is an ec2api specific method. And if I\u0027m following, you\u0027re proposing that we just provide that as a way for the ec2api code to tell the compute API code to ignore any bdms defined in the image metadata because the ec2api code has already merged the image-defined bdms and the user-supplied bdms? If that\u0027s correct, then it\u0027s still bad because it\u0027s an ec2api only solution. Maybe that\u0027s the point?","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2a7a9d9f7bfc8a62aab075c2bf3f997aa5b787d2","unresolved":false,"context_lines":[{"line_number":41,"context_line":"As a user, I want to attach an existing volume to an existing server, which may"},{"line_number":42,"context_line":"or may not already have other attached volumes, and trust the compute service"},{"line_number":43,"context_line":"to attach the volume correctly."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfeb2761_4edb97ec","line":44,"in_reply_to":"dfeb2761_e87b83bb","updated":"2017-04-03 00:08:29.000000000","message":"Thanks for the info Feodor. I also replied to this same thing in the mailing list:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2017-April/114863.html\n\nYou\u0027ve now provided the example so that\u0027s helpful.\n\nAs noted in the mailing list, this isn\u0027t documented or tested behavior anywhere in Tempest that I know of. I had no idea people did this, but looking through some legacy BDMv1 code it looks like it\u0027s there for EC2 compatibility from the old old days. If you/we actually care about this scenario, we should have a Tempest test that verifies it works before we move further with this.\n\nI think we should think about how we can make this straight-forward in the API, rather than rely on a hack in the data model (as noted in the ML). I was thinking something like adding an \u0027image_override\u003dTrue\u0027 field to the block_device_mapping_v2 field which would be used to correlate and override the value of a provided BDM with the one in the image metadata. The tricky part, since we don\u0027t have unique IDs on the BDMs besides the device name, is how do you correlate without specifying a device name - which gets us into a chicken-and-egg scenario where we don\u0027t want the device_name, but kind of need it for this override situation.\n\nWhat if we started exposing uuids for BDMs first, and then dropped device name from the POST APIs? We could then use the uuid to correlate the requested BDM with the one in the image metadata. However, that doesn\u0027t work for old already-attached BDMs and old image metadata...\n\nWe could allow device_name iff image_override\u003dTrue, or just change behavior to say that device_name now means explicit image BDM override, otherwise it\u0027s a 400, and only works if there is a BDM in the image meta that matches that device name. That seems a bit clunky to me though and confusing for people that are used to the current meaning of the device_name field in the request.","commit_id":"f5e424478c8bfa410274f0556926a1aa45a97d55"}],"specs/rocky/approved/remove-device-from-volume-attach-requests.rst":[{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"15a58f591278d0efed2b864561d2880481ed9ddd","unresolved":false,"context_lines":[{"line_number":65,"context_line":"have other attached volumes, and trust the compute service to attach the volume"},{"line_number":66,"context_line":"correctly."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As a user, I want to be able to see the tags set on virtual devices for a"},{"line_number":69,"context_line":"given server."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Proposed change"},{"line_number":72,"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":2,"id":"5f7c97a3_5720d99b","line":69,"range":{"start_line":68,"start_character":0,"end_line":69,"end_character":13},"updated":"2018-06-07 05:24:40.000000000","message":"my understand for tag is something like a label or metadata so we can retrieve or search based on it \n\nthe tag will be something like /dev/vdx as we did before for device? who is going to honor the tag or it\u0027s just something we want to let operator know this is \u0027db\u0027 disk , this is \u0027tmp\u0027\n disk etc?\n\nI knew we (IBM ICM) used to have some bugs that you attach the 2 devices but doesn\u0027t spcify the device name and later on when start the instance the devices might be assign different name because of udev order, not sure it\u0027s related ...","commit_id":"99d6a3e9fe83874d7b6bd4e32f603b519db80adc"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2f7b892f34f655624797d3e3b0cb57b98f3910db","unresolved":false,"context_lines":[{"line_number":65,"context_line":"have other attached volumes, and trust the compute service to attach the volume"},{"line_number":66,"context_line":"correctly."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As a user, I want to be able to see the tags set on virtual devices for a"},{"line_number":69,"context_line":"given server."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Proposed change"},{"line_number":72,"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":2,"id":"5f7c97a3_0dba406d","line":69,"range":{"start_line":68,"start_character":0,"end_line":69,"end_character":13},"in_reply_to":"5f7c97a3_5720d99b","updated":"2018-06-07 16:28:13.000000000","message":"\u003e my understand for tag is something like a label or metadata so we can retrieve or search based on it the tag will be something like /dev/vdx as we did before for device? who is going to honor the tag or it\u0027s just something we want to let operator know this is \u0027db\u0027 disk , this is \u0027tmp\u0027\n disk etc?\n\nTags are completely arbitrary strings to identify the device:\n\nhttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id23\n\n\u003e I knew we (IBM ICM) used to have some bugs that you attach the 2 devices but doesn\u0027t spcify the device name and later on when start the instance the devices might be assign different name because of udev order, not sure it\u0027s related ...\n\nWhen you say start, do you mean reboot? And which virt driver? I believe that\u0027s also a long-standing known issue anyway, mdbooth has talked about it many times and I think even had a spec related to it at one point, but the idea was to basically try and preserve the ordering of the block devices in the guest on reboot. However, his spec for local device serials also gets us there a bit since then block devices and local (swap/ephemeral) devices would also have a serial associated so you identify them from within the guest:\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/local-disk-serial-numbers.html","commit_id":"99d6a3e9fe83874d7b6bd4e32f603b519db80adc"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2f7b892f34f655624797d3e3b0cb57b98f3910db","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"There will be three main changes in the same microversion:"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"1. Remove parameter ``device`` from the"},{"line_number":77,"context_line":"   ``POST /servers/{server_id}/os-volume_attachments`` (attach volume) API."},{"line_number":78,"context_line":"   We just need to remove the parameter from the json schema request validation"},{"line_number":79,"context_line":"   for accepted parameters. After that microversion, providing a device when"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f7c97a3_0d480085","line":76,"updated":"2018-06-07 16:28:13.000000000","message":"One side effect of this which came up after discussing this internally, is we had the old (approved) detach/attach root device spec:\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/detach-boot-volume.html\n\nAnd that relied on detaching the root volume and then attaching a new root volume using the root device name, so if we removed the device field from the volume attach API, we wouldn\u0027t be able to do that. If we did that spec (which I think Huawei might re-propose in Stein), another idea would be to pass an is_root flag so that the user doesn\u0027t need to specify a device name, they just say they are detaching and then attaching the root disk, and nova figures out the root bdm.","commit_id":"99d6a3e9fe83874d7b6bd4e32f603b519db80adc"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"499beb5b53a129c320b52c266c310446b76aec4d","unresolved":false,"context_lines":[{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* Request"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"  The ``device`` entry will be removed from the request body json schema."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Response"},{"line_number":111,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f7c97a3_c710e052","line":108,"updated":"2018-06-05 18:01:31.000000000","message":"You\u0027ve mentioned the resulting 400, above. If you wanted to be super complete you could mention it here (as an \"impact\").","commit_id":"99d6a3e9fe83874d7b6bd4e32f603b519db80adc"}]}