| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-16 | |||
| 23:42:37 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.opendev.org/576709 | |
| 23:42:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.opendev.org/576712 | |
| #openstack-nova - 2019-06-17 | |||
| 01:55:44 | tonyb | sean-k-mooney: done. | |
| 03:22:50 | openstackgerrit | Merged openstack/os-vif stable/stein: set ignore_basepython_conflict = True in tox.ini https://review.opendev.org/665195 | |
| 03:26:58 | openstackgerrit | Merged openstack/os-vif stable/stein: Fix mock of built in "open" function in unit tests https://review.opendev.org/665196 | |
| 05:25:46 | openstackgerrit | Merged openstack/nova master: Fix :param: in docstring https://review.opendev.org/665289 | |
| 07:08:36 | openstackgerrit | Yongli He proposed openstack/nova master: Clean up orphan instances virt driver https://review.opendev.org/648912 | |
| 07:08:37 | openstackgerrit | Yongli He proposed openstack/nova master: clean up orphan instances https://review.opendev.org/627765 | |
| 07:35:44 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.opendev.org/621476 | |
| 08:17:37 | openstackgerrit | Tushar Patil proposed openstack/nova-specs master: Update spec: filtering of alloc candidates by forbidden aggregates https://review.opendev.org/665605 | |
| 08:28:58 | openstackgerrit | guangchao.pan proposed openstack/nova master: Add a name for the automatically created volume https://review.opendev.org/660096 | |
| 08:30:44 | openstackgerrit | guangchao.pan proposed openstack/nova master: Add a name for the automatically created volume https://review.opendev.org/660096 | |
| 09:38:13 | openstackgerrit | Mark Goddard proposed openstack/nova master: Exit 1 when db sync runs before api_db sync https://review.opendev.org/665626 | |
| 09:38:14 | openstackgerrit | Mark Goddard proposed openstack/nova master: Update docs on db sync ordering & exit code https://review.opendev.org/665627 | |
| 09:43:43 | openstackgerrit | Mark Goddard proposed openstack/nova master: Exit 1 when db sync runs before api_db sync https://review.opendev.org/665626 | |
| 09:43:43 | openstackgerrit | Mark Goddard proposed openstack/nova master: Update docs on db sync ordering & exit code https://review.opendev.org/665627 | |
| 10:19:36 | bhagyashris | alex_xu, stephenfin, Sean-k-mooney: Hi, I would just like to hear your opinions on http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007144.html | |
| 10:20:14 | stephenfin | bhagyashris: If sean-k-mooney and alex_xu are around, sure | |
| 10:20:24 | stephenfin | I'm replying to the mails one-by-one at the moment | |
| 10:21:05 | bhagyashris | stephenfin: ok thank you! | |
| 10:22:06 | stephenfin | bhagyashris: Do you have anything available to push to Gerrit. I'm getting nervous about how close the next deadline is | |
| 10:22:09 | stephenfin | *? | |
| 10:22:32 | stephenfin | I would like to start reviewing something and iterating nice and quickly if necessary | |
| 10:23:12 | bhagyashris | alex_xu, stephenfin, Sean-k-mooney: I just have concern about this point http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007144.html | |
| 10:23:40 | bhagyashris | stephenfin: once that will be resolve then I will push the patches soon | |
| 10:23:45 | stephenfin | bhagyashris: Just replied to that http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007172.html | |
| 10:24:10 | stephenfin | bhagyashris: tl;dr: don't worry about it because we can rely on host aggregrates | |
| 10:25:08 | stephenfin | If an operator is using them, then pinned instance will always land on hosts in the pinned aggregrate (or whatever it's called). The VCPU inventory of these instances will never be consumed | |
| 10:25:14 | stephenfin | *of these hosts | |
| 10:26:12 | bhagyashris | stephenfin: I have to request to Matt as well. As he has given -2 and abandoned the patches: https://review.opendev.org/#/q/project:openstack/nova+topic:bp/cpu-resources I have submitted earlier | |
| 10:26:54 | stephenfin | If an operator is not using them, then things will be broken, but they were broken before | |
| 10:27:05 | stephenfin | bhagyashris: I can restore those for you if you're planning to re-use them? | |
| 10:27:55 | bhagyashris | stephenfin: yeah I am plaining to use that patches so that will be great if you can restore it :) | |
| 10:28:32 | sean-k-mooney | bhagyashris: the impmenation you did last cycle was not the same as the current spec. they were abandond becayse they had not been updated in many months and the spec was not approved for last cycle | |
| 10:28:34 | bhagyashris | stephenfin: checking your reply.... | |
| 10:29:00 | stephenfin | bhagyashris: Hmm, yeah, looking at them, perhaps it would be better to submit new reviews | |
| 10:32:57 | bhagyashris | stephenfin: yeah but the base implementation has not that much change so I was thinking to push on the same. Only the upgrade patch that anyways not uploaded yet. But if you want to push the new patches then I will push new reviews | |
| 10:34:01 | stephenfin | Yeah, probably easier to just change the commit ID. I don't see that much context that would be useful going forward | |
| 10:34:17 | stephenfin | bhagyashris: Do you think you'll have patches available by the end of this week? | |
| 10:34:25 | stephenfin | At least WIP ones | |
| 10:35:06 | bhagyashris | stephenfin: ok I will push the new patches. Sure I will submit the WIP patches by end of this week | |
| 10:35:07 | sean-k-mooney | looking at the old patches i dont see any logic to soft pin floating instance to the shared_cpu_set | |
| 10:35:20 | sean-k-mooney | i assume that still needs to be written | |
| 10:43:19 | bhagyashris | stephenfin: I just want to ask about your reply that you said the host aggregrates should also be configured correctly that means if user request instance having the flavor extra specs ``resources:PCPU=1 and resources:VPU=1`` on upgrade node then in that case it will report both the VCPU and PCPU resources | |
| 10:43:40 | stephenfin | bhagyashris: No, we're not supporting that at the moment | |
| 10:43:57 | stephenfin | We can support it in U but not in Train | |
| 10:44:38 | stephenfin | Well, we could support it in Train with a big warning that operators need to do their homework, but the spec doesn't encompass that yet | |
| 10:44:51 | sean-k-mooney | stephenfin: its out of scope of the spec | |
| 10:44:54 | bhagyashris | stephenfin: means that flavor (having ``resources:PCPU=1 and resources:VCPU=1``) should have "aggregate_instance_extra_specs:pinned": "true" extra specs as well | |
| 10:45:03 | sean-k-mooney | bhagyashris: no | |
| 10:45:21 | sean-k-mooney | bhagyashris: in train we do not plan to allow host to have both pinned and non pinned cpus | |
| 10:45:23 | stephenfin | As noted in the other email, that was dropped from the spec to focus on getting the important piece - PCPU tracking in placement - done | |
| 10:45:27 | sean-k-mooney | *instances | |
| 10:45:33 | stephenfin | yeah, what sean-k-mooney said | |
| 10:45:49 | sean-k-mooney | host can be mixed but instances cannot, in train | |
| 10:47:41 | bhagyashris | sean-k-mooney : means operator can set either dedicated_set or shared_set only and not the both the set attime ? | |
| 10:47:55 | stephenfin | They can set both | |
| 10:48:04 | sean-k-mooney | mixing pinned and non pinned cpus in a singel instance was not allowed in the spec last cycle either. it was part fo a different spec. | |
| 10:48:05 | stephenfin | cpu_shared_set is also used for emulator threads | |
| 10:48:20 | stephenfin | sean-k-mooney: Nah, it was part of the spec but I scrubbed references to it | |
| 10:48:37 | stephenfin | What wasn't included was the NUMA stuff | |
| 10:48:41 | sean-k-mooney | stephenfin: hum maybe the other spec got folded in at some point | |
| 10:48:43 | stephenfin | *was never included | |
| 10:48:47 | stephenfin | Quite possibly, yeah | |
| 10:49:39 | stephenfin | bhagyashris: We're totally for supporting instances with pinned and unpinned instances in the future but not yet. This is just too complex already without adding more complexity | |
| 10:49:46 | stephenfin | and not having it makes upgrades simpler, as you note | |
| 10:50:42 | stephenfin | So if you have patches adding this functionality, I would leave them to the end of the series and wouldn't focus your attention on them yet. They won't merge so you'd be wasting effort | |
| 10:51:20 | bhagyashris | stephenfin: if operator can set both the set say cpu_dedicated_set and cpu_shared_set then in that case inventory reported in the placement will be PCPU and VCPU right? | |
| 10:51:35 | stephenfin | Yes | |
| 10:52:00 | sean-k-mooney | bhagyashris: what i was refering to before about soft pinning is that when you are mixing pinned guests with floating guests we need to ensure the floating guest only float over teh cpu_shared_set when cpu_dedicated_set is defiend | |
| 10:52:15 | sean-k-mooney | bhagyashris: yep | |
| 10:52:22 | stephenfin | and, in theory, they could stop using host aggregates to separate pinned instances from non-pinned instances at that point | |
| 10:52:49 | stephenfin | because the non-pinned instances will only float on the cores listed in cpu_shared_set | |
| 10:53:03 | stephenfin | Or "soft pinning", as sean-k-mooney points out | |
| 10:53:22 | sean-k-mooney | its the same as what we do for numa | |
| 10:53:31 | sean-k-mooney | if you dont also enable cpu pinning | |
| 10:53:44 | sean-k-mooney | we confine the cpus to float over a numa node | |
| 10:54:05 | stephenfin | yup, though we shouldn't care about NUMA affinity for the non-NUMA and non-pinned case | |
| 10:54:14 | sean-k-mooney | correct | |
| 10:54:40 | stephenfin | sean-k-mooney: This reinforces how important artom's NUMA live migration work is though | |
| 10:54:59 | stephenfin | we'll need that to make sure the soft pinning information is recalculated when we live migrate | |
| 10:56:01 | sean-k-mooney | stephenfin: yes we will we already have accounted for that in his work | |
| 10:56:14 | sean-k-mooney | we support the soft pinning case for numa | |
| 10:56:20 | stephenfin | awesome | |
| 10:56:33 | sean-k-mooney | so we just need to ensure that we also pass back the info for non pinned guests | |
| 10:56:42 | stephenfin | Yup | |
| 10:56:44 | stephenfin | bhagyashris: Any other questions before I disappear for lunch? | |
| 10:56:57 | sean-k-mooney | so there should be a change in the cpu pinning spec that extend what he is doing for shared instances | |
| 10:57:47 | sean-k-mooney | * not spec but patch series | |
| 10:58:15 | bhagyashris | s so in that case it will consume both the inventories | |
| 10:58:15 | bhagyashris | stephenfin: but the host aggregates will come into picture only when the host are under that aggregate and that aggregate having meta data pinned and flavor also need to set the extra specs "aggregate_instance_extra_specs:pinned": "true" but as per the new implementation and flavor having new flavor extra specs (``resources:PCPU=1 and resources:VCPU=1``) and dont have "aggregate_instance_extra_specs:pinned": "true" extra spec | |
| 10:59:06 | sean-k-mooney | "resources:PCPU=1 and resources:VCPU=1" is not valid in train | |
| 10:59:23 | sean-k-mooney | bhagyashris: we can have the api reject instance with that config | |
| 10:59:29 | stephenfin | Yeah, you need to stop worrying about that. We can't and won't support it in Train | |
| 10:59:43 | stephenfin | In fact, we should have an explicit check to prevent that | |
| 11:00:18 | stephenfin | Until we get to U and submit a new spec for adding this functionality | |
| 11:00:38 | sean-k-mooney | stephenfin: bhagyashris ya we should alex_xu pointed out that there is already a check in the api tha validates the numa and pinning extra_specs are valide so we can extend it | |
| 11:02:27 | bhagyashris | stephenfin, sean-k-mooney : but ie user request it separately say in the first request he request resources:PCPU=1 and in second request he request resources:VCPU=1 then it will consume the resources form the same cpu_set | |
| 11:02:48 | sean-k-mooney | bhagyashris: what second request | |
| 11:02:57 | sean-k-mooney | do you mean two different vms? | |