| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-27 | |||
| 17:01:17 | mriedem | ken'ichi says it's ok https://review.openstack.org/#/c/616995/ | |
| 17:01:33 | mdbooth | mriedem: Going back a patch, I was wondering about adding an 'intent' to driver.cleanup and/or driver.destroy, i.e. driver.destroy(reason=MIGRATION|DELETE). We currently have destroy_disks, but the problem with this is that we second guess it in ComputeManager, which makes it basically useless. | |
| 17:02:22 | mdbooth | What we want the driver to do is, for delete: delete everything. For migrate/evacuate: delete everything local to this hypervisor. | |
| 17:03:03 | mdbooth | I think the definition of 'local to the hypervisor' is more cleanly defined internally by the hypervisor. | |
| 17:03:05 | slaweq | hi nova cores, can You take alook at https://review.openstack.org/#/c/619061/ - it should fix neutron-tempest-postgres-full periodic job in gate so it's quite important for us :) | |
| 17:03:08 | slaweq | thx in advance | |
| 17:03:27 | sean-k-mooney | mriedem: oh ok cool i think there is more in that file we are not using that we could remove too | |
| 17:03:56 | mriedem | mdbooth: i don't expect you'll get much in the way of replies on that in the ML | |
| 17:04:08 | mriedem | people, like me, will likely say they don't want to think about it | |
| 17:04:25 | mdbooth | mriedem: It's a source of a class of real bugs, thoough | |
| 17:04:26 | mriedem | mdbooth: so having said that, i assume you aren't proposing to change your current fix to incorporate that right? | |
| 17:04:32 | mriedem | mdbooth: oh i don't doubt it | |
| 17:04:34 | mdbooth | mriedem: Hell, no | |
| 17:04:55 | mdbooth | mriedem: I was thinking about lyarwood's original proposal to fix an extra thing in my patch | |
| 17:04:58 | mriedem | there is definitely a russian roulette of disk deletion in compute/virt | |
| 17:05:16 | mdbooth | I looked harder at that, and I don't think we can fix it like that | |
| 17:07:42 | openstackgerrit | Jack Ding proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 17:12:03 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: [WIP] Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542 | |
| 17:14:48 | mdbooth | mriedem: Practically speaking, what would be the most practical way to go about making that sort of change? Just post a patch? Problem is it wouldn't be a small amount of work, so I'd be cautious of that without some level of buy in beforehand. BP? | |
| 17:17:19 | mriedem | bp doesn't give you much in the way of details, spec allows you to really write the details down and get review on it without getting too far into implementation, but idk | |
| 17:17:47 | mriedem | gonna be a hard sell to get people to want to spend time/brain power on this | |
| 17:38:15 | sean-k-mooney | mdbooth: blueprints tend to be more for tracking then design if you want input you will want a spec or at least a etherpad + hangout if you have a quorum of people that are interested | |
| 17:44:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor TestEvacuateDeleteServerRestartOriginalCompute https://review.openstack.org/608705 | |
| 17:44:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix InstanceNotFound during _destroy_evacuated_instances https://review.openstack.org/606122 | |
| 17:44:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400 | |
| 17:44:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Always read-deleted=yes on lazy-load https://review.openstack.org/575190 | |
| 17:44:21 | mriedem | dansmith: rebasearoo | |
| 17:45:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: Run against mriedem's evacuate test https://review.openstack.org/604423 | |
| 17:49:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587 | |
| 17:49:54 | artom | mriedem, ^^ I think I got everything, when you have a moment | |
| 17:51:16 | mriedem | ok | |
| 17:52:38 | artom | (Oh and the docstring patch as well) | |
| 17:52:47 | artom | But that's not as important | |
| 17:52:50 | bauzas | mriedem: artom: I'll try to look at this spec tomorrow | |
| 17:52:58 | artom | woot | |
| 17:53:03 | artom | Cheers bauzas! | |
| 17:55:03 | bauzas | artom: before cheering me, wait for my comments :) | |
| 17:55:26 | artom | I have 100% confidence they'll be constructive and useful. | |
| 17:55:47 | artom | Why no, my nose isn't brown, whydja ask? ;) | |
| 19:06:27 | mriedem | artom: dansmith: there you go https://review.openstack.org/#/c/599587/ | |
| 19:40:16 | artom | mriedem, thank you! | |
| 19:41:37 | mriedem | belmoreira: hey, remember talking in berlin about a problem where if you have a lot of disabled computes for an upgrade, but with max_placement_results set low, you could get novalidhost because placement returns all disabled computes? you were going to open a bug for that but i never saw one. | |
| 19:42:09 | mriedem | i remember dansmith and i kicked around some ideas about that in berlin, but my memory is getting hazy | |
| 19:45:45 | mriedem | need another core on this concurrent i/o disk semaphore thing in runways https://review.openstack.org/#/c/609180/ | |
| 19:45:48 | mriedem | it's pretty simple | |
| 20:21:02 | cdent | Are hooks still a thing that are being used in nova, or is it more that they haven't been cleared away yet? | |
| 20:22:38 | mriedem | don't build on them if you can help it | |
| 20:22:48 | mriedem | rely on notifications if possible | |
| 20:23:32 | mriedem | hooks are use at your own risk (we can break them and not care to fix them), and the last time someone complained about the interface breaking on one of the hooks, upstream got real serious about just yanking them | |
| 20:23:42 | mriedem | kind of one of those squeeky wheel kinds of things - best not to talk about it | |
| 20:23:54 | cdent | yeah, I was wondering if the yanking was still an option | |
| 20:24:23 | mriedem | if we had a good reason to | |
| 20:24:29 | cdent | because the race I'm watching just showed up with a trace from one of them, but it appears it is more likely a coincidence | |
| 20:24:34 | mriedem | and someone that cared enough | |
| 20:25:29 | cdent | my running theory at this point is a totally unsurprising "it's probably eventlet" | |
| 20:28:12 | mriedem | no one was ever fired for blaming eventlet | |
| 20:32:24 | mriedem | GET /jaypipes | |
| 20:32:25 | mriedem | https://review.openstack.org/#/c/603352/7 | |
| 20:36:15 | mriedem | i imagine jay is fighting with code using hooks within oath | |
| 20:36:31 | mriedem | hooks that call off to some chef thing | |
| 20:49:42 | openstackgerrit | Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677 | |
| 20:49:42 | openstackgerrit | Eric Fried proposed openstack/nova master: SIGHUP n-cpu to clear provider tree cache https://review.openstack.org/615646 | |
| 20:49:43 | openstackgerrit | Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705 | |
| 20:49:43 | openstackgerrit | Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695 | |
| 20:49:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049 | |
| 20:49:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042 | |
| 20:49:47 | efried | blayum | |
| 20:50:56 | cdent | huzzah | |
| 20:54:34 | artom | So eventlets are the reverse IBM? No one got fired for either buying IBM, or blaming eventlets? | |
| 20:59:28 | mriedem | that was the joke yes | |
| 21:02:44 | tbachman | <delayed boom-splash> | |
| 21:07:01 | flwang | could anybody please help me understand that if i can swift from v2 endpoint to v2.1 endpoint directly? | |
| 21:07:25 | flwang | 'directly' means change the endpoint url in keystone catalyst directly, thanks a lot | |
| 21:11:47 | mriedem | flwang: https://docs.openstack.org/nova/latest/reference/stable-api.html and https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/api-relax-validation.html might help, but i think you also have to do something with the api-paste.ini | |
| 21:11:58 | mriedem | since that is config, it will require a change on upgrade to use v2.1 | |
| 21:13:32 | mriedem | i'm thinking about this from liberty https://github.com/openstack/nova/commit/4a18f7d3bafcdbede48500aac389e0a770b8e6a8#diff-c29e518f0f69a48dc80705f43cf9a3b4 | |
| 21:14:35 | flwang | mriedem: thanks for reply, we have enabled it based on my testing, the v2.1 endpoint works | |
| 21:14:45 | flwang | but i'm not sure how can we migrate the catalyst in keystone | |
| 21:14:50 | flwang | catalog | |
| 21:15:18 | mriedem | you can't just make the compute endpoint point at v2.1 rather than v2? | |
| 21:16:50 | flwang | because when you initialize a nova client, the code will talk to keystone catalog to get the endpoint | |
| 21:17:01 | flwang | and currently, we're using /v2/ in the endpint | |
| 21:17:07 | flwang | not v1 | |
| 21:17:16 | flwang | for example, for horizon | |
| 21:17:20 | flwang | it's doing that | |
| 21:17:40 | flwang | and as a result, there are some features we can't enable without upgrading the endpint | |
| 21:20:38 | flwang | mriedem: i just checked, we have done the correct work for nova (api-paste.ini) | |
| 21:21:10 | flwang | and as I mentioned above, the endpoint is working correctly. im just not sure if we can change the keystone catalog now | |
| 21:21:30 | mriedem | the client just asks for the compute endpoint, right? which is an alias to some URL | |
| 21:21:49 | mriedem | the client shouldn't care if it's v1 or v2 or v2.1 really unless they have version-specific requests | |
| 21:23:21 | flwang | mriedem: yes, that's my understanding | |
| 21:23:49 | flwang | i think, as admin, it should be safe to switch the endpoint, but just wanna get more ideas at here | |
| 21:25:22 | mriedem | well it's been awhile since i've talked to any operators that went through this and the old kilo/liberty release notes are pretty sparse, | |
| 21:25:34 | mriedem | but the api-paste.ini was the big thing i knew of that hit people, like when oath upgraded, | |
| 21:25:39 | mriedem | but jpenick is out, and jaypipes insn't here | |
| 21:25:41 | mriedem | *isn't | |
| 21:25:47 | mriedem | jroll: were you around for the oath upgrade to ocata? | |
| 21:25:53 | mriedem | and compute api v2.1? | |
| 21:26:11 | mriedem | flwang: otherwise #openstack-operators is probably best | |
| 21:27:05 | Sundar | cdent: Please ping me when you have the time. Thanks. | |