Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-20
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.
16:24:15 mriedem Sundar: ok, if os-acc were like os-brick and os-vif, i would expect it to deal with the physical devices on the host
16:24:24 mriedem and something like python-cyborgclient would be used for dealing with the cyborg rest API
16:24:27 mriedem or the openstacksdk
16:24:47 mriedem at least that's the model nova has for dealing with volumes and ports
16:24:54 Sundar jaypipes, Sure, NP
16:26:40 Sundar mriedem: I understand. os-acc is not an exact clone of os-vif or os-brick. For example, to bind an ARQ, a device may need to be configured or re-programmed. That requires a Cyborg driver which knows the details of that device.
16:27:04 Sundar mriedem: That is more like what a Neutron mechanism driver does.
16:27:42 mriedem hmm,
16:27:58 mriedem os-brick and os-vif definitely have plugins/drivers that do things based on the 'type' of device
16:28:07 mriedem but i'm just sitting in the peanut gallery here so ignore me
16:33:47 Sundar If we were to have separate drivers for os-acc and Cyborg, it would be cumbersome -- for example, tasks needed for device discovery/initialization (handled by Cyborg drivers) and tasks required for ARQ binding (initiated via os-acc) will have many commonalities. For instance, both may need ways to reset the device (or some part of it).
16:34:28 Sundar Apart from having two different driver installs/configures etc.
16:38:39 Sundar The os-vif plugins, from what I have seen, are handling Linux bridges, OVS, etc., not hardware per se.
16:41:11 mriedem i believe cinder (the service) uses os-brick
16:41:19 mriedem to avoid doing the same things in both places
16:41:24 mriedem jungleboyj: ^?
16:43:34 dansmith mriedem: Sundar I think it's entirely legit to think that not all device programming can be contained within os-acc
16:44:01 dansmith it's a lot more complicated of a thing than configuring an initiator or a bridge
16:44:21 Sundar dansmith: ^ +1
16:44:26 jungleboyj mriedem: You understanding is correct and we have different drivers in there depending on the type of device.
16:45:44 mriedem ok, again, peanut gallery
16:45:57 jungleboyj Both Cinder and Nova use os-brick so that we aren't duplicating code.
16:45:59 sean-k-mooney o/
16:46:20 jungleboyj That does the work locally on the compute node and then anything that required work from the volume driver is done through the Cinder-API.
16:47:40 dansmith if we use brick as the analogy,
16:47:53 dansmith it would be like putting all the stuff that talks to the backend volume providers into os-brick
16:49:02 sean-k-mooney dansmith: the programin of the device id not really done by cyborg either howver
16:49:15 sean-k-mooney it will be delegating the fpga progroming in the intel case to opae
16:49:35 dansmith sean-k-mooney: sure, just like cinder-volume doesn't actually sort the bits on the disk, but asks whatever api it has for the backend to do it
16:49:35 Sundar sean-k-mooney: Not quite true.
16:50:27 Sundar Cyborg will indeed call a Cyborg driver, which can call into device/vendor-specific drivers, such as OPAE or i915 (for GPUs), etc.
16:53:45 sean-k-mooney so im conused are we all happy with the statemet nova only interaction point with cyborg should be via os-acc and that os-acc should only interact with cyborg via its rest api
16:55:20 dansmith I guess I'm not sure what is confusing.. we interact with cinder via the cinderclient/brick
16:55:32 dansmith I think we're hoping that os-acc can serve both purposes, right?
16:55:42 mriedem that's what i'm hearing be described
16:55:51 mriedem os-acc is both rest api client and low-level host device thing
16:56:05 sean-k-mooney yes and that os-acc can hold the definitions of any data structre that nova and cyboge have to share
16:56:26 sean-k-mooney mriedem: yes to form no to later
16:56:37 mriedem what?
16:56:40 dansmith huh?
16:56:43 dansmith jinx
16:57:02 sean-k-mooney os-acc would only be a rest client
16:57:04 mriedem i got jinxed by a couple of 7 year old girls the other night, couldn't talk for 10 minutes, it was....not hard
16:57:31 sean-k-mooney the low level programing is handeled by the cyboge drivers and the tools they invoke
16:58:17 Sundar sean-k-mooney: True. But I think what is being said is that Nova views os-acc as performing the low-level tasks, i.e, it calls os-acc and leaves the details to it
16:58:23 jaypipes I really don't see why os-acc can't start off being a plug-the-device-into-the-VM library.
16:58:25 dansmith sean-k-mooney: I don't know why you're so intent on declaring that os-acc is only one thing or another
16:58:40 dansmith jaypipes: that's not a separate action
16:58:48 jaypipes dansmith: what do you mean?
16:58:57 dansmith jaypipes: plugging involves writing pci attachment into the virt xml for boot, right?
16:59:19 dansmith jaypipes: if there's any massaging of the device needed, like writing to sys to discover a new pci endpoint or something, then that seems like it could/should be in os-acc
16:59:23 sean-k-mooney jaypipes: would you be happy saying os-acc could start as beeing a program the device for the vm lib
16:59:46 mriedem in other news, we broke postgresql http://logs.openstack.org/periodic/git.openstack.org/openstack/neutron/master/neutron-tempest-postgres-full/a52bcf9/logs/screen-n-api.txt.gz?level=ERROR
17:00:28 jaypipes dansmith: yes, I agree with you. I just don't believe os-acc should be a REST API client to cyborg.
17:00:48 dansmith jaypipes: so we need a cyborgclient?

Earlier   Later