| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-02 | |||
| 10:59:56 | lyarwood | k8s etc boots and then attaches for example | |
| 10:59:59 | sean-k-mooney | i used to use --volume | |
| 11:00:11 | lyarwood | anyway stephenfin I think this was just missed tbh | |
| 11:00:18 | stephenfin | sean-k-mooney: --volume is for a boot device though | |
| 11:00:27 | lyarwood | I got slightly confused by some output you posted in here | |
| 11:00:29 | sean-k-mooney | no its not | |
| 11:00:29 | stephenfin | at least in OSC | |
| 11:00:35 | stephenfin | it sets boot_index to 0 | |
| 11:00:50 | lyarwood | yeah --volume is shorthand for bfv in osc | |
| 11:01:07 | sean-k-mooney | ok i normally use horizon for this but im pretty sure i used --volume for this too | |
| 11:01:23 | sean-k-mooney | that a pretty bad design choice then | |
| 11:01:30 | stephenfin | Yeah, I'm not a fan either | |
| 11:01:57 | stephenfin | it should be the equivalent of '--network' and '--port', which are shorthand for various permutations of '--nic' | |
| 11:01:59 | lyarwood | didn't you have a change up to move that to --boot-volume? | |
| 11:02:12 | stephenfin | not me, that I recall | |
| 11:02:20 | lyarwood | okay I thought someone did | |
| 11:02:38 | lyarwood | I'd be fine with that but I'm not sure how you could then reuse --volume without breaking people | |
| 11:02:47 | sean-k-mooney | --bfv was porposed at one point | |
| 11:03:37 | stephenfin | I guess you could consider ordering and use 'parsed_args.volumes[0]' is 'parsed_args.image_uuid' was unset? | |
| 11:03:39 | sean-k-mooney | lyarwood: given osc is ment to work the same acroos multiple clouds and this would not be a micorverison change | |
| 11:03:42 | stephenfin | s/is/if/ | |
| 11:03:51 | sean-k-mooney | we coudl only resue --volume after a major version bump | |
| 11:04:32 | stephenfin | not really, iirc using '--volume' and '--image' together currently is illegal | |
| 11:04:46 | stephenfin | so we'd be loosening restrictions, not adding new ones | |
| 11:05:37 | stephenfin | if it's not it probably should be, since I can't see how specifying an image_uuid and a BDM with a boot_index of 0 would be allowed by the server | |
| 11:05:39 | sean-k-mooney | you can use --image and --boot-from-volume <size> today that is the short hand for that | |
| 11:05:56 | stephenfin | yeah, that's not what I'm describing though and it's a different thing | |
| 11:05:58 | sean-k-mooney | but i tought we could use --image and --volume today to boot form image and attach data volumes | |
| 11:06:04 | stephenfin | that'll create a new volume iirc | |
| 11:06:12 | sean-k-mooney | can we add --data-volumn | |
| 11:06:25 | stephenfin | that's kind of ugly | |
| 11:07:14 | sean-k-mooney | well if we cant reclaim --volume then its kind of the best we can do | |
| 11:07:39 | sean-k-mooney | som of the osc optionts are kind of questionable | |
| 11:07:50 | sean-k-mooney | for example --image-property | |
| 11:08:22 | stephenfin | $ openstack server create --flavor m1.tiny --image cirros-0.5.1-x86_64-disk --network private --volume test-volume test-server | |
| 11:08:28 | stephenfin | openstack server create: error: argument --volume: not allowed with argument --image | |
| 11:08:39 | stephenfin | yeah, as expected you can't do that currently | |
| 11:08:50 | stephenfin | so we could add it easily | |
| 11:09:31 | stephenfin | if image is not specified, the first volume specified gets boot_index of 0 and the rest get -1; if it *is* specified, all volumes get boot_index of -1 | |
| 11:09:48 | sean-k-mooney | no | |
| 11:10:11 | sean-k-mooney | if volume and image as sprecifed the root disk is created form the image | |
| 11:10:37 | sean-k-mooney | so that has boot index 0 | |
| 11:10:43 | stephenfin | that would mean overwriting whatever's already on the volume, no? | |
| 11:11:03 | stephenfin | that doesn't seem like something you'd want to happen automatically | |
| 11:11:04 | sean-k-mooney | no because we would be generating the bdm | |
| 11:11:29 | sean-k-mooney | its the only thing i would add to be honest | |
| 11:11:42 | sean-k-mooney | i dont think i would ever use what you proposed | |
| 11:12:02 | stephenfin | I don't understand what you're asking for though | |
| 11:12:17 | lyarwood | sean-k-mooney: tbh I think that's pretty confusing UX | |
| 11:12:32 | lyarwood | if you provide both --image and --volume you end up with an image based volume? | |
| 11:12:41 | sean-k-mooney | no | |
| 11:12:56 | sean-k-mooney | you end up with a image based root disk not on cinder and a data volume | |
| 11:13:03 | lyarwood | ah | |
| 11:13:15 | lyarwood | sorry I misunderstood something you said above | |
| 11:13:21 | stephenfin | I think I did too | |
| 11:13:41 | stephenfin | sean-k-mooney: the data volume would have a boot_index of -1, no? | |
| 11:13:50 | stephenfin | since it's a data volume, not a boot volume | |
| 11:14:09 | lyarwood | haha I don't think it does | |
| 11:14:09 | sean-k-mooney | well it typically would not be set as bootable in cinder at all | |
| 11:14:26 | stephenfin | so would you just not set it? | |
| 11:14:39 | sean-k-mooney | i dont know | |
| 11:14:40 | stephenfin | so instead of: | |
| 11:14:41 | stephenfin | if image is not specified, the first volume specified gets boot_index of 0 and the rest get -1; if it *is* specified, all volumes get boot_index of -1 | |
| 11:14:45 | stephenfin | I should say: | |
| 11:14:48 | sean-k-mooney | i assumed -1 means last possibel | |
| 11:14:57 | sean-k-mooney | or not bootable | |
| 11:14:58 | lyarwood | `To disable a device from booting, set the boot index to a negative value or use the default boot index value, which is None.` | |
| 11:15:06 | lyarwood | I've always just left it as None | |
| 11:15:10 | stephenfin | if image is not specified, the first volume specified gets boot_index of 0 and the rest get nothing; if it *is* specified, no volume gets a boot_index | |
| 11:15:25 | sean-k-mooney | yes | |
| 11:15:30 | sean-k-mooney | that would work | |
| 11:15:50 | lyarwood | yup | |
| 11:15:52 | stephenfin | so 'server create --image IMAGE --volume VOLUME ...' -> boot from image with an attached data volume (2 block devices) | |
| 11:15:59 | sean-k-mooney | yes | |
| 11:16:01 | stephenfin | so 'server create --volume VOLUME ...' -> boot from volume (1 block devices) | |
| 11:16:06 | stephenfin | s/so/and/ | |
| 11:16:23 | sean-k-mooney | yep | |
| 11:16:24 | lyarwood | stephenfin: does the first one use BDMs for both block devices or just the volume? | |
| 11:16:24 | stephenfin | okay, cool. That's what I was thinking all along but clearly didn't word it well. That should be easily doable | |
| 11:16:41 | lyarwood | stephenfin: and provide the image via imageRef | |
| 11:16:50 | stephenfin | probably just the volume with a separate imageRed | |
| 11:16:51 | stephenfin | *f | |
| 11:16:55 | lyarwood | cool | |
| 11:17:01 | stephenfin | seeing as it's easier | |
| 11:17:05 | stephenfin | presumably | |
| 11:17:08 | lyarwood | I was going to say if it did bdms for both we could nuke that | |
| 11:17:16 | sean-k-mooney | lyarwood: is there an advantate to use the bdm and setting the image one to local | |
| 11:17:21 | lyarwood | as yeah it's easier to use imageRef | |
| 11:17:54 | lyarwood | sean-k-mooney: no IMHO, given how weird osc already is about this stuff I was just checking it wasn't using them | |
| 11:18:05 | sean-k-mooney | ack | |
| 11:18:59 | stephenfin | sean-k-mooney: as for your concerns RE: --image-property: I share them https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L812-L814 | |
| 11:19:02 | stephenfin | it's on the chopping block | |
| 11:19:12 | stephenfin | or will be soon | |
| 11:19:58 | sean-k-mooney | well my concern was actully that we approved overriding image properties on the command line in the pass at the spec stage | |
| 11:20:04 | sean-k-mooney | but it never got implemented | |
| 11:20:22 | sean-k-mooney | so that really should not exist because if we ever revived that it would be a problem | |
| 11:20:24 | stephenfin | you really do need to play around with this stuff to realize the ugliness of some of the interactions | |
| 11:20:34 | stephenfin | lots of good stuff there but so many rough edges too | |
| 11:20:41 | stephenfin | sean-k-mooney: agreed | |
| 11:20:56 | sean-k-mooney | are you going to add --ephemeral | |