Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-12
07:14:34 openstackgerrit Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support compute node resource provider update and create https://review.openstack.org/521041
07:24:57 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 3 https://review.openstack.org/560727
07:25:40 openstackgerrit Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support compute node resource provider update and create https://review.openstack.org/521041
07:38:23 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 4 https://review.openstack.org/560731
07:55:20 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 4 https://review.openstack.org/560731
07:59:30 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 4 https://review.openstack.org/560731
08:09:29 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/543569
08:12:43 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in test_serversV21.py (1) https://review.openstack.org/560821
08:14:19 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in test_serversV21.py (1) https://review.openstack.org/560821
08:32:16 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 4 https://review.openstack.org/560731
08:53:37 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in test_serversV21.py (2) https://review.openstack.org/560829
08:58:48 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: WIP: complex policy https://review.openstack.org/553776
08:58:49 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Add rules column to instance_group_policy table. https://review.openstack.org/560832
09:03:15 openstackgerrit jichenjc proposed openstack/nova master: remove ec2 object definitions https://review.openstack.org/557150
09:03:16 openstackgerrit jichenjc proposed openstack/nova master: remove ec2 db functions https://review.openstack.org/557572
09:33:47 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 5 https://review.openstack.org/560734
09:33:51 phuongnh hi jaypipes, I would like to add one more line in file https://review.openstack.org/#/c/462759/3/os_traits/hw/cpu/x86.py for CPU_FPGA
09:34:10 phuongnh the link to this is: https://en.wikipedia.org/wiki/Field-programmable_gate_array
09:34:13 phuongnh Do I need to propose a blueprint in launchpad?
09:50:54 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 6 https://review.openstack.org/560737
11:04:09 openstackgerrit Merged openstack/nova master: Remove mox in test_virt_drivers.py https://review.openstack.org/559878
11:12:09 Shilpa stephenfin: Hi
11:20:40 openstackgerrit Merged openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (1) https://review.openstack.org/558704
11:26:58 stephenfin Shilpa: o/
11:28:22 Shilpa stephenfin: i have added patch set https://review.openstack.org/#/c/550172/2, and added comment there, can you please go through the same.
11:29:51 Shilpa stephenfin: its ok to proceed with noVNC v1.0.0 tag, i have seen issue reported here at https://github.com/novnc/noVNC/issues/1034
11:31:27 stephenfin Shilpa: It looks like the CI is failing though?
11:31:35 stephenfin with a valid failure, no less
11:32:37 Shilpa stephenfin: i have noted that, but they were failing on earlier patch set too, so just ignored, will check logs
11:46:31 openstackgerrit Zhenyu Zheng proposed openstack/nova-specs master: Amend allow abort live migrations in queued status spec https://review.openstack.org/560872
11:58:09 bhagyashris alex_xu: Hi, I just want to know about the spec https://docs.openstack.org/oslo.config/latest/reference/mutable.html which basically give the provision to make the conf parameter as mutable
11:59:51 Shilpa stephenfin: checked logs http://logs.openstack.org/72/550172/2/check/tempest-full/f6945b6/job-output.txt.gz, and observed that 1 test case is failed, and that is tempest.api.compute.servers.test_novnc.NoVNCConsoleTestJSON.test_novnc[id-c640fdff-8ab4-45a4-a5d8-7e6146cbd0dc]
11:59:52 alex_xu bhagyashris: maybe gcb is good person, but looks like he isn't in this channel
11:59:53 bhagyashris alex_xu: there is one patch submitted in nova https://review.openstack.org/#/c/319203/3 so what are the criteria to make the conf parameter as mutable in any project
12:00:48 alex_xu bhagyashris: ok
12:01:53 bhagyashris alex_xu: as per the operators point of view every parameter should be make it as mutable but why only these two parameters are made it as mutable
12:02:01 openstackgerrit Matthew Booth proposed openstack/nova master: Give volume DriverBlockDevice classes a common prefix https://review.openstack.org/526346
12:02:02 openstackgerrit Matthew Booth proposed openstack/nova master: Add DriverLocalImageBlockDevice https://review.openstack.org/526347
12:02:03 openstackgerrit Matthew Booth proposed openstack/nova master: Expose driver_block_device fields consistently https://review.openstack.org/528362
12:02:04 openstackgerrit Matthew Booth proposed openstack/nova master: Add local_root to block_device_info https://review.openstack.org/529029
12:02:05 openstackgerrit Matthew Booth proposed openstack/nova master: Pass DriverBlockDevice to driver.attach_volume https://review.openstack.org/528363
12:02:06 openstackgerrit Matthew Booth proposed openstack/nova master: Fix libvirt volume tests passing invalid disk_info https://review.openstack.org/529328
12:03:06 bhagyashris alex_xu: in this patch https://review.openstack.org/#/c/319203/3
12:05:28 alex_xu bhagyashris: I guess that BP only target to something people just need at that point
12:07:28 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 7 https://review.openstack.org/560748
12:07:40 alex_xu bhagyashris: I'm not sure all the config option works, but I also didn't see any reject for other options other than that BP
12:10:59 bhagyashris alex_xu: Actually I have few queries in nova only those two parameters are marked as mutable = True in (https://review.openstack.org/#/c/319203/3) so is that means other all the conf parameters are non-mutable.
12:11:40 openstackgerrit pippo proposed openstack/nova master: Update eventlet https://review.openstack.org/560876
12:32:41 efried Good UGT morning bhagyashris
12:33:33 efried bhagyashris: Are you going to take over https://review.openstack.org/560444 and https://review.openstack.org/560459 ?
12:34:55 bhagyashris efried: Good morning :)
12:42:22 bhagyashris efried: ok i will take.
12:43:34 efried bhagyashris: Great. Can you put your name down on the etherpad https://etherpad.openstack.org/p/rocky-nova-priorities-tracking see L115
12:43:54 efried jaypipes: FYI ^
12:47:39 bauzas stephenfin: quick question, if I'm providing a extra spec saying --property hw:numa_nodes=N, does it mean that the instance will use 2 physical NUMA nodes, or just that the instance XML will have 2 nodes ?
12:48:13 bauzas if the latter, are we supporting to not have sharded the NUMA nodes ?
12:48:37 efried sean-k-mooney, cfriesen: ^
12:48:40 bauzas stephenfin: context is https://review.openstack.org/#/c/552924/7/specs/rocky/approved/numa-topology-with-rps.rst@185
12:52:02 bauzas efried: as you can see, I wonder if we would still need a specific sharding param
12:52:47 bauzas efried: because when we discussed yesterday, I was only thinking of vGPUs affinited to CPUs, not about vCPUs being anti-affinited by NUMA nodes
12:53:05 bauzas so the latter would need something missing now
12:53:21 bauzas and then, in that case, that would be in my spec :
12:57:33 efried bauzas: Yup; and I totally can't answer that question (whether we need explicit anti-affinity/sharding)
12:57:47 bauzas efried: when looking at the doc, see " FLAVOR-NODES: (integer) The number of host NUMA nodes to restrict execution of instance vCPU threads to. If not specified, the vCPU threads can run on any number of the host NUMA nodes available."
12:57:47 efried But your spec definitely must.
12:57:51 bauzas https://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-numa-topology
12:58:17 efried bauzas: Oh, that's interesting. I read that as a *maximum*.
12:58:41 efried In which case, we're covered.
12:58:50 efried sort of
12:58:59 efried We need to split into N numbered request groups
12:59:24 efried The only issue is that we can't specify that in a flexible way - it would have to be specific numbers of procs in each group.
12:59:36 efried and the only reasonable way to do that is to divide them evenly.
13:00:03 efried That still means we get *at most* N separate NUMA nodes, but because granular doesn't guarantee separation, we could get anywhere from 1..N
13:00:13 bauzas that said, in https://docs.openstack.org/nova/latest/admin/cpu-topologies.html
13:00:38 bauzas it says " Inadequate per-node resources will result in scheduling failures. Resources that are specific to a node include not only CPUs and memory, but also PCI and SR-IOV resources. It is not possible to use multiple resources from different nodes without requesting a multi-node layout. As such, it may be necessary to ensure PCI or SR-IOV resources are associated with the same NUMA node or force a multi-node layout."
13:01:02 efried That's fair.
13:01:22 bauzas what I understand from the above is that if I'm asking for 2 nodes but then only have 1 node, then NoValidHost
13:01:33 bauzas that's honeslty confusing
13:01:35 efried no, that's not how I read it.
13:01:52 bauzas also given https://bugs.launchpad.net/nova/+bug/1466780 and " There is no correlation required between the NUMA topology exposed in the instance and how the instance is actually pinned on the host. This is by design. See this invalid bug for more information."
13:01:52 openstack Launchpad bug 1466780 in OpenStack Compute (nova) "nova libvirt pinning not reflected in VirtCPUTopology" [Undecided,Invalid] - Assigned to Stephen Finucane (stephenfinucane)
13:02:06 bauzas but I take that only for CPU pinning
13:02:15 efried I read it to mean, "if you're restricting to one NUMA node, but no single node has all the resources available, NoValidHost" Which is totally legit.
13:02:35 bauzas let's wait for the others, then
13:02:37 kholkina the spec for user-data update need your review https://review.openstack.org/#/c/547964/
13:02:43 efried But it brings us to a different issue, which is whether your spec claims to handle device affinity as well as proc/mem
13:03:05 bauzas efried: that said, if we need to shard, what kind of query param are you thinking ?
13:03:33 openstackgerrit sahid proposed openstack/nova master: libvirt: move version to string in utils https://review.openstack.org/560455
13:03:34 openstackgerrit sahid proposed openstack/nova master: libvirt: refactor get_base_config to accept host arg https://review.openstack.org/560456
13:03:35 openstackgerrit sahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997
13:03:36 bauzas that's the problem with numbered request groups
13:03:41 efried bauzas: For explicitly separating request groups to separate resource providers? I was thinking something like ?separate_providers=resources1,resources2,...
13:03:55 efried ...if placement is where we want to handle it.
13:04:26 efried bauzas: But the other option is to handle it in the NUMATopologyFilter. Placement would give us back all the candidates, which would include the ones that are sharded and the ones that are combined. And the filter would just pick the ones that are appropriately sharded.
13:04:35 bauzas so, ?separate_providers=resources1,resources2&resources1:VCPU=1&resources2:VCPU=1 ?
13:04:44 efried bauzas: yes
13:05:14 efried Implementing that will be a bear, but yes.
13:05:20 bauzas if placement folks are accepting that, then I'd prefer to do that by Placement instead of the filter
13:05:34 bauzas because the less we have in the filter, the better it will be
13:05:42 efried I don't see it making Rocky, tbh

Earlier   Later