Earlier  
Posted Nick Remark
#openstack-nova - 2019-10-03
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 sean-k-mooney we down suport it downstream becasue the osp iamges are not lvm based
19:22:11 mriedem we == rhosp right?
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
19:35:26 mriedem rare, but it's happened
19:35:53 efried k, just confused by the stein one that was proposed in train and its message says stein.
19:36:11 dansmith proposed in train for stein backports
19:36:17 dansmith like this is proposed in u for train backports
19:36:30 efried rite.
19:36:36 efried thanks
19:42:20 mriedem gmann: 1846559
19:42:23 mriedem oops, bug 1846559
19:42:23 openstack bug 1846559 in OpenStack Compute (nova) "Handling Down Cells in nova - security_groups can be in the response for GET /servers/detail" [Medium,Confirmed] https://launchpad.net/bugs/1846559
19:42:52 gmann thanks
19:43:46 sean-k-mooney if you use nova network instead of neutron you will get the security grous too
19:44:45 openstackgerrit Merged openstack/nova master: nova-net: Remove explicit 'USE_NEUTRON = True' https://review.opendev.org/685937

Earlier   Later