Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-07
13:26:15 efried sean-k-mooney: Or would it be sufficient in that case to say "no CPU affinity" and just let 'em spread out?
13:26:35 sean-k-mooney efried: no in the flavor extraspec you can specify how many cpus are assigned to each virtual numa node
13:26:56 efried sean-k-mooney: By what, naming the NUMA node?
13:27:17 efried So you could still get away with something that finicky using traits.
13:27:31 efried You could even do it so you didn't necessarily have to target a specific host, possibly.
13:27:40 sean-k-mooney efried: nameing the virtual numa nodes we have a nodeX sysntax where X is an integer starting at 0
13:27:57 sean-k-mooney the virtual number has no baring in phyical numa nodes on the host
13:28:02 efried sean-k-mooney: Just so - use a trait for that, plus granular request groups, and you can get away with that.
13:28:17 efried sean-k-mooney: You wouldn't use the affinity concept at all in that case.
13:28:46 sean-k-mooney efried: you would use affinity to tie memory form a numa node to cpus for a numa node
13:29:41 sean-k-mooney e.g. 8 vpcu with 2G or ram guset with 2 numa nodes each with 4 cores and 1G of ram
13:29:44 efried sean-k-mooney: I have to run, but would you mind scribbling down a concrete use case or two for this?
13:30:23 efried I want to make sure we can cover it one way or the other.
13:30:52 cdent (more scribbling)++
13:31:03 sean-k-mooney efried: sure stephenfin may have more to had but ill try to add a few flavor exampels to an eterhpad
13:31:11 efried Thank you
13:33:31 openstackgerrit Merged openstack/nova master: placement doc: Conflict caveat for DELETE APIs https://review.openstack.org/540919
13:35:19 sean-k-mooney efried: this is one of the multi-numa flavor i use for my own testing http://paste.openstack.org/show/664744/
13:36:20 efried sean-k-mooney: Roger that. I'll have some questions about it later on. gtg
13:37:19 sean-k-mooney efried: ill use that as a base however that is not the best example as i am depending on alot of implict behavor. ill work on smaples here https://etherpad.openstack.org/p/multi-numa-samples-for-placement talk later o/
13:38:45 jianghuaw bauzas, gibi May you help to look at this support matrix doc for vGPU? https://review.openstack.org/#/c/540808/
13:39:12 jianghuaw Hope it's not late for rc1.
13:39:14 jianghuaw thanks.
14:26:45 ameeda mriedem: I still need +2w here https://review.openstack.org/#/c/528385/. can you please help ?
14:27:32 bauzas jianghuaw: will look today, promised.
14:28:34 jianghuaw bauzas, thanks very much:-)
14:31:27 openstackgerrit Jacek Tomasiak proposed openstack/python-novaclient master: Fix listing of instances above API max_limit https://review.openstack.org/534222
14:32:23 openstackgerrit Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289
14:32:31 openstackgerrit Takashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller https://review.openstack.org/347289
14:32:38 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728
14:32:53 hrw bauzas: please take a look
15:20:42 kashyap sean-k-mooney: Wonder if you have thoughts on my last two comments on the design here: https://review.openstack.org/#/c/497457/18
15:20:45 kashyap (No hurry.)
15:27:00 mriedem o/
15:27:54 cdent o/
15:28:46 openstackgerrit Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728
15:28:52 hrw http://logs.openstack.org/28/541728/1/check/build-openstack-sphinx-docs/7a3bf19/html/user/support-matrix.html is nice. had no idea that zuul will make it available
15:28:56 lyarwood \o morning
15:30:20 dansmith mriedem: so we just merged another compute rpc bump that breaks my patches
15:30:28 dansmith mriedem: surely we should be in lock down for that except for critical bits
15:30:33 stephenfin ltomasbo: Two comments left on https://review.openstack.org/#/c/540679/
15:30:42 stephenfin Ooops, lyarwood ^
15:30:45 stephenfin Sorry ltomasbo :)
15:31:21 ltomasbo :D
15:31:43 mriedem dansmith: it was likely gibi's evacuate late affinity check bug patch,
15:31:48 dansmith yup
15:31:48 mriedem which we wanted to get in since we can't backport it
15:32:08 mriedem that's the last thing i'm aware of
15:32:22 dansmith mriedem: ack, well, it broke a lot of stuff I just got done fixing, so I want to make sure we're done before I fix this again
15:33:09 mriedem i'm not aware of any other patches for rc1 that require rpc version bumps
15:33:38 dansmith okay
15:34:18 kashyap dansmith: Something less grumbly: As 'promised', I've spent a couple of hours this morning digging into the 'bandwidth' parameter. I also got the source reviewed by 2 upstream libvirt devs. Noted the review. Refer my latest two comments on the change: https://review.openstack.org/#/c/497457/
15:34:29 dansmith kashyap: I've already replied
15:34:37 kashyap Ah, didn't even see yours!
15:34:52 kashyap dansmith: So here's even _more_ source-code deep dive discussion with Eric Blake, on that parameter: https://kashyapc.fedorapeople.org/virt/libvirt-bandwidth-API-parameter.txt
15:35:09 kashyap I cleaned up IRC conversation with Eric (libvirt / QEMU dev) on OFTC. And posted it there.
15:35:32 kashyap I learnt interesting things. I'm going to post an upstream libvirt API doc. These semantics should be documented.
15:35:35 dansmith kashyap: yep, the line of code sahid quoted makes it pretty clear which takes precedence
15:35:59 kashyap Eagle eyes there
15:37:52 kashyap So, your suggestion is also reasonable to me (instead of flipping the sequence of calls). Just setting it first, and run it _without_ setting the bandwidth parameter
15:41:57 kashyap Ah, I said the samething as you in the psuedo code - i.e. not supply the 'bandwidth' parameter on the second call.
15:43:05 lyarwood stephenfin: thanks updated, we don't do anything with the return in both cases.
15:44:48 stephenfin ltomasbo: Sweet. +2 from moi
15:47:39 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: wip: minimal qemu/libvirt for aarch64 https://review.openstack.org/541756
15:50:02 stephenfin Anyone want to introduce some of that NUMA goodness into their day? Could do we another set of eyes on https://review.openstack.org/#/c/537363/ and the patches either side of it
15:52:45 mriedem efried: on https://bugs.launchpad.net/nova/+bug/1747511 - i was thinking, could we maybe try to rule out glanceclient as being an issue by doing a straight image API request to GET /images/{image_id} using KSA?
15:52:45 openstack Launchpad bug 1747511 in OpenStack Compute (nova) "server create fails with "Can not find requested image" when CONF.glance.api_servers is not set and [service_user] is set" [High,Confirmed]
15:53:36 hrw mriedem: maybe 3.6.0 libvirt a bit high but it is first version which worked nicely with nova without any extra changes
15:54:16 efried mriedem: Yeah, mordred would love you for that.
15:54:24 mriedem hrw: my point in that comment was i don't think docs is good enough, which is why we have the min version check per arch when the driver starts up
15:54:42 mriedem efried: i was thinking that /v2/v2/images thing is the issue as you pointed out, but you said it shouldn't be
15:54:45 hrw mriedem: sure.
15:55:02 hrw mriedem: the docs patch is something to start with
15:55:02 mriedem hrw: obviously introducing a min version check like that in the code would require an upgrade release note
15:55:04 efried mriedem: I said what?
15:55:12 mriedem hrw: i'd do it in the same patch
15:55:27 mriedem efried: i thought you said that glanceclient bug where the double versions are in the URL wouldn't be an issue for our ksa adapter code
15:55:43 hrw mriedem: you mean supportmatrix docs + min libvirt + relnote?
15:55:45 mriedem if that's definitely the issue, then we can try to see if the direct-to-ksa request would be better
15:55:48 efried mriedem: I thought that *was* the issue. But looking at the results from the latest runs, I'm not as sure. I was going to ask you to glance (hah) over them and see how they compared to yours.
15:55:50 mriedem hrw: yesh
15:55:53 hrw mriedem: ok
15:56:10 mriedem efried: link?
15:57:13 efried mriedem: https://review.openstack.org/#/q/owner:%22Eric+Fried+%253Cefried%2540us.ibm.com%253E%22+project:openstack/nova+dnm+debug+nova-next
15:58:32 mriedem efried: i don't think those nova patches are actually running with https://review.openstack.org/#/c/541431/ since it's not a src job
15:58:44 mriedem i.e. i think the nova CI results are only using the u-c version of ksa, not that patch
15:58:58 efried They changed that recently, I thought.
15:59:00 mriedem legacy-tempest-dsvm-neutron-src on the ksa patch is what you'd want
15:59:05 mriedem hmm
16:02:10 mordred efried, mriedem: just reading scrollback - yes, I think you should stop using glanceclient.
16:02:34 mordred efried, mriedem is there a thing I can help debug?
16:03:25 mriedem https://bugs.launchpad.net/nova/+bug/1747511
16:03:26 openstack Launchpad bug 1747511 in OpenStack Compute (nova) "server create fails with "Can not find requested image" when CONF.glance.api_servers is not set and [service_user] is set" [High,Confirmed]
16:03:35 mriedem https://review.openstack.org/#/c/541008/
16:03:56 mriedem ^ shows that when nova uses ksa to find the image endpoint (rather than CONF.glance.api_servers), and [service_user] tokens,
16:04:07 mriedem we get an image endpoint url like image/v2/v2/
16:04:37 mriedem http://logs.openstack.org/08/541008/2/check/legacy-tempest-dsvm-neutron-nova-next-full/f24c9d2/logs/screen-n-api.txt.gz#_Feb_05_21_46_51_455934
16:05:10 mriedem http://logs.openstack.org/08/541008/2/check/legacy-tempest-dsvm-neutron-nova-next-full/f24c9d2/logs/screen-g-api.txt.gz#_Feb_05_21_46_51_651885
16:05:25 mriedem GET /v2/v2/images/d5659eaf-1c56-4b35-970b-229a91b84bbd
16:05:30 mordred yes. you cannot find a proper endpoint and then pass it to glanceclient

Earlier   Later