| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-03 | |||
| 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 | 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: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 | 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: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: 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. | |