Earlier  
Posted Nick Remark
#openstack-nova - 2019-10-03
18:26:48 mriedem you're going to have to rebase that series anyway aren't you? once the bottom 2 changes merged
18:26:50 mriedem *merge
18:26:54 stephenfin will I?
18:27:02 stephenfin I was hoping to avoid that
18:27:50 stephenfin mriedem: https://github.com/stephenfin/nova/commit/066e60572877dbc00c42f62ee6d02fd00c10ee4e
18:31:07 mriedem blech, i don't really want to wait for that, and if you have to rebase anyway (gerrit is showing the bottom two patches being diverged from later in the series)...
18:31:14 mriedem though i'm not sure that means you'll actually have to rebase
18:31:24 mriedem how about just following up with a simple patch on top of the one i'm cranky about?
18:31:31 stephenfin Sure, I can do that
18:31:39 mriedem again, m'fing synergy
18:44:45 openstackgerrit Merged openstack/nova stable/train: Restore console proxy deployment info to cells v2 layout doc https://review.opendev.org/686325
18:45:11 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_quota_sets' functional tests https://review.opendev.org/684334
18:45:34 stephenfin Hurrah, it worked
18:45:35 stephenfin mriedem: ^
18:50:53 mriedem got it
18:54:39 sean-k-mooney dansmith: mriedem: i left some question in the precache spec regarding image lifetime https://review.opendev.org/#/c/686232/5
18:56:43 sean-k-mooney im +0.5 on that sepc as it is so i like that its simple. just want to ensure we dont end up with tones of cached images that are never used and on the flip side that if it take a long time to cache it on alot of host that by the time it finsihes we dont race with cleaning them up
18:56:49 dansmith sean-k-mooney: what line?
18:57:33 sean-k-mooney 158 ish
18:58:17 sean-k-mooney also see the comment on line 95 about the isolateHostfilter and aggreateImageProertiesIsolation filter
18:58:36 dansmith sean-k-mooney: I'm specifically excluding any GET reporting on this, FWIW, but I said elsewhere that the standard imagecache purge rules would apply to these images
18:58:37 sean-k-mooney those are used to geofence where instacne with certin image can land
18:58:47 dansmith sean-k-mooney: which is why when we re-cache an image we already have, we touch it
18:59:22 dansmith sean-k-mooney: right, but this is admin-controlled, by aggregate, so they control where the images go, and may want to pre-cache an image somewhere before they allow the scheduler to place it there
18:59:23 dansmith s/it/an instance/
18:59:50 openstackgerrit Merged openstack/nova master: nova-net: Use nova-net explicitly in functional tests https://review.opendev.org/684326
19:00:08 sean-k-mooney sure im just wondering if it could be a foot gun that we shoudl docuemtn
19:00:29 sean-k-mooney e.g. call out tha twe wont run the isolation filters with teh aggreate you provided
19:00:52 sean-k-mooney so as an operator its your responcablity to ensure it does not violate any polices
19:01:26 dansmith sure, the docs will say lots of "this is very basic" things
19:02:06 sean-k-mooney ya ok honestly those were my two main concernes
19:02:13 mriedem what's the worst that would happen in that case? you push an image to a host that doesn't get used b/c the scheduler is configured to exclude that image from that host, so the image just ages out and is removed
19:02:29 dansmith right
19:02:37 dansmith which you may want, and if you don't, it gets purged later
19:02:42 sean-k-mooney mriedem: you push an image across a contry bountry and violate export contol
19:03:11 dansmith sean-k-mooney: ...which you asked for explicitly :)
19:03:19 sean-k-mooney as an admin you should know what edge sites your host aggretes map too
19:03:33 sean-k-mooney but that filter was added to prevent that case form happening
19:03:42 sean-k-mooney dansmith: yes its user error
19:03:43 mriedem a future improvement could be to validate the images against the host aggregate using the configured filters, something like that - the old scheduler as library idea
19:03:54 sean-k-mooney ya
19:04:06 mriedem hence the list o dicts so you could single out a particularly hairy image to validate
19:04:11 sean-k-mooney i was also sugestiong a follow on could be to run the weighs
19:04:14 mriedem and the others are just like ubuntu images and it doesn't matter
19:04:18 dansmith sean-k-mooney: *admin error
19:04:19 mriedem spray em while you got em
19:04:23 sean-k-mooney to priortise the order the miages are pushed out
19:04:43 dansmith sean-k-mooney: I mentioned priorities as a future thing, in the spec
19:04:56 sean-k-mooney yep i saw
19:05:04 mriedem yeah sounds like what's proposed doesn't make building the fancy in later hard, so that's the goal
19:05:46 sean-k-mooney and it was what came to mind i saw mriedem ask about it being a dict then read the paragpgh where you mentioned priorties and ttls
19:06:03 sean-k-mooney dansmith: i do like the design you are proposing
19:08:24 openstackgerrit Eric Fried proposed openstack/os-traits master: Add method to visualize the os-traits tree https://review.opendev.org/686464
19:09:05 sean-k-mooney oh i remembered what i was going to ask. do we have docuemntation for how the normal caching works
19:09:46 sean-k-mooney if yes i can find it myself
19:10:17 dansmith sean-k-mooney: I dunno, let me know :)
19:11:21 sean-k-mooney if i dont find it im sure mdbooth could tell me over beer
19:12:39 mriedem no
19:12:46 mriedem we don't have anything for docs on image caching
19:12:54 mriedem i've complained about, but done nothing about, many a time
19:13:44 mriedem we definitely should though since it's a not very well understood area of the code, obviously
19:13:55 mriedem i elect mdbooth to write something up
19:14:43 dansmith I could maybe do some of that in the process of writing up these
19:16:13 sean-k-mooney dansmith: you mentioned in the spec that libvirt,vmware and hyperv share teh same imagecache module but i also supece part of the reason we pass around partial methods in that code is because its "generic" code that has to deal with driver specific edgecases
19:16:42 dansmith sean-k-mooney: it's much worse than you could even imagine, trust me
19:17:41 sean-k-mooney oh i have seen it and ran away before. i mentioned in the spec it would be nice to add image caching for the lvm image backend at some point usign lvm snapshots. then i rememerbed what that code looked like
19:18:06 dansmith yeah, I replied to that.. I'm not sure that it's not implemented for LVM, or at least, not smartly unimplemented
19:18:09 dansmith but I could be wrong
19:19:21 sean-k-mooney im deploy with lvm at the weekend and i did not see lvm volumes beign used as cache but i did not check if there were snapshots or if the backing file was cached a different way
19:19:45 dansmith no, it would be cached on disk as a file in the same way
19:19:50 dansmith and then used to write into the volume
19:19:59 dansmith the cache is always files on disk, regardless
19:20:01 sean-k-mooney ah ok
19:20:18 sean-k-mooney that less efficent but it makes sense
19:21:17 dansmith it's just naïveté in the code
19:21:31 mriedem gmann: re the down cell / security groups thing you mentioned before https://review.opendev.org/#/c/685927/2/nova/tests/functional/test_servers.py@1264
19:21:36 dansmith and a result of nobody (that I know of) really using LVM seriously as a backend
19:21:40 dansmith we don't even support it, AFAIK
19:22:11 mriedem we == rhosp right?
19:22:11 sean-k-mooney we down suport it downstream becasue the osp iamges are not lvm based
19:22:16 sean-k-mooney yes
19:22:18 mriedem windriver was using lvm for a long time
19:22:20 mriedem then moved to ceph
19:22:22 dansmith sean-k-mooney: I'm pretty sure we do not
19:22:39 sean-k-mooney sorry yes i ment to say we do not
19:24:16 dansmith it doesn't really matter if the osp images are flat or not, I think we don't support it for overcloud
19:24:21 sean-k-mooney the lvm backed performs better the qcow2 for write intensive workloads which is why imt thinking of using it
19:24:27 dansmith we used to I think, but dropped it probably because lyarwood threatened to quit :)
19:24:33 mriedem dansmith: btw, unrelated to image caching, question for you on the prep resize patch at the bottom of the cross-cell series https://review.opendev.org/#/c/633293/
19:24:34 dansmith sure
19:24:51 mriedem dansmith: while it's fresh in your head, earlier i had posted a diff of what it might look like to re-use the existing prep_resize
19:25:12 mriedem it's not terrible...but i'd need to freshen that diff up to see what it looks like now after the vpmem stuff changed how normal prep_resize works
19:25:25 dansmith mriedem: I though we discussed that in here
19:25:42 gmann mriedem: yeah, i was thinking to mock the get_all or multi cell function or something in DownCellFixture and not return the down cell instances. but did not check yet.
19:25:45 mriedem i think we did a bit before i wrote the code to see what the diff would actually look like
19:26:01 dansmith mriedem: I think I said I wish we could make them more the same, but I'm probably just being too idealistic, and then the numa LM came along with a similar requirement
19:26:04 mriedem gmann: tl;dr you're right and we'll return security groups and proxy to neutron even for down cell responses
19:26:28 mriedem gmann: that was hidden in functional tests b/c of the bad fixture
19:28:24 mriedem dansmith: ok for prep_resize (of the 5 compute resize related methods) it's not terrible to munge support into the existing thing if we want to do that,
19:28:48 mriedem but it's not really tenable for the others imo

Earlier   Later