Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-03
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: WIP - placement: claim resources in scheduler https://review.openstack.org/476632
14:58:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: support GET /allocation_candidates https://review.openstack.org/475448
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.
15:47:51 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081
15:49:15 AJaeger mriedem, or any cores around?
15:49:34 AJaeger Could you please abandon this change: https://review.openstack.org/#/c/479657/ - it will never build and is wrong
15:49:38 AJaeger Hangs currently in zuul...
15:50:21 mriedem AJaeger: i don't see the abandon button
15:50:33 AJaeger ok, then I'll ask infra-root...
15:51:38 fungi that's a fun one
15:51:40 fungi looking now
15:52:21 AJaeger fungi, you're everywhere ;) Ignore my ping on #openstack-infra then :-) - and thanks
15:55:39 fungi okay, abandoned
15:56:04 AJaeger thanks
16:00:29 sfinucan mdbooth: Ooh, that's a tricky one
16:00:33 sfinucan Thanks for the context
16:04:08 mriedem melwitt: do you know if james is also serving VMs in his cloud or just baremetal?
16:06:13 bauzas mriedem: AFAIK, mel is on patriotic PTO today
16:06:44 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient master: DO NOT MERGE: debug failed test https://review.openstack.org/479818
16:08:05 jaypipes bauzas: responded.
16:08:10 mriedem bauzas: ok
16:08:18 jaypipes bauzas: there's no hurry on the n-r-p series, though.
16:08:28 jaypipes bauzas: allocation candidates is the more important one at this point.
16:08:32 bauzas jaypipes: I know, but I think your change is fine by me
16:08:35 bauzas jaypipes: sure
16:08:42 mriedem bauzas: can you go over this one? https://review.openstack.org/#/c/476631/15
16:08:55 mriedem is dan out today too?
16:09:02 mriedem i.e. is today a red hat holiday?
16:09:10 bauzas mriedem: dan too
16:09:16 bauzas mriedem: dunno
16:09:26 mriedem most people make it a long weekend
16:09:30 bauzas mriedem: pssst, I'm not an US folk :p
16:09:34 mriedem really?
16:10:23 bauzas even if we have elephants having trumps, any of them are our president :p
16:10:39 bauzas anyway, looking at your change
16:11:36 mriedem our child care provider is closed today so i'm hosting a play date and working
16:12:11 bauzas heh
16:15:13 openstackgerrit Gábor Antal proposed openstack/nova master: Add json style checking for sample notifications https://review.openstack.org/443677
16:31:47 sfinucan mdbooth: IMA I'm pretty confused by https://review.openstack.org/#/c/479802/
16:32:48 mdbooth sfinucan: What specifically?

Earlier   Later