| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 17:20:27 | mriedem | dansmith: that reminds me, one thing we'll likely want documented with using your thing is making sure a service user token is configured to avoid the user token timing out while triyng to download an image across a bunch of computes | |
| 17:20:42 | mriedem | https://docs.openstack.org/nova/latest/admin/support-compute.html#user-token-times-out-during-long-running-operations | |
| 17:21:00 | dansmith | mriedem: ack | |
| 17:23:30 | mriedem | bauzas: easy and fast -1 from me | |
| 17:23:33 | mriedem | you're welcome | |
| 17:25:29 | mnaser | but i dont think a token timing out during download might an issue | |
| 17:25:38 | mnaser | cause the request will be done with the download is done anyways | |
| 17:25:47 | mnaser | i think image upload are an issue for things like submitting properties/etc when dnoe | |
| 17:26:41 | dansmith | mnaser: we're talking about image pre-caching, where the process may take an hour | |
| 17:26:59 | dansmith | mnaser: so by the time the last compute starts doing the work, the token may have expired and it can't pull the image | |
| 17:27:20 | mnaser | oh i see, this isnt necessarily the on-vm-launch thing | |
| 17:27:21 | mriedem | lyarwood: i'm not sure i got your question correct in https://review.opendev.org/#/c/541420/ | |
| 17:27:32 | dansmith | mnaser: unrelated to vm launch entirely | |
| 17:27:39 | mnaser | okay, right :> | |
| 17:28:48 | dansmith | mnaser: is image pre-caching a thing you care about btw? I think your cloud is too general purpose to care maybe, but... ? | |
| 17:29:23 | dansmith | or you use ceph so not a thing anyway | |
| 17:29:25 | mnaser | dansmith: i think in our case most of our stuff is ceph based, and yeah, too general purpose to have images precached *but* it might be something as we are considering having VMs that are entirely local storage | |
| 17:29:38 | dansmith | okay | |
| 17:30:11 | mnaser | so maybe having a glance property that we'd use to maintain a bunch of 'hot' images that we expect users to launch often (then precache those images in some ci job) | |
| 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 | 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 | |