Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-16
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
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

Earlier   Later