Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-08
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 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:39 bauzas gibi: I just +2d the whole series with comments
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 openstackgerrit Andreas Jaeger proposed openstack/nova-specs master: Cleanup py27 support https://review.opendev.org/718368
09:53:22 gibi True
09:53:24 gibi (Pdb) att['delete_on_termination']
09:53:27 gibi 'False'
09:53:29 gibi (Pdb)
09:53:42 gibi and ovo converst the non empty string ('False') to True automatically

Earlier   Later