Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-03
14:33:27 openstackgerrit Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448
14:33:28 openstackgerrit Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632
14:33:32 jaypipes mriedem: pulled in master ^^
14:33:45 jaypipes mriedem: I think that func test failure is fixed.
14:33:45 sfinucan moshele: Kind of. That's for PCI devices, but would that include VF devices?
14:33:47 sfinucan I guess
14:33:51 jaypipes mriedem: will see in about an hour ;)
14:33:58 sfinucan * I assume it would, but I'm not sure
14:34:00 moshele sfinucan
14:34:00 moshele moshele
14:34:06 mriedem jaypipes: ok i can hunt for a recent change related to that
14:34:11 mriedem unless edleafe- can point it out quick
14:34:12 moshele sfinucan: yes it is the same code
14:34:21 jaypipes mriedem: gimme a sec.
14:34:31 moshele sfinucan: VF is eventually a pci device
14:35:02 jaypipes mriedem: edl
14:35:08 jaypipes mriedem: edl
14:35:11 jaypipes oh ffs.
14:35:18 jaypipes https://review.openstack.org/#/c/478564/
14:35:20 jaypipes mriedem: ^^
14:35:28 jaypipes `damn paste buffers.
14:35:29 sfinucan moshele: Right, that's what I thought. However, I've an instance with an OVS-DPDK-managed PCI device on node 1, and it's booting on node 0
14:35:44 sfinucan Must be something to do with OVS-DPDK aspect of it, and how it's being attached to the instance
14:35:47 mriedem jaypipes: oh nice
14:35:49 mriedem whew
14:36:15 moshele sfinucan: did you puth the numa filter ? and what libvirt verions are you using?
14:36:48 jaypipes back in a bit.
14:37:26 sfinucan moshele: I'm not doing it personally, but I'd assume you'd need that filter for things to even boot. I will ask though
14:38:23 sfinucan fwiw, all the logs are here. I'm guessing it's accessible outside RH? https://bugzilla.redhat.com/show_bug.cgi?id=1459543
14:38:23 openstack bugzilla.redhat.com bug 1459543 in openstack-nova "Virt NUMA placements on NUMA1 using flavor extra specs - places Virt guest on NUMA0" [Medium,Assigned] - Assigned to sfinucan
14:38:23 mriedem jaypipes: fix this up and i'll +W the change https://review.openstack.org/#/c/475448/23/nova/api/openstack/placement/rest_api_version_history.rst
14:40:14 sfinucan mriedem: Per openstackstatus above, would appreciate reviews on this series to get those redirects working --> https://review.openstack.org/#/q/topic:doc-migration+project:openstack/nova
14:40:34 sfinucan At least, I _think_ that means we need to do those now to fix those build
14:41:57 mriedem yeah probably
14:43:16 mriedem sfinucan: sdague isn't around but you guys are going to need to sort out https://review.openstack.org/#/c/478468/ which is the bottom change in your series
14:44:11 sfinucan mriedem: Damn. I think I can kick that to the end. The rest should be a-OK
14:44:35 moshele mriedem: hi, now that https://review.openstack.org/#/c/478923/ is merge how do I update the requirement file? is it done automatically
14:45:11 sfinucan moshele: Looks like they're using libvirt 2.0 but they don't have the NUMA filter on. I'll ping em. Thanks for the tip :)
14:45:36 sfinucan AR me: Put note that NUMA affinity is supported in the SR-IOV admin guide
14:45:53 mriedem moshele: you have to update the global-requirements file in the openstack/requirements repo
14:46:04 mriedem moshele: this https://github.com/openstack/requirements/blob/master/global-requirements.txt#L161
14:46:13 mriedem and the related entry in upper-constraints in that same repo
14:46:36 mriedem moshele: once it's merged in global-requirements it will get auto-synced to nova
14:47:37 moshele sfinucan: np :)
14:48:03 moshele mriedem: cool thanks
14:49:16 sfinucan Yup, Googling for openstack-docs is not a thing atm :'(
14:58:14 openstackgerrit Jay Pipes proposed openstack/nova master: placement: scheduler uses allocation candidates https://review.openstack.org/476631
14:58:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448
14:58:15 openstackgerrit Jay Pipes proposed openstack/nova master: WIP - placement: claim resources in scheduler https://review.openstack.org/476632
14:58:17 jaypipes mriedem: done.
15:00:13 mriedem thanks, +W
15:02:09 sean-k-mooney jaypipes: o/ since your about just wanted to run something past you regrading the traits api. what would your opipion be on extending traits to allow tag that are key value pairs with stardadised keys? e.g. standardised HW_CPU_FREQUENCY key with integer or string value field
15:02:33 jaypipes sean-k-mooney: I would be opposed to that.
15:02:46 sean-k-mooney ok good to know :)
15:03:24 jaypipes sean-k-mooney: what would the CPU frequency be used for w.r.t. scheduling?
15:03:29 mriedem jaypipes: alex_xu: that reminds me, something that came up in shenzhen last week, and i'm sure there is a reason for it, but why don't we allow traits on resource provider aggregates?
15:03:53 mriedem we have talked about a distance trait on an aggregate
15:03:55 mriedem for affinity
15:03:59 jaypipes mriedem: because the aggregates are simply groups of resource providers. they aren't things in and of themselves.
15:04:47 mriedem ok this question was coming from some guys doing baremetal, i'm not exactly sure what the use case was though, so i'd have to follow up
15:04:56 jaypipes mriedem: you mean Mogan? :)
15:05:10 sean-k-mooney jaypipes: for latence reasons i may not want to secheld to a node with a specific frequence below X but it more useful for adative power management. where i coudl declare teh maxium and minium frequence support by a specic cpu
15:06:04 jaypipes sean-k-mooney: I think that kind of things is probably best left as a custom trait that you decorate a provider with.
15:06:20 jaypipes sean-k-mooney: CUSTOM_HIGH_FREQUENCY_CPUS or similar.
15:07:19 sean-k-mooney jaypipes: yep that is an option though i was just concerend that it might result in a lot of traits. that said they are just db row so not exeaclty the most expencive things in the world to create
15:08:21 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285
15:09:23 sean-k-mooney there are a few other resouces capablityes that i can think of such as disk iops that would be better mapped with a key and value then just a lable but lables can still be used
15:11:07 mriedem jaypipes: yeah related
15:11:19 mriedem jaypipes: but they had some other things for nova+ironic, which is what we run in the public cloud
15:11:54 mriedem which leads me to other nova vm+bm questions for ops for johnthetubaguy
15:13:14 sean-k-mooney mriedem: are the bm guys perhapss modeling multi node chassies as a aggreagate which might be why they are interested in traits on aggreages? if so nested resouce providers sould support that usecase
15:13:22 bauzas jaypipes: could you please ACK'ing my comments here https://review.openstack.org/#/c/415920/15 so I could +W it ?
15:14:44 bauzas FWIW, hectic day
15:20:14 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: DO NOT MERGE: debug failed test https://review.openstack.org/479818
15:24:42 openstackgerrit Stephen Finucane proposed openstack/os-vif master: doc: Create directory structure for docs migration https://review.openstack.org/479861
15:24:43 openstackgerrit Stephen Finucane proposed openstack/os-vif master: doc: Switch from oslosphinx to openstackdocstheme https://review.openstack.org/479862
15:25:20 sfinucan jaypipes, sean-k-mooney, moshele: More docs fixes ^
15:25:34 sfinucan (for https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
15:26:21 sean-k-mooney sfinucan: what is openstackdocstheme?
15:26:39 sfinucan sean-k-mooney: the theme that docs.openstack.org uses
15:27:17 sfinucan We're supposed to use it for any official OpenStack projects now
15:27:24 sean-k-mooney but is it a theme for sphinx that is maintined by the docs team for consitnecy across all offical docs?
15:27:32 sean-k-mooney ok cool
15:28:19 mriedem sean-k-mooney: i don't actually know what the use case is,
15:28:28 mriedem but nested RPs might be an option, it did come up too for BM
15:28:37 mriedem but not for multi-node chassis,
15:28:50 mriedem more for modeling NICs and Disks
15:29:02 mriedem and putting traits on those like type and capabilities
15:29:35 sean-k-mooney mriedem: i think blade servers are a good candiated for nested resouce providers as anti afinity at the chassis level may be needed to ha reasons
15:31:33 mriedem yes that was one example that came up too
15:31:55 mriedem making sure you're not in the same rack as the other servers in the same group
15:32:51 sean-k-mooney mriedem: that could be modeled with aggregates too but i guess it just depends on what you are trying to achive.
15:33:07 mriedem we got talking about the distance stuff from the boston session which then goes down the road of do we standarize the distance enums? or do we leave that up to ops (which wouldn't be interoperable)? or do you define it at an SLA level, but is your SLA guaranteed within the same rack, row or DC?
15:34:57 sean-k-mooney mriedem: ceph stiks a resonably good blance there. they provide standard values in the crush map for osd,host,rack... but you can just change the vaule if you want too.
15:36:25 sean-k-mooney for example if you want to add a lay for chassis in between host and rack you can by editing the crushmap, honestly i dont know whay the best aproch would be but have a predifed set would be good for interop
15:42:12 mdbooth sfinucan: Here's a fun patch if you've got time: https://review.openstack.org/#/c/462521/ . It has 2 dependencies which are stacked above it.
15:43:19 mdbooth The idea is to automatically kick off a revert if it fails on the destination. It's a bit tricky basically because of instance state, migration state, and quotas.
15:44:06 mdbooth It's obviously a user-friendly feature, but it's actually intended as a workaround for a bug we can't easily fix right now due to our datamodel.
15:45:41 mdbooth Bug details are in the bug link, but basically if your resize fails on the destination node, your instance is using a deleted glance image, and you don't revert within 24 hours, it'll delete the only remaining copy of your image. At this point your instance is unrecoverable.
15:46:53 mdbooth Ideally we would have the image cache not delete the image in this case, but our datamodel means it's not possible to identify an instance which is awaiting confirmation on the destination.

Earlier   Later