Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-16
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 actually I don't think reshaper accounts for reparenting at all. I was talking about:
18:20:40 efried Neutron starts first. Creates the NIC RPs. They have no parent.
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 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: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 mriedem but yes i was +2 before because it's a big improvement over nothing
00:59:42 melwitt ok
00:59:58 melwitt yup ++
01:14:13 mriedem melwitt: ok comments inline
01:14:33 melwitt thanks
01:31:10 openstackgerrit fupingxie proposed openstack/nova master: Support list for alias in pci section in nova.conf https://review.openstack.org/592243
01:42:03 openstackgerrit melanie witt proposed openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533
01:47:05 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Add support specify volume type when boot instance https://review.openstack.org/579520
01:49:06 ileixe Hi guys, Does anybody have optimal solution for nova-schedulers' race condition? I just tried to increase try attempts but wonder how others do..
01:50:05 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support deleting data volume when destroy instance https://review.openstack.org/580336
02:05:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Add zvm admin intro and hypervisor information https://review.openstack.org/533125
02:08:43 openstackgerrit Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252
02:09:00 mriedem efried: powervm supports snapshot right? if so, it should be able to claim shelve support https://review.openstack.org/#/c/533512/14/doc/source/user/feature-matrix-gp.ini
02:09:09 mriedem which is just snapshot, destroy and spawn from snapshot elsewhere
02:09:23 melwitt ileixe: you mean race with parallel requests? are you using an older version of nova? as of the pike version, the scheduler is claiming resources with placement, which solves the parallel requests race
02:09:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Add zvm CI information https://review.openstack.org/533512
02:12:02 melwitt ileixe: if you are using an older version than pike, you can increase the retries (max_attempts) the way you have. you can also use the scheduler_host_subset_size config option to randomize the selection of compute host during scheduling, if you are OK with spreading instances rather than packing them https://docs.openstack.org/ocata/config-reference/compute/schedulers.html
02:12:32 ileixe melwitt: Yes, exactly. We did not upgrade the placement api yet, and I also expect the api solve the synchronize problem but I could not find the related logic in master branch.
02:13:12 ileixe Thanks for the answer, I will try to find the logic if it solve the problem.

Earlier   Later