| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 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 | openstack | Launchpad bug 1761487 in OpenStack Compute (nova) "Nova, Unexpected API Error while creating VM" [Undecided,Invalid] | |
| 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: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 | |
| 15:52:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: add a link in the install guides about configuring neutron https://review.openstack.org/559115 | |
| 15:53:03 | stephenfin | I can figure out what network I have but then I need to map that network to a given NUMA node | |
| 15:53:39 | stephenfin | and that information lives on each individual host, either as a configuration option or something else | |
| 15:53:55 | sean-k-mooney | stephenfin: well you can have enough info in the schduler if you populated it in the host state object. placement does not know about it however unlees the compute agent puts it in placement too | |
| 15:54:13 | stephenfin | so it looks like I'm going to have to pass it back to the scheduler via the host state object, which I'm not sure I want to do | |
| 15:54:21 | stephenfin | sean-k-mooney: yup, exactly | |
| 15:54:28 | sean-k-mooney | stephenfin: i had assumed you were going to addd the network stuff to the numa topology blob | |
| 15:55:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: add a link in the install guides about configuring neutron https://review.openstack.org/559115 | |
| 15:55:49 | sean-k-mooney | so the compute agent would read the config opptions and populated the numa info for the backend into the numatopology blob then the numa topology filter which gets that blob in the host_State object can make desions about the host | |
| 15:57:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs. https://review.openstack.org/556459 | |
| 15:57:43 | stephenfin | sean-k-mooney: Hmm, I hadn't considered that. I'd been adding additional fields and then got stuck because I had a network from the user and physnet name from the host | |
| 15:57:54 | sean-k-mooney | stephenfin: your only other option bar modleing it in placement which is the long term answer is to not scheduler based on the numa constriats and retry if you cannont fit the insance on the compute node that was selected | |
| 15:57:55 | stephenfin | *I had considered that but... | |
| 15:58:41 | sean-k-mooney | stephenfin: well you have more then the network | |
| 15:58:58 | sean-k-mooney | your stuff assumed that the vm was booted with a nuton port | |
| 15:59:10 | stephenfin | so network and port IDs | |
| 15:59:11 | stephenfin | ? | |