| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 14:37:39 | sahid | mriedem, stephenfin, can you remove your -2 on ^ - the spec has been accepted and that could help to get more reviews | |
| 14:38:14 | stephenfin | sahid: Sure, done | |
| 14:40:18 | mriedem | sahid: done | |
| 14:40:36 | sahid | thakns | |
| 14:47:29 | openstackgerrit | sahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997 | |
| 14:50:00 | mriedem | efried: setting CONF.neutron.auth_type is going to be required to talk to neutron using ksa right? | |
| 14:50:14 | efried | mriedem: I believe so, yes. | |
| 14:50:17 | efried | uh | |
| 14:50:22 | efried | unless you're going the admin path. | |
| 14:50:31 | mriedem | that's what i was worried about, | |
| 14:50:35 | efried | then you're just using admin auth. | |
| 14:50:45 | mriedem | but if you get here and auth_type is None, http://git.openstack.org/cgit/openstack/nova/tree/nova/network/neutronv2/api.py#n75 | |
| 14:50:48 | efried | which is CONF.something-other-than-neutron.auth_type, I imagine. | |
| 14:50:50 | mriedem | then you've f'cked up right? | |
| 14:51:51 | efried | hum, that code shouldn't be in nova at all. If you had no auth type, that ksa loading shoulda kicked an exception. | |
| 14:52:21 | efried | I'll have to go paw through the ksa code again, gimme a few... | |
| 14:52:22 | openstackgerrit | sahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997 | |
| 14:53:22 | imacdonn | mriedem: on a very-slightly related note; take a peek at https://review.openstack.org/#/c/558089/ when you get a chance | |
| 14:53:53 | efried | Yes, mriedem, ^ is truly excellent work :) | |
| 14:54:02 | imacdonn | :) | |
| 14:55:50 | efried | mriedem: Okay, I was mistaken. No exception; it returns None. https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/conf.py#L122-L124 | |
| 14:56:47 | mriedem | efried: right, ok, point is i'm trying to know if/when i can log something useful in the logs for when you don't configure nova to talk to neutron https://bugs.launchpad.net/nova/+bug/1761487 | |
| 14:56:47 | openstack | Launchpad bug 1761487 in OpenStack Compute (nova) "Nova, Unexpected API Error while creating VM" [Undecided,Invalid] | |
| 14:56:51 | mriedem | we get that same bug at least weekly | |
| 14:58:16 | efried | mriedem: This would be very similar in spirit to what imacdonn noted above. We used to try to determine whether you'd configured placement based on whether [placement]os_region_name was present. Which isn't the best way to do it, because that guy can default - auth_type would have been a better one to check. | |
| 14:58:57 | efried | mriedem: Which leads me to this one: you could have a similar check for neutron config. Though I don't know whether neutron is required to make the world work, so having the check up front may be too aggressive. | |
| 14:59:13 | efried | mriedem: But yeah, you could at least make that error message that you pointed out more clear. | |
| 14:59:44 | efried | mriedem: "You need to configure the [neutron] section of your conf with ksa Adapter options." | |
| 14:59:49 | efried | kind of thing. | |
| 15:00:01 | zigo | o/ | |
| 15:00:02 | mriedem | neutron is required yeah, because we assume port binding is available in neutron and the port binding extension is an admin-only extension by default | |
| 15:00:19 | kashyap | zigo: Hi there ... so to follow-up, all the distributions in the DistroSupportMatrix have libvirt 3.8.0 and QEMU 2.9.0 | |
| 15:00:20 | mriedem | efried: so i'll start small with that kind of log message if we hit this, | |
| 15:00:25 | zigo | I haven't tried backporting libvirt & qemu to Stretch, could you give me some time so I can tell if it's painful or not? | |
| 15:00:27 | kashyap | zigo: This is the wiki: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix | |
| 15:00:29 | efried | mriedem: ++ | |
| 15:00:38 | mriedem | efried: and i also noticed during triage of that bug that our install guide, at least for ubuntu, doesn't tell you that you need to configure nova with neutron creds | |
| 15:00:45 | kashyap | zigo: Sure. Please respond here: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129048.html | |
| 15:00:53 | zigo | Will do. | |
| 15:01:00 | zigo | I should be able to give an answer tomorrow. | |
| 15:01:06 | kashyap | zigo: I spent a couple of hours duking around various Debian packaging URLs & wrote that up | |
| 15:01:09 | kashyap | Thanks! | |
| 15:01:14 | zigo | (today, got 2 hours driving back home from work in Geneva) | |
| 15:01:32 | mriedem | dansmith: https://review.openstack.org/#/c/555416/ is ready to go if you want to re-apply your +2 | |
| 15:01:51 | tssurya | thanks ^^ | |
| 15:05:29 | mriedem | tssurya: unrelated, but would you mind pushing a simple patch to add a .. note:: to http://logs.openstack.org/59/556459/9/check/build-openstack-sphinx-docs/66f4bf4/html/admin/configuration/schedulers.html#cell-filters that those filters are only for cells v1 which is deprecated | |
| 15:06:03 | tssurya | mriedem: sure, looking at it now.. | |
| 15:12:21 | zigo | kashyap: You can just scrap Jessie from your table, it's unsupported already, and maybe add Sid. | |
| 15:12:25 | zigo | That's what counts for me. | |
| 15:12:47 | kashyap | zigo: "Sid" == Testing / unstable, isn't it? | |
| 15:12:55 | kashyap | zigo: Isn't it "Buster" that's the upcoming release? | |
| 15:13:21 | zigo | kashyap: Generally, we have sid == buster, package migrate in 5 days from Sid to Buster if there's no RC bug. | |
| 15:13:31 | kashyap | zigo: "Also ... it's a wiki, feel free to update it" :-) | |
| 15:13:36 | zigo | :) | |
| 15:14:05 | kashyap | zigo: When I checked earlier this week, there was no ETA for Buster (love saying it out loud) | |
| 15:14:32 | zigo | Sure, that's what Debian is about: it's ready when it's ready, no commercial agenda. | |
| 15:14:33 | bauzas | dansmith: mriedem: melwitt: FYI, I had a family loss this week, so I won't be around tomorrow | |
| 15:14:45 | zigo | What's surprising is that there's still no freeze date. | |
| 15:14:46 | kashyap | zigo: Either way, if you see, we're trying to converge on a reasonable least common denonimnator version for libvirt / QEMU across releases | |
| 15:14:54 | dansmith | bauzas: ack :( | |
| 15:14:58 | zigo | I guess the release team has a few more transition to get done before announcing the freeze date. | |
| 15:15:12 | bauzas | hence also me not around this afternoon :( | |
| 15:15:15 | melwitt | sorry to hear that bauzas :( | |
| 15:15:20 | zigo | bauzas: Oh, sorry to read that. Moral support and all... | |
| 15:15:21 | kashyap | bauzas: Take care of that; IRC can wait | |
| 15:15:53 | bauzas | np, it was my grand father who was 91 | |
| 15:19:40 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update the Cell filters section of the scheduler docs https://review.openstack.org/559108 | |
| 15:21:04 | tssurya | mriedem: ^ | |
| 15:25:29 | mriedem | bauzas: ack; making it that long is a feat | |
| 15:26:00 | bauzas | yup, and with a way to leave us quickly without illness | |
| 15:26:10 | bauzas | just because the body stopds | |
| 15:26:21 | bauzas | I just hope everyone can leave the world like him | |
| 15:27:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Log a more useful error when neutron isn't configured https://review.openstack.org/559111 | |
| 15:27:38 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs. https://review.openstack.org/556459 | |
| 15:30:56 | mriedem | tssurya: thanks, +2 | |
| 15:32:59 | mriedem | melwitt: i meant to point this out in the meeting, but i noticed it after the bugs and gate CI part - i saw some very weird and random looking failures in the functional job in what looks to be an unrelated change http://logs.openstack.org/12/555812/5/gate/nova-tox-functional/94dc121/testr_results.html.gz | |
| 15:33:49 | melwitt | hm, that looks plenty weird | |
| 15:36:17 | mriedem | dansmith: was "limestone" the cloud provider that was timing out yesterday? | |
| 15:36:23 | dansmith | mriedem: yar | |
| 15:36:25 | mriedem | because that's the one this functional job above seems to hit | |
| 15:36:28 | mriedem | yeah ok so that's probably all it was | |
| 15:36:31 | mriedem | melwitt: nvm then | |
| 15:37:31 | melwitt | a-ha, cool | |
| 15:42:06 | stephenfin | sean-k-mooney: I recall a blueprint that would allow us to determine what networking backend was running on a host (I guess so you could mix hosts OVS-DPDK and OVS kernel). Got a link, if so? | |
| 15:43:10 | mriedem | stephenfin: wouldn't that information be in the port's host binding details? | |
| 15:46:25 | stephenfin | mriedem: Possibly, but we don't do any of that stuff until we land on a host, far as I can tell | |
| 15:47:01 | stephenfin | Only thing we do do (heh) is prepare a PCIRequest object for any SR-IOV requests | |
| 15:48:04 | stephenfin | bauzas: Sorry to hear it :( | |
| 15:48:34 | bauzas | stephenfin: no worries, it was expected | |
| 15:48:45 | sean-k-mooney | mriedem: that info is not in the port until after binding | |
| 15:49:07 | sean-k-mooney | stephenfin: i dont think it was in a seperat spec but it was part of the bandwith based scheduling spec | |
| 15:49:41 | stephenfin | sean-k-mooney: Hmm, OK. Was hoping I could steal some ideas from said spec | |
| 15:50:05 | sean-k-mooney | the intent was to use traits for neturon extention or backend to select the backend. the trati would be added to the neutron port resouce reuest | |
| 15:50:34 | stephenfin | So you'd be querying placement? | |
| 15:50:40 | sean-k-mooney | stephenfin: well you can proably steal them from the bandwith spec. | |
| 15:50:46 | sean-k-mooney | stephenfin: yes | |
| 15:51:05 | sean-k-mooney | or rather its addtional info that is included with nova queries placement | |
| 15:51:12 | stephenfin | Darn, it all comes back to placement | |
| 15:52:14 | sean-k-mooney | stephenfin: i did have a proposal to do this with a neutron api for network backend capablities in mitaka before placement but that never went anywhere outside intel | |
| 15:52:37 | stephenfin | Yeah, so NUMA stuff. I naturally want to be able to do this stuff in the scheduler but I don't have enough information at that point to make a decision | |