Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-29
15:28:13 mriedem i remember the answer
15:28:31 kashyap mriedem: Heh, not trying to "circumvent" anything!
15:28:43 kashyap Wanted to double-confirm. Something about "assume good intent"?
15:29:05 bauzas to the audience, keep in mind that if you tell to a French folk "I like you, but you're bad", there is a very strong meaning https://review.openstack.org/#/c/547990/16/nova/scheduler/client/report.py@341
15:29:37 bauzas tl;dr: the "but" litterally cancels what you just said before
15:29:58 mriedem that means the same thing in english
15:30:08 mriedem "i like you, but we're breaking up"
15:30:27 mriedem "you're a valuable member of the team, but...."
15:31:16 dansmith kashyap: keeping the patch small is good, but not generally at the expense of tests
15:31:29 dansmith kashyap: when in doubt, cut down the four-page release notes :)
15:31:30 kashyap dansmith: Okido; I'll shut up and get that going. :-)
15:31:49 kashyap dansmith: Actually, most of that info belongs in the config option help text
15:31:59 kashyap dansmith: But, yes. I trimmed it
15:32:26 kashyap dansmith: Wonder if you could cut some slack, English is my 3rd language, much as I love it :P
15:32:40 bauzas mriedem: what's interesting is that 'but' in english can mean "except that one"
15:32:50 bauzas mriedem: while we don't have that one in French
15:33:02 bauzas it's another word
15:33:03 edleafe alex_xu_: jaypipes: sorry, meeting time. Would love to continue our etherpad conversation, but...
15:33:11 bauzas hah
15:33:15 openstackgerrit Eric Fried proposed openstack/nova master: Fix N332 api_version decorator hacking check https://review.openstack.org/557743
15:33:17 efried mriedem: ^
15:33:20 bauzas edleafe: good usage of "but" :p
15:33:24 kashyap bauzas: Speaking of French and English; do you know this: "How a Mistake Gave Us the Word 'Cherry'" -- https://www.merriam-webster.com/words-at-play/cherry-history-origin
15:33:25 bauzas right on time
15:33:38 alex_xu_ edleafe: np, my brain doesn't work also
15:34:21 jaypipes alex_xu_, edleafe: do we have something that can be standardized in os-traits that represents the things that an FPGA is *capable* of programming? For example, in vGPU land, we have the VGPU_RESOLUTION_XXX traits and VGPU_MAX_DISPLAY_HEAD traits etc.
15:34:55 edleafe jaypipes: dunno - that would be a good question for the FPGA vendors
15:36:05 efried bauzas: Would you mind casting your eye upon https://review.openstack.org/#/c/557508/ ?
15:36:17 bauzas if that's only one eye
15:36:20 bauzas I can blink
15:37:02 bauzas efried: CC'd
15:37:04 efried acceptable
15:37:12 bauzas efried: just focusing on dansmith's series
15:37:18 bauzas but then I can help
15:37:21 efried thanks
15:37:24 mriedem bauzas: ever word in english has at least 3 different meanings
15:37:45 mriedem *every even
15:37:47 efried holy shit, I just looked back at that etherpad.
15:37:48 bauzas efried: food for thoughts too https://review.openstack.org/#/c/557065/
15:37:56 bauzas efried: since you asked me about that
15:38:02 efried bauzas: ack
15:38:09 efried brb...
15:38:11 bauzas I'm not a big fan of a nova-manage command just for that
15:38:36 bauzas if one day libvirt provides the API to set this, then we would deprecate the conf option
15:38:55 bauzas while a nova-manage command for a very specific libvirt hack makes me worried by the precedence
15:42:57 bauzas gibi: happy travels
15:43:45 cdent happy honeymoon gibi
15:45:14 melwitt o/ gibi
15:49:08 alex_xu_ jaypipes: FPGA_FUNCTION_X,y,z, I guess
15:49:24 alex_xu_ jaypipes: and I thought we should have a trait FPGA_DEVICE_PRE_PROGRAMMED
15:49:38 openstackgerrit Mathieu Gagné proposed openstack/nova master: Fix rebuild of baremetal instance when vm_state is ERROR https://review.openstack.org/523559
15:53:47 dansmith mriedem: to use osc-placement do I have to tell osc to use a specific microversion?
15:54:12 dansmith getting "Operation or argument is not supported with version 1.0"
15:54:59 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Fix bad management of _TRAITS_SYNCED flag https://review.openstack.org/557722
15:55:34 openstackgerrit Merged openstack/nova stable/queens: add check before adding cpus to cpuset_reserved https://review.openstack.org/557621
15:55:55 mriedem dansmith: yup
15:56:02 mriedem osc doesn't default to latest like nova cli does
15:56:31 dansmith yeah I found it
15:56:35 jaypipes gibi: congrats again and have a great time on your honeymoon, man :)
15:57:16 mriedem get used to always being wrong
16:10:27 openstackgerrit Dan Smith proposed openstack/nova master: Documentation for tenant isolation with placement https://review.openstack.org/557490
16:10:42 dansmith mriedem: wanna glance at this ^ before I shut down my devstack node I used to generate the command outputs?
16:18:34 mriedem please hold
16:18:40 efried dansmith, jaypipes, edleafe, cdent, bauzas, alex_xu_: I'm caught up on the etherpad now. I think there's actually agreement on the salient points. The discussion of "capable of X" versus "flashed with X" is orthogonal. (Still relevant, still needing discussion, but the outcome doesn't affect the rest.) Good if I summarize and respond on the ML?
16:18:42 mriedem https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/hypervisor.html#hypervisor-list
16:18:45 mriedem dansmith: let's use osc
16:18:54 dansmith mriedem: it doesn't show id
16:19:05 mriedem --os-compute-api-version 2.53
16:19:13 dansmith I also thought we were still recommending novaclient for admin things?
16:19:42 edleafe efried: the problem was that jaypipes strongly objected to the "capable of X" traits
16:19:48 dansmith also the long --foo-version things really muck up the output, just by the way
16:19:51 mriedem i've got a guy here for some stuff so need to be afk for a bit
16:20:00 jaypipes efried: I'm fine with you summarizing on the ML, though it does seem from the etherpad that there are still a number of things that are still not agreed on.
16:20:03 mriedem you can set an env var early if you want
16:20:05 efried edleafe: I'm saying that discussion is tangential
16:20:12 mriedem export OS_COMPUTE_API_VERSION=2.53
16:20:49 dansmith well, that makes them less copy/pasteable in isolation
16:20:53 dansmith just saying, it's annoyiung
16:23:20 melwitt lyarwood: can you pls remove the -W on this? https://review.openstack.org/#/c/550498/ queens change merged
16:23:39 lyarwood melwitt: done
16:23:44 melwitt woot thanks
16:26:19 openstackgerrit Dan Smith proposed openstack/nova master: Documentation for tenant isolation with placement https://review.openstack.org/557490
16:26:25 dansmith mriedem: like that ^ ?
16:43:39 efried edleafe, jaypipes: You'll notice I neatly sidestepped the issue of "capable-of-X" vs "has-X" traits :P
16:45:05 edleafe efried: in meeting - will read soon
16:47:03 jaypipes efried: still trying to get through all the reading...
16:47:08 jaypipes efried: on the ML post.
16:49:29 dansmith I'm not sure what to comment on at this point, maybe we need to re-summarize at the top again with the feedback and iterate?
17:10:58 mriedem dansmith: yup, thanks. comments inline
17:17:00 efried dansmith: If you're talking about the etherpad, I summarized on the ML already.
17:19:11 melwitt nice job on those, good stuff
17:30:27 jmlowe_ of ports and a no network found error
17:30:27 jmlowe_ I'm hunting down kind of a strange problem, the initial symptom is that the addFixedIp server action returns 202 but the fixed ip is never really added, I go digging and I find "Network could not be found for instance" in the logs of the compute node, further digging reveals that the device_owner of the port is compute:zone-r7 and it is filtered because the availability zone of the instance is zone-r2 leaving an empty list
17:32:56 jmlowe_ I'm left with 3 questions, why isn't the port device_owner updated during unshelve, why does the port have to match the AZ of the instance and not just the instance and network id, are there any open bugs for this because this is nearly impossible to search for
17:34:12 efried jmlowe_: The only part of that I can address is the 202, which means "I understand your request; now I'm going to go away and process it asynchronously." So it's not a bug that you got 202 but the thingy ultimately failed.
17:35:12 jmlowe_ That's what I figured, in a perfect world the application would move on to higher microversions and interact with neutron
17:37:25 jmlowe_ The quick and dirty patch would be to eliminate device owner as a search opt leaving device_id and network_id, but I don't understand the logic of having it so I may be missing some subtlety about why it's there
17:39:58 jmlowe_ https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1459
17:40:38 mriedem jmlowe_: it's likely an old ass bug in shelve where the device_owner isn't cleared
17:40:47 jmlowe_ Yea!

Earlier   Later