| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-18 | |||
| 13:30:38 | sean-k-mooney | moshele: cool i just wanted to reach out as i do check the result but i also dont block patches if the melonox ci fails and i can determin the failure was unrelated to the current patch as it is in this case | |
| 13:34:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api-ref: 'vcpus_total' doesn't reflect overcommit ratio https://review.openstack.org/611604 | |
| 13:36:32 | stephenfin | jaypipes, mriedem: Would it ever make sense to remove the vcpus_used, vcpus_total from the hypervisor APIs, given that placement can do this stuff for us now? They're very misleading ^ | |
| 13:38:52 | openstackgerrit | Merged openstack/nova-specs master: Update pypi url to new url https://review.openstack.org/582092 | |
| 13:40:01 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use assertRegex instead of assertRegexpMatches https://review.openstack.org/611608 | |
| 13:43:21 | lennyb | moshele, sean-k-mooney I am rechecking the issue | |
| 13:45:04 | mriedem | stephenfin: we've talked about it, and at the last ptg too | |
| 13:45:10 | mriedem | or just have that API proxy to placement | |
| 13:47:41 | stephenfin | mriedem: This is the "What does shared storage provider support in nova give us? What does it fix?" section, I assume? | |
| 13:48:37 | mriedem | yes | |
| 13:49:05 | sean-k-mooney | stephenfin: perhaps. we did discuss it in the context of the local_gb field but we also disucssed should we just remove the hypervior api or as mriedem said make be a proxy to the relevent data from plancement in the future | |
| 13:49:41 | stephenfin | My next question was "I thought we don't do proxies any more", but I do vaguely recall a discussion about how this was special. Maybe that was something else though. Is it special? | |
| 13:50:53 | mriedem | it's definitely low priority | |
| 13:51:06 | sean-k-mooney | stephenfin: i would personally prefer to deprecate, document how to query placement for the same infor and remove but is it special. i am sure it is to somemone but i dont think its a vital api | |
| 13:51:25 | mriedem | dansmith: your +W awaits https://review.openstack.org/#/c/611084/ | |
| 13:51:52 | dansmith | mriedem: my +W waits for no man | |
| 13:52:48 | stephenfin | mriedem: ack, just curious after awaugama's struggles yesterday | |
| 13:52:59 | sean-k-mooney | stephenfin: by the way for https://review.openstack.org/#/c/611604 that is expected | |
| 13:53:36 | mriedem | stephenfin: so what's the tl;dr on that? the vcpus_used/total was a red herring? | |
| 13:53:41 | stephenfin | sean-k-mooney: Expected but not documented, from what I could see. Best to document these things | |
| 13:54:23 | stephenfin | mriedem: I actually don't know. I haven't checked in with him yet today. awaugama? | |
| 13:54:27 | sean-k-mooney | that the field that report how many hypervior cpus you have is not multipled by an over commit | |
| 13:55:08 | stephenfin | sean-k-mooney: Yeah, I know. That's why I'm seeking to explicitly call it out :) | |
| 13:55:40 | stephenfin | (I didn't know that before yesterday as it doesn't matter for dedicated cores) | |
| 13:56:20 | awaugama | mriedem, stephenfin: waiting to sync with bauzas to go over it | |
| 13:56:33 | sean-k-mooney | stephenfin: but you are adding noise... fine but a more meaningful addtion would be to expcitly point or this corresponds to the number of phyical threads availbale on the hyperviors | |
| 13:58:49 | stephenfin | sean-k-mooney: Those would make for some good review comments :) | |
| 13:59:23 | mriedem | i left some | |
| 13:59:51 | sean-k-mooney | stephenfin: i was trying not to have to leave a -1 but ok ill add them | |
| 14:00:15 | mriedem | nova meeting time | |
| 14:00:16 | gibi | nova meeting is starting in #openstack-meeting | |
| 14:01:27 | bauzas | awaugama: sorry, I'm swamped under multiple internal issues | |
| 14:01:43 | awaugama | bauzas, all good. ping me when you've got a chance | |
| 14:02:05 | bauzas | well, I thought I'd have a chance by this morning but then I got a meeting | |
| 14:02:28 | bauzas | live my life | |
| 14:12:44 | dansmith | mriedem, tssurya: just FYI, I figured out the big weird functional test failure that was hitting the down cell series | |
| 14:12:56 | dansmith | it's in our fixture, luckily, but I need to figure out how to fix it in a way that isn't terrible | |
| 14:13:17 | tssurya | dansmith: you did ?! | |
| 14:13:22 | dansmith | tssurya: yeah | |
| 14:13:31 | dansmith | tssurya: took me a while because I'm slow | |
| 14:13:37 | mriedem | slow but powerful | |
| 14:13:50 | tssurya | I couldn't.. have been at it for some time, then I got busy with some other stuff downstream | |
| 14:13:54 | dansmith | we're racing to double-lock a lock | |
| 14:13:54 | mriedem | that was our AS400 build process name when i started at ibm... | |
| 14:14:21 | dansmith | so I need to make that safe for recursion somehow | |
| 14:16:38 | tssurya | just to be sure dansmith, you are talking abotu these tests right ? http://logs.openstack.org/58/591658/10/check/nova-tox-functional-py35/ab65888/testr_results.html.gz | |
| 14:17:07 | dansmith | tssurya: yep | |
| 14:17:49 | tssurya | great :) thanks a lot for investigating, I wanted to bring it up at some point, but got busy | |
| 15:02:15 | mordred | mriedem: I got this bug: https://bugs.launchpad.net/shade/+bug/1798489 which I believe stems from when we switched to making direct rest calls for create_server ... I'm sure it's my fault... | |
| 15:02:15 | openstack | Launchpad bug 1798489 in Shade "v4-fixed-ip / v6-fixed-ip no longer supported in shade for new vms" [Undecided,New] | |
| 15:02:37 | melwitt | ||
| 15:02:38 | mordred | mriedem: but I was looking for any mentoin of v4-fixed-ip in the api docs and can't find one | |
| 15:02:58 | mordred | I suppose I don't actually need to only talk to mriedem about that :) | |
| 15:02:59 | cfriesen | mriedem: geez, you weren't kidding about a bunch of comments on vTPM | |
| 15:03:18 | mordred | anybody know off the top of their head if that's like an old option or something? | |
| 15:04:54 | mordred | OH - I see it - it's a novaclient thing | |
| 15:11:49 | frickler | mordred: osc has it, too http://git.openstack.org/cgit/openstack/python-openstackclient/tree/openstackclient/compute/v2/server.py#n531 | |
| 15:12:43 | mordred | frickler: yah - so it does. it's just not actually a nova api thing - they all get sent as fixed_ip in the network dict to nova | |
| 15:17:18 | lennyb | moshele, sean-k-mooney both patches passed https://review.openstack.org/#/c/610916/ and https://review.openstack.org/#/c/611017/ | |
| 15:18:09 | sean-k-mooney | lennyb: thanks :) | |
| 15:24:01 | mriedem | mordred: was away - get it figured out? | |
| 15:24:02 | cfriesen | got an interesting bug related to "bus=scsi" that someone else has confirmed....https://bugs.launchpad.net/nova/+bug/1792077 | |
| 15:24:02 | openstack | Launchpad bug 1792077 in OpenStack Compute (nova) "problem specifying multiple "bus=scsi" block devices on nova boot" [Undecided,New] | |
| 15:24:38 | mordred | mriedem: yah- there is an argument novaclient takes that isn't in the rest api that the switch from novaclient to REST lost support for | |
| 15:24:56 | mriedem | ok | |
| 15:27:33 | cfriesen | mdbooth: you might be interested in this ^ | |
| 15:33:55 | mordred | mriedem, frickler: https://review.openstack.org/#/c/611651/ is the fix, just in case you're interested | |
| 15:34:34 | mordred | frickler: I also pushed up an sdk patch for it so that we can support it from osc when we switch over | |
| 15:45:31 | mriedem | melwitt: need this rocky backport https://review.openstack.org/#/c/611327/ | |
| 15:46:02 | melwitt | on it | |
| 15:47:06 | mriedem | we'll likely need a rocky release next week because we have at least 3 upgrade impacting issues | |
| 15:47:41 | melwitt | yeah, I was thinking we'd do the usual and do stable releases for everything along with s-1 | |
| 15:47:48 | mriedem | also need https://review.openstack.org/#/c/611337/ | |
| 15:47:56 | melwitt | unless there's a branch that doesn't have enough stuff in it | |
| 15:48:27 | melwitt | but in general I think a lot goes into the stable branches even in a short-ish time | |
| 15:56:53 | openstackgerrit | Dan Smith proposed openstack/nova master: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_project() https://review.openstack.org/607663 | |
| 15:56:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 15:56:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934 | |
| 15:56:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 15:56:55 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 15:56:56 | openstackgerrit | Dan Smith proposed openstack/nova master: Make CellDatabases fixture reentrant https://review.openstack.org/611665 | |
| 15:57:21 | dansmith | mriedem: that last one there is the fixture change.. would appreciate careful scrutiny | |
| 15:57:36 | dansmith | seems to pass all existing tests and fix the (related) ones in the down cell stuff | |
| 16:02:00 | dansmith | mriedem: on that compute node uuid backport, | |
| 16:02:03 | dansmith | I wanted to go think about it a little | |
| 16:02:55 | dansmith | I thought there were some assumptions that the ironic node uuid was the same as the compute node uuid, so you could correlate the resource provider | |
| 16:02:56 | dansmith | but I also know we use the name (which is the ironic uuid) | |
| 16:03:01 | dansmith | was that all worked out on the original? | |
| 16:03:47 | mriedem | "I thought there were some assumptions that the ironic node uuid was the same as the compute node uuid" has never been the case | |
| 16:04:00 | mriedem | before that change, the compute node uuid was always randomly generated when we created the record | |
| 16:04:07 | mriedem | the compute node hypervisor_hostname is the ironic uuid | |
| 16:05:14 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/compute/resource_tracker.py#L585 | |
| 16:05:27 | dansmith | right | |
| 16:05:27 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/objects/compute_node.py#L312 | |
| 16:05:40 | dansmith | okay I see the breaking change was just a "it would be nice" so.. okay | |
| 16:05:45 | mriedem | yeah | |
| 16:05:49 | dansmith | there was that rebalance bug that was fixed, | |
| 16:05:59 | dansmith | so I wanted to make sure it wasn't related to that, | |
| 16:06:08 | dansmith | but I was deep in that fixture debug so I didn't chase | |
| 16:06:11 | dansmith | so cool enough | |