Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-05
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 ?
15:59:27 sean-k-mooney in that case we already pull back the full neutron port object to check if its an sriov port
15:59:46 sean-k-mooney so you can ask neutron for the physnet and put that in the instance request object
16:00:04 sean-k-mooney you can also determin if its a tunneled/routed port
16:00:31 stephenfin sean-k-mooney: Yup, I've been charting that this afternoon :D http://paste.openstack.org/show/718499/
16:01:06 sean-k-mooney stephenfin: thats how the nic feature based schduling works :)
16:01:27 stephenfin ralonsoh_'s patches?
16:01:31 sean-k-mooney yep
16:01:46 stephenfin (I've been meaning to re-review those but they were failing CI last I checked)
16:02:05 sean-k-mooney we extend the pci requst spec object to carry the feature flags
16:02:59 sean-k-mooney stephenfin: i belive the bandwidth spec was suggestion adding an arry of networkRequstsSepcs to the instance request object
16:03:37 stephenfin I need to reread that one too so. That's exactly what I'd done
16:04:01 sean-k-mooney stephenfin: oh and i started rebasing rodoflos patches yesterday
16:04:18 stephenfin Only, like I said, it seemed useless to me because I didn't want to be querying neutron for more information from the scheduler
16:04:19 sean-k-mooney i hope to have them back up tomrowo or monday
16:04:31 stephenfin sean-k-mooney: Sounds good. I can review once they're done
16:04:35 stephenfin *ready
16:05:22 stephenfin sean-k-mooney: I'll push up what I have probably some time tomorrow
16:05:33 stephenfin Try not to laugh too hard. It's strewn with TODOs :D
16:05:34 sean-k-mooney well i broke them more in the refactor. once they are back passing unuit test i will need to do some more testing with real hardware so they wont be "ready" untill later next week but they can still be reviewed
16:05:54 stephenfin Yeah, that's fine. I can do some basic validation too
16:06:02 stephenfin ...given that I actually have hardware again
16:06:31 sean-k-mooney well im currently doing the rebase work in a vm so need to deploy on real hard ware to test after that is done.
16:12:16 mriedem efried: imacdonn: i've updated https://review.openstack.org/#/c/554577/ to depend on your nova change
16:13:34 efried mriedem: cool
16:30:05 mriedem kashyap: holy wow everything volume-related failed in your patch http://logs.openstack.org/84/534384/24/check/tempest-full/c7c0cbe/
16:30:09 mriedem congratulations on breaking cinder
16:31:03 kashyap mriedem: I suppose you're referring to: https://review.openstack.org/#/c/558783/

Earlier   Later