| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 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 | stephenfin: I was probably just griping about stub_out being a thin wrapper around | |
| 17:58:42 | efried | self.useFixture(fixtures.MockPatch(...)) | |
| 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 | in this case if the noop's return is actually important, you would do like | |
| 18:00:22 | efried | self.useFixture(fixtures.MockPatch('path.to.thing', return_value=('',''))) | |
| 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 | stephenfin | niiiiice | |
| 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: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 | |
| 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 :) | |