| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 17:31:19 | sean-k-mooney | mnaser: with ceph we do the whole cow clone in ceph to cache the image once its added to ceph the first time but precaching could still be useful in edge deployment if they had ceph too right? | |
| 17:31:46 | dansmith | mnaser: well, it won't be that automatic yet, but you could write a script to key it off of an image prop | |
| 17:31:51 | sean-k-mooney | it might not help vexhosts usecase but precaching with ceph chould still be useful | |
| 17:32:14 | mnaser | precache with ceph COULD solve that thing i talkeda bout a long time when multiple cells with their own ceph cluster each | |
| 17:32:15 | dansmith | sean-k-mooney: ceph at the edge doesn't work very well right now | |
| 17:32:31 | sean-k-mooney | dansmith: due to the 3 node requiremnet? | |
| 17:32:35 | mnaser | dansmith: yep, but at least id have the tool available in that case yeah | |
| 17:32:43 | dansmith | sean-k-mooney: because nova will do the pathologically terrible thing with ceph if it's not the same one as glance uses | |
| 17:32:50 | dansmith | mnaser: yep | |
| 17:33:21 | sean-k-mooney | download the image from glance and uplaod ti to ceph repeatedly? | |
| 17:33:42 | stephenfin | efried: I recall seeing a comment from you about doing this kind of thing differently https://github.com/openstack/nova/blob/master/nova/tests/functional/api_sample_tests/api_sample_base.py#L133 | |
| 17:34:14 | stephenfin | I should know what that alternative way is but I'm having a senior moment. Care to remind me? | |
| 17:34:25 | stephenfin | (allows us avoid the 'fake_noop' arg) | |
| 17:34:35 | dansmith | sean-k-mooney: yes so you end up with no re-use, but silently | |
| 17:34:44 | sean-k-mooney | ya that sucks | |
| 17:35:04 | sean-k-mooney | and wastes space on a ceph cluster that is proably already constratied | |
| 17:35:45 | dansmith | sean-k-mooney: s'mah point. This is what I mentioned at the last PTG which I will fix when glance gets the backend management APIs | |
| 17:35:50 | sean-k-mooney | and bandwith over a potentially slow link. isnt the multipl glace locaiton feature ment to help with that | |
| 17:36:18 | dansmith | sean-k-mooney: it is, but nova only has one it can handle, so if it's not already stored there, it will silently do the bad thing | |
| 17:36:19 | sean-k-mooney | ya i recall you talking about this | |
| 17:37:12 | sean-k-mooney | do you intend to adress that as part of the precaching spec or declare it out of scope and adress that seperatly | |
| 17:37:18 | sean-k-mooney | i woudl think seperatly | |
| 17:37:42 | dansmith | completely unrelated | |
| 17:38:11 | sean-k-mooney | well they both adress image distubution but ya that is what i was hoping you would say | |
| 17:38:52 | sean-k-mooney | im just preempting the possiblity of scope creap | |
| 17:55:11 | sean-k-mooney | has anyone ever tried to do an FFU across more then 3 release? | |
| 17:55:47 | sean-k-mooney | e.g. form say newton to train | |
| 17:56:12 | sean-k-mooney | i feel like that would be kind of a pain | |
| 17:58:42 | efried | self.useFixture(fixtures.MockPatch(...)) | |
| 17:58:42 | efried | stephenfin: I was probably just griping about stub_out being a thin wrapper around | |
| 17:58:48 | efried | you could replace it everywhere | |
| 17:58:59 | mriedem | stephenfin: are you thinking of efried always saying to use new= on a mock to avoid the method signature change? | |
| 17:59:45 | efried | in many stub_out cases where the replacement is actually a no-op, you can MockPatch('just.the.thing') and you get a default mock, i.e. you can do away with the replacement stub function | |
| 18:00:22 | efried | self.useFixture(fixtures.MockPatch('path.to.thing', return_value=('',''))) | |
| 18:00:22 | efried | in this case if the noop's return is actually important, you would do like | |
| 18:00:40 | stephenfin | hmm, that does rely on us not doing a truthiness check somewhere though | |
| 18:00:45 | stephenfin | or using return_value | |
| 18:00:52 | stephenfin | since bool(mock.Mock()) == True | |
| 18:01:25 | efried | if you use return_value it would be functionally identical to what's already there. | |
| 18:01:31 | sean-k-mooney | it depens on what you are testing | |
| 18:02:37 | sean-k-mooney | for what its woth i prefer using mock.patch and avoiding the stub_out stuff whenever possible | |
| 18:04:24 | efried | stub_out is a holdover from mox transition; at this point it can and should diaf | |
| 18:08:03 | stephenfin | mriedem: Could I ask you to look at https://review.opendev.org/#/c/684326/ and https://review.opendev.org/#/c/685937/ again at some point so I can keep that train moving | |
| 18:08:21 | stephenfin | I've another batch of those ready to go, including a lot of API removals/deprecations | |
| 18:08:30 | mriedem | stephenfin: just commented on https://review.opendev.org/#/c/684326/ | |
| 18:08:44 | mriedem | "I can't say I understand all of these but it looks like for at least some of them, which I think can extend to all of them, that there is likely something in the API samples response that is different when using neutron over nova-network and as such to change those tests to use neutron we also have to regenerate the samples which should be done an individual basis rather than en masse." | |
| 18:08:44 | stephenfin | niiiiice | |
| 18:08:47 | mriedem | if that's correct, then good | |
| 18:09:10 | stephenfin | that is correct | |
| 18:10:17 | mriedem | cool | |
| 18:10:40 | sean-k-mooney | an example of that is the way security groups are reported when using nova-net vs neturon right | |
| 18:10:57 | sean-k-mooney | its in the server show with nova net but not when using neturon | |
| 18:11:16 | mriedem | sean-k-mooney: | |
| 18:11:27 | mriedem | remember how you said you were too distracted to review dansmith's spec twice now? | |
| 18:11:51 | mriedem | put. the. irc. down. | |
| 18:11:55 | dansmith | lol | |
| 18:11:57 | sean-k-mooney | yes im on line 60 ish | |
| 18:12:33 | mriedem | i'm sure i'm not the only one that does this, but i've got irc in a separate monitor and when i need to focus on something i minimize it on that monitor, otherwise the scrolling chatter draws me in like a deadly siren | |
| 18:12:51 | dansmith | mriedem: any thoughts on where the parallelism conf knob should be? It'll be honored in conductor, but putting it in conf/conductor seems kinda weird for operators | |
| 18:13:03 | stephenfin | mriedem: Replied to the questions on that, if you were curious | |
| 18:13:30 | mriedem | dansmith: i'm fine with it being in conductor. if you think we might make it generally available elsewhere later then i guess DEFAULT? | |
| 18:13:35 | stephenfin | sean-k-mooney: Sort of. They _should_ be reported but weren't because the NeutronFixture was incomplete https://review.opendev.org/#/c/685927/2 | |
| 18:13:44 | stephenfin | fixed in that change | |
| 18:14:01 | dansmith | mriedem: given that the imagecache things are all in DEFAULT still, I kinda think that's the right call | |
| 18:14:02 | sean-k-mooney | ah ok | |
| 18:14:33 | stephenfin | and it's only a small step from there to Skynet | |
| 18:15:28 | mriedem | dansmith: or, | |
| 18:15:37 | mriedem | we actually group the imagecache options properly and do it there | |
| 18:15:43 | mriedem | i'm sure stephenfin would be up for such toil | |
| 18:17:27 | mriedem | having said that i only see 2 image_cache_* options today | |
| 18:17:50 | mriedem | oh and remove_unused_base_images | |
| 18:18:46 | mriedem | oh and | |
| 18:18:47 | mriedem | remove_unused_original_minimum_age_seconds | |
| 18:18:54 | dansmith | guh | |
| 18:19:08 | dansmith | I almost had the easy option | |
| 18:19:12 | mriedem | well, | |
| 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 | |