| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-04 | |||
| 14:01:03 | mriedem | delete_on_termination=true for bfv, | |
| 14:01:04 | sean-k-mooney | jaypipes: from a placement perspecitive did we settle on the idea that neutron and cinder resouces would be conumed by the instance e.g. the instance uuid is used as the consumer rather then neutorn port uuid ecta. | |
| 14:01:07 | mriedem | and nova cleans up the ports it creates | |
| 14:01:14 | jaypipes | mriedem: who said anything about terminating anything? | |
| 14:01:37 | mriedem | we can assume that someone would eventually try to delete these resources | |
| 14:01:57 | mriedem | if this is stricly baremetal instances b/c oath, then let's be clear about that | |
| 14:02:04 | jaypipes | mriedem: let's discuss this on the review, eh | |
| 14:02:04 | mriedem | but even baremetal instances can boot from volume now | |
| 14:02:24 | jaypipes | mriedem: this is not strictly bm instances for oath, no... | |
| 14:02:25 | mriedem | sure | |
| 14:02:41 | jaypipes | I'm really not sure why you think that. | |
| 14:02:56 | jaypipes | I'm not sure what about the spec as written gave you that impression. | |
| 14:08:42 | tobias-urdin | hm is there any easy way to figure out if an instance is volume backed using novaclient? | |
| 14:09:27 | mriedem | yes | |
| 14:09:32 | mriedem | image_ref is '' | |
| 14:10:29 | mriedem | *image | |
| 14:10:37 | mriedem | normally it's a dict with an id and link, | |
| 14:10:40 | mriedem | but for volume-backed, it's just '' | |
| 14:11:12 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L332 | |
| 14:15:50 | mriedem | comments inline | |
| 14:15:55 | mriedem | jaypipes: | |
| 14:18:41 | tobias-urdin | mriedem: thanks! | |
| 14:23:43 | tobias-urdin | mriedem: and if you need to get a list of all attached volume and know which one is the root volume? | |
| 14:25:05 | tobias-urdin | sorry got it get_server_volumes() | |
| 14:25:57 | tobias-urdin | if it's one volume that easy, otherwise should you rely that device=/dev/vda always is the first that is booting | |
| 14:26:02 | tobias-urdin | ? | |
| 14:27:24 | mriedem | device name doesn't really mean anything, | |
| 14:27:28 | mriedem | nova ignores it if supplied | |
| 14:27:46 | mriedem | boot_index is what you'd want, but i don't think we expose that out of the api | |
| 14:28:20 | mriedem | we certainly could, and probably should if we ever want to get device_name out of the API for volumes | |
| 14:30:05 | tobias-urdin | hm ouch so the boot index cant be access through any api calls listing server info or block device mappings or similar | |
| 14:31:12 | tobias-urdin | can the boot_index be changed from nova's perspective? because the only way I could work around that would be relying on the creation date of the volumes | |
| 14:31:20 | sean-k-mooney | tobias-urdin: if you need a reliable way to assicate volumes with devices in the guest you need to use tags | |
| 14:33:52 | tobias-urdin | sean-k-mooney: ok, don't think that helps what i'm trying to do. i need to get the root volume if its a volume backed instance | |
| 14:34:27 | tobias-urdin | i guess other than creation date i could check if the volume was created from an image with the cinder api, but that could fail as well if somebody attaches a volume for recovery | |
| 14:34:58 | sean-k-mooney | tobias-urdin: e.g. novas boot form volume form image or boot with a precreated volume | |
| 14:36:01 | tobias-urdin | after checking i can't see nova populating the image field even when booting from a volume + image during creation | |
| 14:36:35 | sean-k-mooney | mdbooth: wasn't someone working on ^^ | |
| 14:37:10 | mriedem | which image field? | |
| 14:37:36 | mriedem | i forgot about tags - yes you could use tags to say which is the root volume during boot from volume, but we don't expose the bdm tags out of the API either :) | |
| 14:37:42 | tobias-urdin | whichever Server.image from novaclient provides | |
| 14:37:50 | mriedem | i have related specs for both of those things i think | |
| 14:38:04 | mriedem | yes that's on purpose - the server.image is '' if volume-backed | |
| 14:38:14 | mriedem | the image backing the root volume is in the volume metadata | |
| 14:38:41 | mriedem | in "volume_image_metadata" | |
| 14:39:23 | mriedem | https://review.openstack.org/#/c/452546/ is related to getting device_name out of the API, | |
| 14:39:27 | tobias-urdin | is that exposed out of the api and novaclient? | |
| 14:39:36 | sean-k-mooney | volume_image_metadata is a copy of the glance metadata for an image pluse i think an image ref of some kind i think ? | |
| 14:39:53 | mriedem | tobias-urdin: which? volume_image_metadata? | |
| 14:40:03 | mriedem | tobias-urdin: that's on the volume, so nova doesn't expose it, cinder does, | |
| 14:40:04 | mriedem | but yes | |
| 14:41:25 | mriedem | https://review.openstack.org/#/c/393930/ also related to exposing bdm tags out of the compute api | |
| 14:41:28 | mdbooth | volume_image_metadata doesn't need to have a corresponding glance image, btw. | |
| 14:41:36 | mriedem | which overlaps with https://review.openstack.org/#/c/452546/ | |
| 14:41:51 | mdbooth | But it's used in the same way and has the same semantics. | |
| 14:43:43 | mdbooth | mriedem: Yeah, it's weird we don't expose that. | |
| 14:44:14 | mdbooth | tags via the rest api, that is. | |
| 14:44:36 | mriedem | just hasn't been done - i've had the specs, been defeated, then found new agreement but haven't found new motivation for doing the work | |
| 14:46:45 | tobias-urdin | found what i needed in volume_image_metadata atleast, just have to do some ugly assumptions for now based on volume_image_metadata and creation date since i cant access boot_index or block device mappings info | |
| 14:46:55 | tobias-urdin | thanks for helping out :) | |
| 14:49:27 | sean-k-mooney | tobias-urdin: this kind of think is something that could be a feature request to the openstacksdk/shade teams as getting the root volume for boot from volume is likely one of thoes things that will change alot depending on your env and could be handeld in a shade proxy api | |
| 14:49:46 | mdbooth | tobias-urdin: In practise, it's probably going to be the one with volume_image_metadata. | |
| 14:50:28 | mdbooth | Although I was reviewing a v2v tool the other day which added volume_image_metadata to multiple volumes, which would have broken that assumption, but I can't imagine that's common. | |
| 14:51:20 | mdbooth | Creation data is less reliable, especially if you have persistent data on volume X, and created a root volume to contain an app to manipulate it some time later. | |
| 14:51:47 | mdbooth | Unlike the first case, I'd expect that to be likely to happen in the wild. | |
| 14:52:39 | tobias-urdin | sean-k-mooney: sort of pressing to get this stuff done (as always...) otherwise it would've been optimal to check the sdk first | |
| 14:53:04 | tobias-urdin | mdbooth: yeah, i was thinking about combining if there is multiple volume_image_metadata just assume the first created.. atleast i would always get something | |
| 14:56:03 | prometheanfire | stephenfin: hi :D | |
| 14:56:09 | stephenfin | prometheanfire: o/ | |
| 14:57:16 | mdbooth | Not strictly related, but afaict we attach volumes in a non-deterministic order on restart, except for the root volume. And that's ok. We should probably deliberately randomise it :) | |
| 14:58:39 | tobias-urdin | while I'm at it... here's a sad question, can I somehow block the creation of image backed instances? (i.e images_type backed instances) | |
| 14:59:29 | tobias-urdin | policy, super simple api hack or similar, everything's allowed but the best would be to not really touch anything critical | |
| 14:59:38 | prometheanfire | stephenfin: maybe my deployment is just broken, gimme a few to get out of this meeting and I'll update you | |
| 14:59:59 | tobias-urdin | I was hoping on setting images_type to None but that errors out upon initialization | |
| 15:01:25 | mdbooth | tobias-urdin: Don't deploy glance? | |
| 15:01:33 | tobias-urdin | (oh how I wish there was a cinder backend for images_type right now, wish i familar enough with the codebase to drive such a work) | |
| 15:02:41 | tobias-urdin | mdbooth: how u mean? hm settings [glance]/api_servers to something invalid? | |
| 15:02:58 | sean-k-mooney | tobias-urdin: well if you have ceph you could set nova to image_type ceph | |
| 15:03:38 | tobias-urdin | sean-k-mooney: yea that's what we do today, however don't want users that way at all, weird i know but we want to default to cinder | |
| 15:03:46 | efried | bauzas, mriedem: https://review.openstack.org/#/c/598365/ just needs config helps updated? | |
| 15:04:14 | mriedem | haven't looked at reviews on it yet today | |
| 15:04:39 | sean-k-mooney | tobias-urdin: its not that weird haveing a generic image_type cinder has come up in dublin ptg and last time in denver | |
| 15:04:42 | bauzas | efried: yep, IMHO | |
| 15:04:50 | sean-k-mooney | its just not that simple. | |
| 15:05:05 | bauzas | efried: mriedem: once done, we could modify the default values | |
| 15:05:26 | mriedem | i thought ovh already had a patch for that | |
| 15:05:29 | tobias-urdin | sean-k-mooney: yea :( | |
| 15:05:35 | efried | bauzas, mriedem: It's blocking our CI, so I would like to get it merged as soon as possible. | |
| 15:05:48 | bauzas | orly N | |
| 15:05:49 | bauzas | ? | |
| 15:05:55 | bauzas | if so, let me +W it | |
| 15:06:03 | mriedem | bauzas: https://review.openstack.org/#/c/532924/ | |
| 15:06:10 | sean-k-mooney | mriedem: do you know if anyone is proposing or looking at a cinder image time for stein or makeing bfv the default? | |
| 15:06:19 | efried | bauzas: Okay, thanks. We can do the conf helps in a fup? | |
| 15:06:30 | sean-k-mooney | *image_type=cinder | |
| 15:06:31 | mriedem | efried: i can look and update | |
| 15:06:44 | bauzas | efried: if needed, yep | |
| 15:06:51 | mriedem | sean-k-mooney: as in the fabled libvirt cinder image backend of lore? | |
| 15:07:00 | mriedem | no, no one is working on that | |
| 15:07:14 | bauzas | mriedem: would you be possible to pass a new revision now, or just a new change later ? | |