Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-08
09:06:45 gibi bauzas: could you please add you thinking to the etherpad https://etherpad.openstack.org/p/nova-victoria-ptg around L84
09:06:48 stephenfin that's my understanding of it, anyway. gibi can correct me if I'm wrong, though he's probably correct in saying we should wait til after feature freeze to work on this bugfix
09:06:57 bauzas but I'm afraid we would run against client changes if we don't do it
09:07:00 gibi stephenfin: you are correct
09:07:05 stephenfin \o/
09:07:24 bauzas gibi: and the fact that stephenfin takes time to write the client changes instead of the BP owner makes me think that I'm right
09:07:25 gibi stephenfin: I would also add that this bug exists at least since 2017
09:08:01 gibi bauzas: it is not exactly that. the owner wrote a change, we even merged a fixed version of it, stephenfin just has an improvement idea on the CLI interface
09:08:11 bauzas gibi: writing client changes should be the responsibility of the bp owner, not the nova maintainers IMHO
09:08:13 stephenfin bauzas: tbc, the client changes were done. I'm just tweaking it because I didn't like how it was done
09:08:24 bauzas oh ok, then nevermind
09:08:29 stephenfin but my patch is by no means mandatory
09:08:48 bauzas cool then
09:08:54 stephenfin if anything, I'm at fault because lyarwood drafted the novaclient change for *my* series /o\
09:09:22 bauzas again, it's just my personal thoughts, not a policy
09:09:25 gibi bauzas: btw merging the client code before the API version bump means we need to agree what microversion number an API change will take _before_ we merge the API change
09:09:26 bauzas don't take it wrong
09:09:39 lyarwood stephenfin: wait, did I screw that up?
09:09:53 stephenfin lyarwood: no no, it was good, thanks :)
09:10:00 bauzas gibi: when we're close to FF, I feel we somehow organize it already :)
09:10:01 gibi bauzas: I'm not saying we should not do that, I say this will add complexity
09:10:29 stephenfin gibi, bauzas: Yeah, let's bring this up at the PTG. Only two microversions left to go for this cycle, hopefully
09:10:30 gibi bauzas: on the nova side it is by chance, on the client side, it is driven by the allocated microversion
09:10:31 bauzas just because of the potential merge conflicts that would require a Zuul respin
09:10:38 gibi stephenfin: +!
09:10:39 gibi stephenfin: +1
09:10:51 bauzas I can add thoughts on this, not solutions
09:10:54 lyarwood and both are no-ops in the client
09:12:25 lyarwood we all assumed you had farmed some of your work out to your kids ;)
09:12:27 bauzas should I say "please keep me locked down for a while ?"
09:12:33 lyarwood /s
09:13:06 bauzas lyarwood: you can't imagine how you're right : this weekend's TODO : teach 'Scratch' to my 9yo daughter, she wants to
09:13:21 lyarwood that's awesome :)
09:13:57 bauzas she did read children books about girls doing STEM, she now wants to code
09:14:13 bauzas not sure how long it will last tho
09:16:26 bauzas https://www.penguinrandomhouse.com/series/GWC/girls-who-code FTW
09:21:50 bauzas gibi: looking at https://launchpad.net/nova/+milestone/ussuri-3 I only see lyarwood's and gmann's changes requiring reviews, right?
09:22:00 bauzas gibi: other bps aren't marked 'Needs Code review'
09:22:11 bauzas (besides my own BP of course)
09:22:22 gibi brinzhang: something is either wrong with https://review.opendev.org/#/c/712651/15 or with the API code, as I cannot change d-o-t from True to False
09:22:39 gibi bauzas: don't trust Needs Code review field
09:22:47 gibi I'm pretty sure it is not up-to-date
09:23:15 bauzas gibi: I usually don't but other BPs are either implemented or 'Started' but are actually either merged or still WIP :)
09:23:40 gibi bauzas: hm, stephenfin's extra spec validation also open
09:24:21 bauzas of the 3 'Started', one is already got +2 from me, the other one is the 2.85 microversion change we just discussed and the third one is in the gate :)
09:24:39 bauzas gibi: I just +2d the whole series with comments
09:24:39 stephenfin yeah, that's blocked by this tempest change. I'm hoping gmann can expedite it today https://review.opendev.org/#/c/707223/
09:24:45 gibi bauzas: cool
09:25:06 bauzas either way, jumping to lyarwood's then
09:25:24 gibi I got pinged about the https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/use-pcpu-and-vcpu-in-one-instance too
09:25:37 gibi bauzas: yeah, lyarwood should be close
09:25:40 gibi bauzas: thanks
09:25:51 gibi I mean lyarwood's
09:25:58 bauzas gibi: want me to look at https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/use-pcpu-and-vcpu-in-one-instance too ?
09:26:40 gibi bauzas: honestly I don't know if it still has a chance to land, there is a lot of patches there
09:26:50 bauzas that's what I see
09:27:02 gibi and I haven't really followed the series so I have no context how complex it is
09:27:15 gibi gmann's policy patches are fairly simple in the other hand
09:27:39 stephenfin I'm happy to keep reviewing the policy patches, if you could take a look at the pcpu-and-vcpu one, bauzas
09:27:49 stephenfin fwiw, the complexity is only in the last two patches or
09:27:51 stephenfin ....so
09:28:04 gibi also there is https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/unified-limits-nova I started reviewing lately but I had no time to get back to it and re-review
09:28:10 stephenfin the rest is an attempt to make that code readable :(
09:28:20 stephenfin it's so, so bad
09:29:24 bauzas ok, entering the frightening tho exciting world of mystery that are volume-backed instances
09:29:31 bauzas lyarwood: ^
09:30:11 bauzas stephenfin: okay, then you're next in my queue after bfv rescuse
09:30:14 bauzas rescue*
09:30:38 openstackgerrit Stephen Finucane proposed openstack/nova master: Follow-up for flavor-extra-spec-validators series https://review.opendev.org/718357
09:30:59 bauzas stephenfin: I'd appreciate some reading of https://review.opendev.org/#/c/715489/
09:31:06 bauzas (btw.)
09:31:33 bauzas bonus stage : https://review.opendev.org/#/c/717975/8
09:32:24 lyarwood bauzas: I've got that open at the moment btw, taking a while as I've never looked at vGPU stuff before.
09:32:52 bauzas lyarwood: that's the reason why I invested a bit of time on functionally testing the feature https://review.opendev.org/#/c/717975/
09:33:31 bauzas worth reading the last bit, fresh as of this night.
09:34:13 lyarwood ack thanks
09:37:31 brinzhang gibi: seem like you missed the "--os-compute-api-version 2.85" in you CLI
09:37:45 gibi brinzhang: hm, interesting
09:37:47 gibi checking...
09:38:02 gibi nova client should default to max microversion
09:38:10 gibi and False to True worked
09:38:15 gibi but let me double check it
09:38:52 brinzhang Emm..interesting..
09:40:41 gibi brinzhang: here is a repro http://paste.openstack.org/show/791792/
09:41:05 gibi False -> True works, True -> False seems to be ignored
09:42:13 gibi let's try to attach a debugger
09:42:27 brinzhang gibi: looks like the phenomenon is not in nocalient
09:42:51 gibi you mean, this a potential bug in the nova API change?
09:43:23 brinzhang gibi: I am not sure, I will rebuild my env, I think it's not fast
09:43:43 gibi OK, I'm also looking into this in parallel with you
09:43:51 gibi I will let you know if I found something
09:44:58 brinzhang "False -> True works, True -> False seems to be ignored", that from False to True works, and I reviewed again in novalient code, it's ok for me, so I am not sure whether is it have something in nova API
09:47:26 openstackgerrit Mikhail Ushanov proposed openstack/nova stable/ocata: Support qemu >= 2.10 https://review.opendev.org/693851
09:53:14 gibi brinzhang: it seems to me that converting from the 'False' string to boolean is missing from the API code
09:53:17 gibi (Pdb) bdm.delete_on_termination = att['delete_on_termination']
09:53:19 gibi (Pdb) bdm.delete_on_termination
09:53:22 gibi True
09:53:22 openstackgerrit Andreas Jaeger proposed openstack/nova-specs master: Cleanup py27 support https://review.opendev.org/718368
09:53:24 gibi (Pdb) att['delete_on_termination']
09:53:27 gibi 'False'

Earlier   Later