| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 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. | |
| 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? | |