| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-04 | |||
| 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 ? | |
| 15:07:18 | bauzas | if the latter, no worries | |
| 15:07:24 | kashyap | sean-k-mooney: When you get a minute, please remind me again: we can't set PCIe root ports via flavor metadata property, can we? | |
| 15:07:35 | sean-k-mooney | mriedem: ya that is what i had rememberd form dublin | |
| 15:07:49 | mriedem | bauzas: efried: i'll update it in a minute | |
| 15:07:53 | bauzas | mriedem: and yeah, I remember this change | |
| 15:07:59 | prometheanfire | stephenfin: ya, I made sure no pycache/pyc/pyo | |
| 15:08:24 | sean-k-mooney | kashyap: if we can the glance metadef have not been created to document it. i wish we could and didn not have this in the nova config. ill check | |
| 15:08:56 | kashyap | sean-k-mooney: Right, I presume we _can't_ today; I'll go look the code | |
| 15:09:02 | bauzas | mriedem: and I also remember the spec https://review.openstack.org/#/c/552105/3/specs/rocky/approved/default-allocation-ratios.rst | |
| 15:09:10 | stephenfin | prometheanfire: There's definitely some form of caching going on or your source is located somewhere else. That's the only reason for that stuff to happen | |
| 15:09:15 | bauzas | mriedem: but I think it's a separate issue | |
| 15:09:20 | kashyap | sean-k-mooney: A libvirt dev was asking that question: can Nova set the root ports via flavor; or just through a global knob | |
| 15:10:46 | prometheanfire | stephenfin: even odder, I ran the py27 version of nova-compute, got the traceback containing py35 | |
| 15:10:59 | prometheanfire | the main traceback was py27 though | |
| 15:11:12 | stephenfin | prometheanfire: Can you paste the output of that? | |
| 15:11:17 | prometheanfire | I think the real issue was that portion | |
| 15:12:20 | sean-k-mooney | kashyap: this is the config generation code but github is not finding its usage https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/libvirt/config.py#L1713-L1728 | |