| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-24 | |||
| 20:49:37 | sean-k-mooney | so i guess it sse not sse3 | |
| 20:49:55 | sean-k-mooney | oh | |
| 20:49:58 | sean-k-mooney | its ssse3 | |
| 20:50:02 | artom | sean-k-mooney, huh, it doesn't directly explain the devstack CA thing | |
| 20:50:09 | artom | But definitely needs fixing | |
| 20:50:23 | sean-k-mooney | right but that is why n-cpu did not start | |
| 20:50:32 | artom | gmann, ^^ I'll push a new version, we'll see if the CA thing as well | |
| 20:50:37 | artom | It would indeed | |
| 20:50:45 | sean-k-mooney | ill swap to qa | |
| #openstack-nova - 2020-11-25 | |||
| 00:57:11 | openstackgerrit | norman shen proposed openstack/nova-specs master: Adds spec for instance live resize https://review.opendev.org/c/openstack/nova-specs/+/141219 | |
| 04:16:36 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Correct some spell errors https://review.opendev.org/c/openstack/nova-specs/+/764117 | |
| 05:09:51 | openstackgerrit | Merged openstack/os-vif master: Fix hacking min version to 3.0.1 https://review.opendev.org/c/openstack/os-vif/+/755168 | |
| 07:45:16 | openstackgerrit | wushiming proposed openstack/os-vif master: Remove the unused coding style modules https://review.opendev.org/c/openstack/os-vif/+/760491 | |
| 10:18:38 | openstackgerrit | Merged openstack/nova-specs master: Correct some spell errors https://review.opendev.org/c/openstack/nova-specs/+/764117 | |
| 10:21:32 | gibi | I feel that the discussion about the DB creds for the nova-compute ML thread is going nowhere. I'm getting fustrated about it as I feel I just wasting time thinking about it. | |
| 10:22:53 | stephenfin | amen :( | |
| 10:25:36 | lyarwood | I've honestly kept away from it given the number of people already involved. | |
| 10:25:58 | lyarwood | That said it is turkey week in the US so I assume that might be causing things to slow somewhat? | |
| 10:26:11 | lyarwood | stephenfin: https://news.ycombinator.com/item?id=25202143 - something to think about for the next in person PTG | |
| 10:26:36 | stephenfin | so what you're saying is, no better time to ram through whatever we want... 😈 | |
| 10:27:00 | stephenfin | Hahahaha | |
| 10:27:25 | gibi | I like bonfire so I support the code burn | |
| 10:27:57 | stephenfin | It's effectively a book burning. Who doesn't love a good book burning. | |
| 10:28:30 | gibi | the thing is that we already agreed (I think) that we don't merge the breaking change in W we wait for X. So I don't thing we can use Turkey week to sabotage everybody | |
| 10:28:49 | gibi | but these are the "wrong books" so we have to burn them! | |
| 10:28:56 | stephenfin | Oh, I was joking :-D That would be a terrible idea, heh | |
| 10:29:16 | gibi | stephenfin: I know, hence the word sabotage :D | |
| 10:29:29 | lyarwood | stephenfin: now you tell me, I've already +W'd everything | |
| 10:29:34 | stephenfin | phew | |
| 10:30:38 | gibi | btw dansmith is out for the rest of the year and he was really active and helping in the ML thread so it is fully possible that if I ignore the thread for a while it will simply die out | |
| 10:30:59 | gibi | but I'm not sure it looks good for a PTL to ignore this :/ | |
| 10:37:03 | bauzas | gibi: my personal take on this is that we made our responsibility in explaining the security risk | |
| 10:38:12 | bauzas | the WSGI app issue is reasonable to fix | |
| 10:38:57 | gibi | yes, I'm fully supportive to fix the sys.argv usage in WSGI regardless of the ML thread | |
| 10:39:12 | bauzas | but then, if you feel you're entering a rathole, make a big signal in the Wallaby release that DB creds are exposed and tell we'll make it hardstop in X | |
| 10:39:13 | gibi | that was a nice thing come out of the thread | |
| 10:39:28 | owalsh | gibi: hey, I'm a bit confused by the conductor [api_database]connection discussion.... | |
| 10:39:47 | bauzas | from a project perspective, we're just verifying the security exposure, that's it | |
| 10:39:53 | gibi | bauzas: this is exaclty what Dan proposed on the ML and I now implemented in code | |
| 10:40:12 | bauzas | gibi: this long talkative thread prevented me to read | |
| 10:40:15 | gibi | bauzas: so in W it is just a warning, in X it is hard fail. | |
| 10:40:24 | bauzas | then, we have actions | |
| 10:40:33 | gibi | but we are getting push back on the hard fail still | |
| 10:40:39 | owalsh | we need api db set for cell conductors for affinity checks, so how can we use it to determine if it's a cell/super conductor? | |
| 10:40:48 | bauzas | gibi: we could revisit then on X | |
| 10:41:10 | gibi | bauzas: yes, but I don't know how the discussion will be differnt :) | |
| 10:41:14 | bauzas | gibi: don't waste your energy on it, and the patch in question that would turn hardstop would just be a gerrit change | |
| 10:41:35 | gibi | owalsh: if you specify [api_database]connection to a nova-conductor service the it becomes a super conductor | |
| 10:41:47 | bauzas | I'm personnally convinced that in terms of productivity, gerrit wins over IRC which itsels wins over emails | |
| 10:41:57 | owalsh | gibi: dansmith and sean-k-mooney1 said it needs to be set on the cell conductor too | |
| 10:42:02 | bauzas | never ever expect good things to happen from a long ML thread | |
| 10:42:17 | gibi | owalsh: if your deployment needs affinity support and you are affraid of race condition in affinity then you need to make each conductor a super conductor | |
| 10:42:25 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Don't detach volumes when RescheduledException raised without retry https://review.opendev.org/c/openstack/nova/+/757894 | |
| 10:42:29 | lyarwood | stephenfin / gibi ; ^ added some additional context to this review btw, I still think it's better to be consistant here and let users clean things up by deleting their ERROR'd out instances. | |
| 10:42:51 | bauzas | gibi: owalsh: I've seen the superconductor proposal, this is way not good at all | |
| 10:43:01 | bauzas | because sometimes operators need flexibility | |
| 10:43:14 | bauzas | and a project shouldn't be opiniating about the service grouping | |
| 10:43:25 | gibi | lyarwood: ack | |
| 10:43:27 | bauzas | (I mean, the service deployment grouping) | |
| 10:43:51 | kashyap | gibi: Wow, impacting seven separate groups with that ML thread ... bold decision ;-) | |
| 10:44:33 | bauzas | gibi: owalsh: I personnally feel that a "superconductor" option could be a thing for operators as a way to group a set of project options | |
| 10:44:40 | gibi | bauzas: while I agree, ML threads has a wider reach than IRC and gerrit | |
| 10:44:45 | bauzas | but it shouldn't be a thing for the project itself | |
| 10:45:01 | bauzas | gibi: I'm not saying ML threads are unnecessary | |
| 10:45:08 | bauzas | they're good for getting noticed | |
| 10:45:13 | gibi | kashyap: that mail originally served as a heads up of the deployers and packagers, and it serverd that purpose well. | |
| 10:45:17 | owalsh | bauzas: we need a f2f PTG :-) | |
| 10:45:24 | gibi | owalsh: +100 | |
| 10:45:25 | bauzas | but then, the debate should happen elsewhere in a gerrit change | |
| 10:45:39 | bauzas | owalsh: gibi: you can't imagine how I feel nowadays | |
| 10:45:56 | bauzas | and I just got notice that my usual ski trip around New Year will be over | |
| 10:46:15 | bauzas | my mood is presently at the 3rd basement | |
| 10:46:24 | kashyap | gibi: Oh, definitely. Wasn't criticizing, BTW :) | |
| 10:46:27 | gibi | bauzas: I'm sorry to hear that :/ | |
| 10:46:44 | stephenfin | bauzas: you ski too much anyway | |
| 10:46:45 | kashyap | bauzas: "will be over" as in "it won't happen"? | |
| 10:46:49 | kashyap | stephenfin: LOL | |
| 10:46:59 | gibi | kashyap: no critic is taken. you and bauzas are right debating thing in that wide ML thread is a bold move | |
| 10:47:04 | bauzas | stephenfin: I haven't done that since March, it's been too long | |
| 10:47:40 | bauzas | kashyap: it shouldn't happen as ski resorts will stay closed until mid-Jan as our president told yesterday | |
| 10:47:43 | kashyap | It's okay; it serves as a record still. And writing out clarifies thinking :) | |
| 10:48:03 | bauzas | gibi: next round, you'll be invited | |
| 10:48:05 | kashyap | bauzas: Right; makes sense. As skii resorts were one of the "super-spreader" events back in March | |
| 10:48:18 | gibi | bauzas: I would love to try again | |
| 10:48:57 | bauzas | gibi: I did that for a couple of colleagues, I'm all up to redo this with a larger crew | |
| 10:49:14 | bauzas | anyway, back to the topic | |
| 10:49:26 | bauzas | gibi: anything worth for me reviewing about this ? | |
| 10:49:41 | gibi | midcycle up in the french alps! | |
| 10:49:43 | bauzas | I guess the WSGI config enablement is on its way, right? | |
| 10:50:37 | gibi | WSGI needs a second core https://review.opendev.org/c/openstack/nova/+/763750 | |
| 10:51:02 | bauzas | ack, looking | |
| 10:52:32 | gibi | there is a non-dangerous func test refactor here https://review.opendev.org/c/openstack/nova/+/758210 | |
| 10:52:49 | owalsh | gibi: re every conductor being a superconductor when api db is set - is that going to affect scaling? | |
| 10:53:37 | gibi | owalsh: good question | |
| 10:57:14 | gibi | owalsh: you might be able to still do conductor separation | |
| 10:57:43 | owalsh | still have mq/db sharding I guess | |
| 10:58:31 | owalsh | and only the cell local computes are on the same mq | |
| 10:58:33 | gibi | owalsh: if you have a conductor with an [api_database]connection config, but only configured to listen to the cell message bus, then that conductor will not get super-conductor type requests, but still can handled the upcalls for the late affinity check | |
| 10:59:06 | gibi | I would love dansmith to confirm this ^^ | |
| 10:59:13 | gibi | as I'm not 100% certain | |