| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 18:19:17 | mriedem | you could be the first to start an [imagecache] group | |
| 18:19:22 | mriedem | and we move the others over after | |
| 18:19:31 | mriedem | that's still easy | |
| 18:19:38 | dansmith | okay yeah, nice | |
| 18:19:54 | mriedem | smells like synergy in here | |
| 18:23:22 | dansmith | smells more like cheating | |
| 18:24:39 | mriedem | stephenfin: https://review.opendev.org/#/c/684334/6 | |
| 18:25:15 | stephenfin | mriedem: Think you can hold your nose and ignore that for now? I have a patch to remove the entire thing locally | |
| 18:25:32 | stephenfin | But I can't push because I'm afraid it'll rebase everything else in that queue | |
| 18:25:41 | mriedem | reply with a link to the thing that removes it | |
| 18:25:53 | mriedem | if it's like 20 patches down the line i'll be sad | |
| 18:26:25 | stephenfin | it's not on Gerrit yet - it'll be 20 patches anyway | |
| 18:26:29 | stephenfin | lemme push to GitHub | |
| 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 | |