| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-29 | |||
| 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! | |
| 17:40:49 | mriedem | when you unshelve, the instance is re-created on a new compute node | |
| 17:40:53 | mriedem | which could be in some other AZ | |
| 17:41:45 | jmlowe_ | correct, I believe that's what I'm seeing, I haven't followed the code to find the place where it should be updating | |