| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 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 | |
| 19:29:23 | dansmith | mriedem: ack, well, do whatever you think is best for all of them and I won't complain again either way | |
| 19:29:34 | mriedem | the only worry i have is eventually having something like rebuild_instance where it's double duty based on conditional and is hairy as hell | |
| 19:29:41 | gmann | mriedem: you mean only in func tests ? GET /server/detail would not return any down cell instances and so does not include the sec grp right ? | |
| 19:29:51 | dansmith | yeah, that was the outcome of our original discussion I think | |
| 19:29:55 | mriedem | gmann: incorrect | |
| 19:30:21 | mriedem | gmann: with the down cell stuff, we return a partial set of information about an instance based on the api db | |
| 19:30:29 | mriedem | https://docs.openstack.org/api-guide/compute/down_cells.html | |
| 19:30:57 | gmann | yeah which is from show method. so true for GET /servers/<server-id> | |
| 19:31:14 | mriedem | the down cell func tests were not using a fixture that returned security groups properly | |
| 19:31:20 | mriedem | stephen's patch exposes that | |
| 19:31:36 | mriedem | anyway, as i said in https://review.opendev.org/#/c/685927/2/nova/tests/functional/test_servers.py@1264 i think it's just a matter of a docs fix for down cell | |
| 19:31:39 | mriedem | tssurya: ^ | |
| 19:32:19 | mriedem | gmann: fwiw it's also possible to test this stuff in devstack, here is a guide https://docs.openstack.org/nova/latest/contributor/testing/down-cell.html | |
| 19:32:49 | gmann | but Show never return sec grp so my point was inconsistent response between SHow and detail | |
| 19:33:09 | mriedem | ah yeah | |
| 19:33:11 | mriedem | fair point | |
| 19:33:23 | mriedem | well, changing that now would be a new microversion | |
| 19:33:47 | gmann | yeah, same i was thinking whether it is worth to fix or just doc update work fine. | |
| 19:33:58 | gmann | doc update works fine i think | |
| 19:34:02 | mriedem | fix it with a new microversion? i don't think it's worth it | |
| 19:34:07 | mriedem | agree | |
| 19:34:26 | mriedem | if you want to know security groups for a server in a down cell, you can get them from neutron directly | |
| 19:34:57 | gmann | true. | |
| 19:34:58 | efried | dansmith: Does the db migrationy thingy get backported? | |
| 19:35:07 | efried | ...is it for train or ussuri | |
| 19:35:10 | efried | I'm confused... | |
| 19:35:14 | mriedem | ussuri, | |
| 19:35:19 | mriedem | it's in case we backport a db migratoin to train | |
| 19:35:22 | dansmith | efried: it's for U | |
| 19:35:23 | dansmith | backporting it would defeat the purpose | |