| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-16 | |||
| 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 | |
| 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. | |
| 02:13:35 | melwitt | ileixe: this is the spec for the work https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/placement-claims.html and the blueprint https://blueprints.launchpad.net/nova/+spec/placement-claims where you can find links to related patches | |
| 02:14:21 | ileixe | melwitt: Thanks! | |
| 02:14:36 | melwitt | if you are on a version older than pike, I would increase the scheduler_host_subset_size option to reduce the chances of collisions with parallel requests | |
| 02:14:38 | melwitt | yw | |
| 02:15:34 | ileixe | Yes actually we increased the configs exactly what you mentioned. And it still sometime happens so I tried to alternatives :) | |
| 02:15:51 | melwitt | oh, I see. got it | |
| 02:23:54 | mriedem | ileixe: are you using the CachingScheduler or FilterScheduler? | |
| 02:24:02 | mriedem | and are you running multiple scheduler workers? | |
| 02:24:17 | ileixe | Yes 4 FilterScheduler | |
| 02:24:43 | mriedem | ok, that's normal, | |
| 02:24:52 | mriedem | then yes host_subset_size will need to be >1, which you've done | |
| 02:25:23 | mriedem | maybe check your weigher configuration? | |
| 02:26:16 | ileixe | 10 we've been used | |
| 02:26:47 | ileixe | and default for retry attempt | |
| 02:27:05 | ileixe | So I was going to increase try attepmts. | |
| 02:27:25 | ileixe | But placement api seems to be optimal solution. :) | |
| 02:27:59 | openstackgerrit | Merged openstack/nova master: Add zvm admin intro and hypervisor information https://review.openstack.org/533125 | |
| 02:36:21 | mriedem | ileixe: yes placement will do an atomic claim on vcpu,ram,disk in the scheduler rather than the late racy claim on the compute host | |
| 02:36:35 | mriedem | you can still race to fail claims for things like numa/pci since we don't model that in placement yet | |
| 02:36:41 | mriedem | but maybe that's not your major issue | |
| 02:39:51 | ileixe | mriedem: Greate. Oh, I found now resources are updated in scheduler itself. | |
| 02:40:07 | ileixe | Thanks guys. Lovely change. | |
| 02:58:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | |
| 02:59:34 | mriedem | melwitt: final zvm docs change is approved | |
| 02:59:38 | mriedem | should be able to cut rc2 after that merges | |
| 03:01:57 | mriedem | +2 on that forced_down docs change as well | |
| 03:10:13 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Update contributor guide for Stein https://review.openstack.org/591258 | |
| 03:21:04 | openstackgerrit | Merged openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | |
| 03:24:21 | Kevin_Zheng | mriedem just came to my head, another thing that strict project to cells won't help much for us is that, we have admin softwares that queries with --all_tenants | |
| 03:26:35 | mriedem | Kevin_Zheng: well, it wouldn't help that specific software, but it would help user server list response timem | |
| 03:26:36 | mriedem | *time | |
| 03:26:52 | mriedem | CERN obviously would have the same issue for admin tooling | |
| 03:26:54 | Kevin_Zheng | yeah I know | |
| 05:54:03 | openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | |
| 06:21:11 | nehaalhat | stephenfin: Hi do you know any periodic task that will update the aggregates list in Nova? | |
| 07:11:49 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the deprecated API extensions policies https://review.openstack.org/586872 | |
| 07:58:58 | openstackgerrit | Merged openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | |
| 08:26:30 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | |
| 08:40:58 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656 | |
| 08:40:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 08:41:00 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 08:41:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 08:41:02 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 08:50:48 | openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | |
| 09:04:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730 | |
| 09:25:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 09:39:02 | kosamara | efried: about trait "ownership": Given RP ownership, the only issue that I see trait ownership addressing is the separation of generated and user-provided traits. I see your discussion with Sundar (https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst@173), but is this actually an issue if RPs are owned by the drivers? | |
| 09:44:30 | kosamara | efried: And for separating user and generated traits, I would also like to hear your argument. When you say "conflict" between the 2, you imply a set of rules that make some traits mutually exclusive? | |
| 09:47:08 | sean-k-mooney | kosamara: we promised operators the ablitiy to add traits to any resouce provider in the past | |
| 09:48:55 | sean-k-mooney | so there is a confilt in that the virt drivers would like to fully own the traits on the resouces they create and the fact that we said operator can add traits to resouce provirers that the virt driver may not be able to determin itself | |
| 09:51:20 | sean-k-mooney | kosamara: also some traits could be multally inclusive such as a disk can both be an ssd and mechanical | |
| 09:52:33 | sean-k-mooney | kosamara: we dont model the compatiablity of traits anyehere and curerntly assume the entity adding the traits will do the right thing | |
| 09:53:22 | sean-k-mooney | for standard traits we might be able to handel that in os-tratis but in general it a problem that we cant fix directly. | |
| 09:53:50 | sean-k-mooney | at least in the CUSTOM_ case | |
| 09:57:56 | kosamara | sean-k-mooney: ok, so the namespacing addresses the operator vs generated part. What I actually don't understand is why the driver *must* fully own the traits, over the operator. If we accept that, then namespacing makes sense, so please explain to me that. | |
| 10:00:37 | sean-k-mooney | well im not sure how namespacing is proposed to work. my understanind is that prevent both the operator and virt drivers form both using stadard traits as such i do not see that as a viable option | |
| 10:01:13 | sean-k-mooney | e.g. either the operator or the virt direver would be able to use the un namespaced standard tratis | |
| 10:06:29 | kosamara | sean-k-mooney: See here the traits sections of my 2nd PS draft: https://etherpad.openstack.org/p/device-placement-passthrough-2 | |
| 10:07:41 | kosamara | sean-k-mooney: exactly, that could be an issue. But still I'm not clear on this, let's wait for efried's input | |
| 10:09:04 | sean-k-mooney | kosamara: i would be stongly opposed to having a CUSTOM_%(virt_driver)_ prefix if i ever need to set that in a flavor to match against it | |
| 10:09:56 | sean-k-mooney | well that depends | |
| 10:10:36 | sean-k-mooney | if the driver ever generated a CUSTOM_%(virt_driver)_ trait for something that was a standard trait then i think that is a very bad design | |
| 10:11:51 | sean-k-mooney | e.g. i should be able to jsut say HW_CPU_X86_AVX not CUSTOM_LIBVIRT_HW_CPU_X86_AVX | |
| 10:13:07 | sean-k-mooney | if a virt driver has a capablity that is truely unique to it, then i can see it useing a CUSTOM_%(virt_driver) trait that siad i would still prefer them to standarise it in os-tratis | |
| 10:23:08 | sean-k-mooney | kosamara: i have added a potentally dumb alternitive to https://etherpad.openstack.org/p/device-placement-passthrough-2 | |