Posted	Nick	Remark
#openstack-nova - 2018-08-16
18:05:24	sean-k-mooney	Sundar: cyborg will have to create a seperate resouce provider tree under the compute node. it should be possible to do that today but im not sure if the virt driver will remove them or not
18:05:29	efried	kosamara: Do you understand the concern about trait "ownership" in general?
18:05:47	efried	sean-k-mooney: The virt driver won't remove them; but we also won't schedule to them either.
18:06:05	sean-k-mooney	efried: can you allocate from them
18:06:32	sean-k-mooney	the intent would to still schduler to the compute node but consume the cyborg resouce from the cyborg subtrees
18:06:42	efried	sean-k-mooney: basically, that whole code path has some bits that will work, some bits that definitely won't, and some that are still a mystery. This is work that needs to be done in Stein.
18:07:08	efried	sean-k-mooney: I think the scheduler *should* consume the cyborg resources.
18:07:20	efried	It's just not allowed to muck with the cyborg providers' inventories or traits.
18:07:23	Sundar	sean-k-mooney: Yes, cyborg is trying to do nRPs. We hit the virt driver overwrite issue and developers decided to wait for that to be resolved.
18:07:54	sean-k-mooney	efried: right. we may also have to revisit the idea of have a seperate root node just for the phyical server and then have per projec subtrees
18:08:31	sean-k-mooney	Sundar: again if the overriete issue is you tried to create invtories on the comptue node resouce provider that will never be supported
18:08:33	efried	revisit? I don't remember visiting that in the first place, ever. Per-project subtrees?
18:09:14	sean-k-mooney	efried: it came up in dublin on the friday when we were all tired
18:09:38	Sundar	sean-k-mooney: no, we created nested RPs within the compute node.
18:09:42	efried	I think Sundar is talking about creating child providers of the compute node provider but having them ignored by the scheduler and/or deleted by the resource tracker. The latter may have happened in libvirt when it was still using get_inventory.
18:09:56	Sundar	Yes ^
18:09:58	efried	I'm guessing you haven't tried it since we implemented libvirt's update_provider_tree method.
18:10:14	Sundar	efried: when was that done?
18:10:25	efried	Sundar: So if you have the resources and inclination, you could try that again. I guarantee it will still break, but it may get slightly further than it did before.
18:10:29	efried	Sundar: Let me find the patch...
18:11:01	sean-k-mooney	efried: the idea being that nova would nolonger own the root node of the tree. the root would have no invetores and just represent teh server then each service on the serve would create there own nested resouce provider beneate that root node
18:11:18	Sundar	efried: "I guarantee it will still break" -- that won't help me persuade other Cyborg developers to start moving fwd :)
18:11:26	efried	Sundar: https://review.openstack.org/#/c/560444/ merged 5/25
18:11:53	sean-k-mooney	efried: it was a fallback incase we did not figure out how to have multple service own different nodes under the current tree create by nova
18:11:54	efried	sean-k-mooney: Nono, nova still owns the root provider. But nova does *not* own the device providers - cyborg owns those.
18:12:04	efried	oh, sorry, you're talking about the project-based thing.
18:12:27	sean-k-mooney	efried: ya sorry i was
18:12:58	efried	sean-k-mooney: Without further placement API work, we would probably have to do that by lassoing the project subtree in an aggregate corresponding to the project ID.
18:13:26	sean-k-mooney	efried: by project id you mean service id?
18:13:39	efried	But regardless, that would still rely on scheduler and resource tracker implementation that we have not started yet. Same as the stuff Sundar is blocked behind.
18:13:43	sean-k-mooney	when i said per-procject i ment nova, neutron, cinder not tenants
18:14:09	efried	um, oh, then forget what I'm saying.
18:14:23	efried	But yes, all of that needs to be thought through.
18:14:39	efried	sean-k-mooney: I would think that nova would still own the root node.
18:15:12	efried	Sundar: Define "moving fwd"? You can't integrate with nova yet, for sure. But I assume there's work you can do while you're waiting for enablement.
18:15:56	sean-k-mooney	efried: perhaps, the idea of spliting it out was in the event that nova is not the first service deployed on the node, we won know what uuid it will get so we cant create the provider tree
18:16:35	efried	somebody would have to reparent
18:16:45	efried	which can be done as long as parent isn't already set.
18:17:48	sean-k-mooney	efried: once that reshaper stuff is reviewed :)
18:18:23	sean-k-mooney	although i guess you could manually reparent now its just not as simple
18:20:40	efried	Now Nova starts. It creates the compute node RP. It also somehow discovers that the NIC and device RPs are out there, and reparents them (PUT /resource_provider/{u} with parent_provider_uuid specified in the payload) to the compute node RP.
18:20:40	efried	Cyborg starts next. Creates the dev RPs. They have no parent (and aren't related to the NIC RPs).
18:20:40	efried	Neutron starts first. Creates the NIC RPs. They have no parent.
18:20:40	efried	actually I don't think reshaper accounts for reparenting at all. I was talking about:
18:24:11	Sundar	efried: Why can't Cyborg and Neutron wait for Nova compute to create the top level first?
18:26:50	Sundar	If that is simpler, that is
18:28:15	efried	I don't know. Maybe they can. Ask sean-k-mooney
18:48:23	openstackgerrit	Merged openstack/nova master: Py3 fix in fake image service https://review.openstack.org/592056
18:53:12	openstackgerrit	Eric Fried proposed openstack/nova-specs master: Repropose reshaper spec for Stein https://review.openstack.org/592650
19:04:25	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: use single-shot INSERT/DELETE agg https://review.openstack.org/592654
19:26:16	openstackgerrit	Eric Fried proposed openstack/nova-specs master: Repropose reshaper spec for Stein https://review.openstack.org/592650
20:50:08	melwitt	nova meeting in 10 minutes
20:59:02	openstackgerrit	Dan Smith proposed openstack/nova master: WIP: Batch results per cell when doing cross-cell listing https://review.openstack.org/592698
21:02:33	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: use single-shot INSERT/DELETE agg https://review.openstack.org/592654
21:24:13	openstackgerrit	Dan Smith proposed openstack/nova master: WIP: Batch results per cell when doing cross-cell listing https://review.openstack.org/592698
22:00:51	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: use single-shot INSERT/DELETE agg https://review.openstack.org/592654
22:04:49	openstackgerrit	Jay Pipes proposed openstack/nova master: placement: use single-shot INSERT/DELETE agg https://review.openstack.org/592654
22:16:34	openstackgerrit	Eric Fried proposed openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.openstack.org/592755
22:17:13	efried	melwitt: In case you were busily working on this enhancement ^
22:19:59	melwitt	hah, thanks
22:24:52	efried	melwitt: Mind if I combine your patches for dynamically finding releases and counting blueprints into a series that commonizes the fs walk bit?
22:25:11	melwitt	efried: nope, go ahead
22:37:56	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104
22:42:01	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Making consistent used of GiB and MiB in API ref https://review.openstack.org/559985
22:49:42	openstackgerrit	melanie witt proposed openstack/nova-specs master: Move rocky implemented specs https://review.openstack.org/592622
22:51:49	openstackgerrit	Eric Fried proposed openstack/nova-specs master: Add a script for counting blueprints https://review.openstack.org/581914
22:52:12	efried	melwitt: ^ rebased on top of the dynamic-y one
22:54:41	melwitt	cool, thanks
23:03:25	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106
23:06:51	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110
23:09:28	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6) https://review.openstack.org/574113
23:11:58	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7) https://review.openstack.org/574974
23:14:50	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8) https://review.openstack.org/575311
23:17:39	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9) https://review.openstack.org/575581
23:20:12	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10) https://review.openstack.org/576017
23:22:40	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11) https://review.openstack.org/576018
23:26:28	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12) https://review.openstack.org/576019
23:29:46	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13) https://review.openstack.org/576020
23:36:03	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14) https://review.openstack.org/576027
23:41:33	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.openstack.org/576031
23:44:42	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.openstack.org/576299
23:48:34	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.openstack.org/576344
23:51:21	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.openstack.org/576673
23:54:35	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.openstack.org/576676
23:57:21	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.openstack.org/576689
23:59:34	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.openstack.org/576709
#openstack-nova - 2018-08-17
00:03:17	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.openstack.org/576712
00:04:05	openstackgerrit	melanie witt proposed openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533
00:13:32	openstackgerrit	melanie witt proposed openstack/nova master: Update contributor process doc for stein https://review.openstack.org/592766
00:29:14	openstackgerrit	melanie witt proposed openstack/nova master: Update contributor docs for stein https://review.openstack.org/592766
00:52:54	mriedem	o/
00:55:07	melwitt	mriedem: I resurrected this old docs patch from sdague based on a bug I closed today. you used to be +2 on it https://review.openstack.org/492533 I'd +2 it but I rebased it out of merge conflict
00:56:38	mriedem	yeah...that got caught up in committee
00:57:24	melwitt	yeah. maybe it's not perfect but it's definitely a big improvement over the docs we currently have
00:58:17	melwitt	I was thinking, "we should add more info to the docs" and then I stumbled upon the abandoned patch while looking for something else
00:59:33	mriedem	yeah, there are a couple of small things we can improve from PS2 comments so i'll mark those
00:59:42	melwitt	ok
00:59:42	mriedem	but yes i was +2 before because it's a big improvement over nothing
00:59:58	melwitt	yup ++
01:14:13	mriedem	melwitt: ok comments inline

Earlier   Later