Earlier  
Posted Nick Remark
#openstack-nova - 2018-11-20
12:53:06 sean-k-mooney we could call the protocol offload instead and switching offloads
12:53:32 jangutter sean-k-mooney: hence why I thought "endpoint offloads" and "datapath offloads" are also good bikesheds....
12:54:22 jangutter sean-k-mooney: "protocol offload" and VXLAN/IPSEC will cause a bit of confusion, but I'm fine with "switching/vswitch/eswitch offloads"
12:55:17 sean-k-mooney then network offloads and switching offloads?
12:55:31 sean-k-mooney i agree the tunnels are kind of both
12:55:36 sean-k-mooney they ware weird
12:55:55 jangutter sean-k-mooney: tell me about it.
12:57:10 jangutter sean-k-mooney: I almost want to call 'em "socket offloads".
12:57:35 sean-k-mooney so while we some of them dont work a l4 however
12:58:14 sean-k-mooney ignore the so while we
12:58:33 sean-k-mooney i need to full clear my buffer when i change what i was going to type
12:59:23 sean-k-mooney jangutter: since we are talking about nameing how do you feel about my nameing comments in https://review.openstack.org/#/c/572081/9/os_vif/objects/host_info.py@205
13:00:04 sean-k-mooney e.g. the fact that the repsentor netdevs are really part of the contol plane not data plane since they do not transmit packets
13:00:29 sean-k-mooney the are kind of like the vhost-user sockets in that respect
13:00:59 jangutter sean-k-mooney: representors absolutely transmit packets.
13:01:02 sean-k-mooney the difference being if you implemented them correctly and ran tcpdump the kernel would actully allow you to sniff the packets
13:01:32 sean-k-mooney jangutter: the VF those but the netdev you add to ovs should not
13:01:36 jangutter sean-k-mooney: mainly, the first packet of a new flow, i.e. something that doesn't have a rule.
13:01:50 sean-k-mooney right the learning packet but not the rest
13:02:03 sean-k-mooney i forgot they are used for the exception path
13:02:10 jangutter sean-k-mooney: yep, and it's vital to things like tunnels...
13:02:33 sean-k-mooney networking is hard.
13:02:47 sean-k-mooney i need to respond to a downstream bug but ill be back in a while
13:02:52 sean-k-mooney did this help?
13:03:02 jangutter sean-k-mooney: thanks very much, this was very therapeutic!
13:03:34 sean-k-mooney ill try and review the spec today or at least this week i have it open on my monitor in anycase
13:04:22 jangutter sean-k-mooney: thanks, will be respinning to try to clarify that some "offloads" are more "off" than others.
13:12:51 openstackgerrit do3meli proposed openstack/nova master: Allow VMs to use unaddressed ports https://review.openstack.org/533249
13:33:47 dtantsur hi folks! is there a high-level description of Placement API? /cc cdent
13:34:26 bauzas dtantsur: https://developer.openstack.org/api-ref/placement/ ?
13:35:18 dtantsur bauzas: this is low-level, it says how to use specific endpoints. I'm more interested in high-level flow.
13:36:06 dtantsur I want to make ironic optionally report to/consume placement
13:36:24 dtantsur I need to understand 1. what reporting actually means, 2. how a node can be reserved via Placement.
13:37:12 bauzas dtantsur: we also have https://docs.openstack.org/nova/latest/contributor/placement.html
13:37:57 belmoreira dtantsur are you tracking this work somewhere?
13:38:29 dtantsur belmoreira: mostly in my head for now.. the API design without placement bits is https://review.openstack.org/617953
13:39:49 dtantsur let me try a specific question
13:40:10 dtantsur given that any Ironic node is represented by exactly one instance of a custom resource class
13:40:46 dtantsur to reserve a node I need: 1. GET /resource_providers?resources=CUSTOM_BAREMETAL:1&required=list,of,traits
13:40:57 dtantsur 2. POST /allocations with suitable UUID?
14:04:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Use long_rpc_timeout in select_destinations RPC call https://review.openstack.org/607735
14:11:57 mriedem dansmith: a couple of questions in https://review.openstack.org/#/c/617898/
14:20:14 dansmith jaypipes: you had feelings on this in the past, if you want to chime in ^
14:27:19 cdent dtantsur: join us in #openstack-placement
14:37:25 mriedem dansmith: replied. i'd be +2 on that now unless you are going to update the little CRUD APIs thing
14:38:05 mriedem i could see value in trying to document your replies about alternatives to filtering on cell etc, but that might be more work than it's worth right now
14:39:14 dansmith mriedem: yep, I'll fix the crud wording first
14:40:13 efried prometheanfire, sean-k-mooney: If we're backporting that oslo.service change, we need to backport the nova fixage to those mocks. This was a pretty big PITA when we did it on master, requiring a weird lockstep of patches in nova and requirements. Let me find it quick...
14:42:49 efried Update nova to use the mocks and require the new release: https://review.openstack.org/#/c/615724/
14:42:49 efried Update the requirements: https://review.openstack.org/#/c/616371/
14:42:49 efried Remove the mocks from nova: https://review.openstack.org/#/c/616697/
14:42:49 efried prometheanfire, sean-k-mooney: Okay, so I think it was, in this order:
14:43:39 sean-k-mooney efried: yes we would or we could not backport the oslo.service change at all
14:44:38 efried sean-k-mooney: Or we could just backport "remove the mocks". The only thing it affects is wallclock time for tox. The mocks are just avoiding real sleeps.
14:44:44 sean-k-mooney i would personally prefer to revet teh oslo change form the 1.31.x branch but that said it only breaks the unit test and does pass functional and tempest tests
14:45:11 sean-k-mooney efried: ya that is an option
14:45:31 efried yes, it's UT only. And it's because nova is mocking private things from oslo.service, and those private things are re/moved with that fix.
14:45:41 efried (and that was my bad, mocking the privates)
14:45:44 openstackgerrit Dan Smith proposed openstack/nova master: Add CellsV2 FAQ about API design decisions https://review.openstack.org/617898
14:46:21 sean-k-mooney efried: yes but they were removed in a release of oslo.service that was above the max allowed by the upper-constratins for that release
14:47:14 sean-k-mooney efried: redhat has backported this internally and it broke everything so i know it will make lyarwood happy if we fixed nova upstream to work with that backport
14:48:23 sean-k-mooney efried: i guess https://review.openstack.org/#/c/616697/ is relitivly small
14:48:45 efried sean-k-mooney: I'm going to take the morning off. If you and/or dhellmann and/or prometheanfire want to fix it up, cool, or bug me about it later and I can propose whatever.
14:48:51 efried sean-k-mooney: Yes, it's trivial.
14:49:58 sean-k-mooney ok i can propose the backport for https://review.openstack.org/#/c/616697/2
14:50:43 sean-k-mooney we cant bump to 1.33 on stable however
14:51:24 sean-k-mooney so we will need to get them to backport the sleep fixture.
14:52:13 openstackgerrit Eric Fried proposed openstack/nova master: Remove v1 check in Cinder client version lookup https://review.openstack.org/617927
14:54:00 openstackgerrit Eric Fried proposed openstack/nova master: Consider root id is None in the database case https://review.openstack.org/613305
14:59:25 efried sean-k-mooney: It looks like that's proposed anyway: https://review.openstack.org/#/c/617989/
15:01:57 sean-k-mooney efried: yes chating to them on oslo channel
15:02:14 sean-k-mooney ill propse the backport for the 2 patches you suggested
15:02:24 efried_pto thanks sean-k-mooney
15:02:56 sean-k-mooney actully hberaud is gong to do it but ill keep an eye on it. enjoy your morning off
15:13:14 jaypipes dansmith: done
15:13:22 jaypipes dansmith: thx for the heads up on that.
15:19:40 dansmith jaypipes: thanks
15:19:48 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Delete the placement code https://review.openstack.org/618215
15:21:06 openstack Launchpad bug 1804253 in openstack-manuals "Capacity planning and scaling in Operations Guide - cells information is out of date" [Undecided,New]
15:21:06 mriedem if someone is looking to update the resurrected ops guide docs about cells https://bugs.launchpad.net/openstack-manuals/+bug/1804253
15:21:13 mriedem ^ is still all cells v1
15:26:21 openstackgerrit Hervé Beraud proposed openstack/nova stable/rocky: remove mocks of oslo.service private members https://review.openstack.org/619019
15:26:59 BjoernT Hello, Is someone here aware of the implementation of ComputeManager._run_image_cache_manag as we run in to performance issues on a NFS mounted /var/lib/nova/instances directory and now had to increase rpc response timeout?
15:32:12 sean-k-mooney that ^ sound like an mdbooth kind of question but he does not seam to be about currently
15:38:57 openstackgerrit Hervé Beraud proposed openstack/nova stable/rocky: Use SleepFixture instead of mocking _ThreadingEvent.wait https://review.openstack.org/619022
15:42:25 openstackgerrit Jack Ding proposed openstack/nova master: Add I/O Semaphore to limit concurrent disk ops https://review.openstack.org/609180
15:47:30 prometheanfire efried_pto: sean-k-mooney I'd say we are fine for now, nova may want to add a exclusion to it's reqs.txt, or not
15:48:13 prometheanfire the update is being held back atm by reqs cross gating
15:49:48 prometheanfire question is, are old versions of nova going to work with the oslo.service change (18.0.2 and the like), it sounds like not, which means packagers should be made aware
15:49:56 sean-k-mooney prometheanfire: https://review.openstack.org/#/c/619019/1 and https://review.openstack.org/#/c/619022/1 will fix the nova compatiblity
15:50:47 sean-k-mooney prometheanfire: old versions of nova would work but the unites would not which may break packager build systems
15:52:39 prometheanfire unites / unit tests?
15:55:30 openstackgerrit Merged openstack/nova master: Add description of custom resource classes https://review.openstack.org/616721
15:55:38 openstackgerrit Merged openstack/nova master: Add CellsV2 FAQ about API design decisions https://review.openstack.org/617898
16:09:23 Sundar jaypipes, dansmith, sean-k-mooney, cdent: Thanks for discussing the Nova-Cyborg spec in IRC y'day. I caught up with that. Will remove the Cyborg API signatures. and
16:10:19 Sundar I still have some questions on what jaypipes expects. The os-acc is not going to handle devices by itself. It neds access to Cyborg db and drivers, which means the majority of work will happen in Cyborg.
16:13:10 Sundar sean-k-mooney: Re. request groups in device profiles, it is still not clear to me how we would handle co-location without them, i.e., we want 2 accelerators from 2 different RPs in the same device.
16:17:08 mriedem os-acc is going to have direct db access to cyborg?
16:23:20 Sundar mdriedem: No. os-acc needs to call Cyborg REST APIs, and those calls do the bulk of the work.
16:23:50 jaypipes Sundar: currently on a call with sean-k-mooney and jangutter about os-vif. give me a little while to respond.

Earlier   Later