Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-04
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
15:13:01 sean-k-mooney kashyap: codesearch did however http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py#n5117
15:13:21 sean-k-mooney kashyap: the dirver uses the conf value directly
15:13:37 kashyap sean-k-mooney: So no metadata property
15:13:43 kashyap Wonder if we should file a blueprint to add it
15:14:07 sean-k-mooney kashyap: i would be +1 on that espcially if we can deprecate and remvoe the conf option
15:14:27 kashyap sean-k-mooney: Yeah, we should be able to do that; instead of the global config.
15:14:45 kashyap Damn, since I 'discovered' the bug, I get the pleasure of filing the Blueprint I guess :P
15:14:58 kashyap sean-k-mooney: More seriously, paperwork question: does this require a spec? Since it's user-impacting?
15:15:29 kashyap Or a spec-less blueprint is reasonable enough?
15:16:41 sean-k-mooney kashyap: spec-less blueprint. extra specs are a gray area as they are not technical part of the versioned api but are user fasing so mriedem or someelse will likely comment on the blueprint if a specs is needed
15:17:18 prometheanfire stephenfin: https://gist.githubusercontent.com/prometheanfire/6512134e799ec8c08c3f080150f60d19/raw/7cdb3a9a350c19540b1c930077e164786226636b/gistfile1.txt
15:17:20 kashyap sean-k-mooney: Yep, noted; thanks for the discussion.
15:18:25 sean-k-mooney by the way i have been using http://codesearch.openstack.org/ a lot more recently instead of using github to such for these things its pretty good
15:19:07 kashyap Ah, nice.
15:19:23 kashyap sean-k-mooney: BTW, seems like "hw:machine_type" isn't documented a flavor extra specs here: https://docs.openstack.org/nova/latest/user/flavors.html
15:19:33 kashyap Is that so?
15:20:01 sean-k-mooney kashyap: correct it is documented here https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L34-L38

Earlier   Later