Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-25
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
11:00:03 owalsh gibi: ack, thanks. Makes sense. I'll make a note to check with dansmith in 2021 :-)
11:01:44 bauzas gibi: just begging for a relnote in https://review.opendev.org/c/openstack/nova/+/763750 so we don't hide this fancy feature
11:02:15 bauzas owalsh: gibi: I missed that point, dan is off until next year ? woah.
11:03:56 gibi bauzas: he told me that he will be away on PTO from this week until end of the year
11:04:11 bauzas that's good to know
11:04:29 gibi bauzas: I can add a reno for the sys.argv patch sure
11:04:35 bauzas I'm still facing unexpected and weird issues with the RPC API bump, I guess I'll defer it until he returns
11:04:52 bauzas because I'm out of steam on finding the problem
11:09:23 openstackgerrit Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336
11:24:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support sys.argv in wsgi app https://review.opendev.org/c/openstack/nova/+/763750
11:24:55 gibi bauzas: now with a reno ^^
11:31:22 gibi bauzas: also if you are in a review mood, there is another test refactor series here. This is a bit bigger though https://review.opendev.org/q/topic:%22remove-fake-notifier%22+(status:open%20OR%20status:merged)
11:39:17 gibi bauzas: and here is some testcoverage restored as a neutron bug has been fixed https://review.opendev.org/c/openstack/nova/+/755995
11:42:22 openstack Launchpad bug 1905224 in OpenStack Compute (nova) "bfv instance create failed due to insufficient resources, the volume is always attaching" [Undecided,New]
11:42:22 gibi lyarwood: +2d https://review.opendev.org/c/openstack/nova/+/757894 then I realized the we have a possibly related fresh bug in the untriaged list https://bugs.launchpad.net/nova/+bug/1905224
11:42:46 lyarwood gibi: looking
11:43:03 gibi "fresh" as it is reported from Pike
11:43:06 lyarwood gibi:`I am in pike version`
11:43:08 lyarwood yeah lol
11:43:24 gibi fresh means freshly opened :D
11:43:28 gibi sorry
11:43:59 lyarwood so that's https://review.opendev.org/c/openstack/nova/+/743220 I think
11:45:26 openstackgerrit Merged openstack/nova master: Use _evacuate_server helper in func test https://review.opendev.org/c/openstack/nova/+/758210
11:47:06 gibi lyarwood: thanks!
14:00:34 lyarwood stephenfin: https://github.com/openstack/nova/blob/e035ff4079c2cc6b32db1f637a3e3a816c2af191/nova/api/validation/extra_specs/hw.py#L73-L77 - any reason we can't point at the o.vo types for this list of enums? https://github.com/openstack/nova/blob/e035ff4079c2cc6b32db1f637a3e3a816c2af191/nova/objects/fields.py#L271-L277
14:00:56 lyarwood stephenfin: just wiring up a validator for my ephemeral encryption spec and didn't want to duplicate things between the two
14:01:17 stephenfin None that I'm aware of. I simply didn't think to
14:01:48 lyarwood stephenfin: kk, might give it a go in a FUP
14:23:22 openstackgerrit Takashi Natsume proposed openstack/nova master: doc: Fix rendering in the PTL guide https://review.opendev.org/c/openstack/nova/+/764175
14:26:09 stephenfin elod: lyarwood: Do you think you could look through https://review.opendev.org/q/topic:%2522bug/1879878%2522+status:open+branch:stable/train this week? The stable/ussuri patches landed some time ago
14:26:29 stephenfin (https://review.opendev.org/q/topic:%2522bug/1879878%2522+status:merged+branch:stable/ussuri for reference)
14:26:44 lyarwood stephenfin: ack, can I trade https://review.opendev.org/c/openstack/nova/+/757894
14:26:55 stephenfin fair
14:27:27 lyarwood stephenfin: FWIW you were previously +2 on this but I can't see the vote since the upgrade

Earlier   Later