| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-03 | |||
| 17:59:44 | mriedem | yeah; https://review.openstack.org/#/c/530982/ on stable/newton failed but +1ed the change | |
| 17:59:48 | mmedvede | mriedem: I maintain kvm on power CI, yes | |
| 17:59:58 | mriedem | should we just not run pkvm ci on newton changes? | |
| 18:00:05 | mriedem | that branch is nearly eol | |
| 18:00:28 | mriedem | 2018-01-03 17:51:43.289 | error: pathspec 'stable/newton' did not match any file(s) known to git. | |
| 18:01:20 | mmedvede | mriedem: there is actually a fix for that in the pipeline, let me dig it out | |
| 18:01:39 | mmedvede | it affects all non-zuulv3 third-party CIs | |
| 18:03:02 | mmedvede | mriedem: https://review.openstack.org/#/c/523925/ | |
| 18:05:17 | mmedvede | the CI failing but still +1 the change is due to there being only non-voting job in the set | |
| 18:05:24 | mriedem | i feel like i recently made a similar change to devstack in newton | |
| 18:05:47 | mriedem | ah yes https://review.openstack.org/#/c/519758/ | |
| 18:06:11 | mriedem | https://review.openstack.org/#/c/520095/ | |
| 18:06:11 | mriedem | and apparently it was my devstack-gate patch they are referencing | |
| 18:07:54 | mriedem | sdague: you around for devstack-gate +2? https://review.openstack.org/#/c/523925/ | |
| 18:07:59 | mmedvede | d-g is accumulating lots of cruft due to having to support zuulv3/v2 at the same time :( | |
| 18:09:53 | mmedvede | mriedem: I'll watch the patch, if the fix would not land I'll disable our CI on stable/newton | |
| 18:11:44 | mriedem | ok | |
| 18:28:10 | mriedem | cdent: you want to take a crack at a release note for this? https://review.openstack.org/#/c/448034/ | |
| 18:30:37 | cdent | mriedem: ya, thanks, will look, I don't know much about that one (just did the rebase) but should be able to do it up | |
| 18:31:00 | mriedem | stephenfin: seeing a TypeError in testing the websocket proxy series http://logs.openstack.org/50/530950/1/check/legacy-tempest-dsvm-py35/1dffae7/logs/screen-n-novnc.txt.gz?level=TRACE#_Jan_03_16_09_08_830407 | |
| 18:31:13 | mriedem | in the py35 job | |
| 18:31:24 | cdent | will check with rado first | |
| 18:33:29 | mriedem | huzzah, i've done my job https://review.openstack.org/#/c/345398/ | |
| 18:37:43 | melwitt | mriedem: weird, I wonder how the tempest py35 passed on my DNM patch but not with yours on the console proxy with TLS stuff | |
| 18:38:32 | mriedem | melwitt: because you were configuring one specific job | |
| 18:38:35 | mriedem | which doesn't use py35 | |
| 18:38:41 | melwitt | oh, right. derp | |
| 18:55:07 | openstackgerrit | Chris Dent proposed openstack/nova master: VMware: add support for different firmwares https://review.openstack.org/448034 | |
| 18:56:46 | cdent | I had an amusing conversation with someone outside of openstack today about the complex bits of placement and scheduling and he said what many people have said before: maybe there needs to be an openstack for "give me a vm" and a different openstack for "I am a telco" | |
| 18:57:36 | jaypipes | cdent: bingo. | |
| 18:57:59 | cdent | I thought that might draw you out :) | |
| 19:01:06 | melwitt | hah, I like that. openstack Telco Edition(tm) | |
| 19:01:23 | cdent | now including a super upper ontology | |
| 19:07:10 | ildikov | and it's only the 3rd of January... :) | |
| 19:10:58 | hrw | guys: can you look at https://review.openstack.org/#/c/530965/ one? It is probably wrong way of doing it and I am open for suggestions | |
| 19:23:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: VMware: add support for different firmwares https://review.openstack.org/448034 | |
| 19:25:28 | stvnoyes | mriedem: Hi Matt, I was talking to ildikov and she suggested I could help with https://review.openstack.org/#/c/266605 , the tempest multiattach test. I see you've been working on it recently. Any objections to me taking it on? | |
| 19:31:58 | ildikov | stvnoyes: I mentioned it mriedem today that we talked about that test and that we can talk about the desired test coverage in Tempest on the meeting tomorrow | |
| 19:32:19 | mriedem | i'm debugging the failure now - can't create a multiattach volume | |
| 19:32:38 | ildikov | mriedem: it's disabled in Cinder | |
| 19:33:14 | ildikov | mriedem: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/lvm.py#L279 | |
| 19:33:29 | mriedem | _filter.py:74}} | |
| 19:33:29 | mriedem | Jan 03 14:42:03.502967 ubuntu-xenial-citycloud-sto2-0001666901 cinder-scheduler[12541]: DEBUG cinder.scheduler.filters.capabilities_filter [None req-ecbc7305-ea6f-438b-af55-028c5b6eeb03 tempest-AttachVolumeMultiAttachTest-1915307512 None] Volume type extra spec requirement "multiattach=<is> True" does not match reported capability "False" {{(pid=12541) _satisfies_extra_specs /opt/stack/cinder/cinder/scheduler/filters/capabili | |
| 19:33:56 | stvnoyes | ||
| 19:33:56 | stvnoyes | @page { margin: 0.79in } pre { direction: ltr; text-align: left; orphans: 2; widows: 2 } pre.western { font-family: "Times New Roman", serif; font-size: 12pt } pre.cjk { font-family: "SimSun"; font-size: 12pt; so-language: zh-CN } pre.ctl { font-family: "Times New Roman"; font-size: 12pt } p { margin-bottom: 0.1in; direction: ltr; line-height: 120%; text-align: left; orphans: 2; widows: 2 } p.western { fo | |
| 19:34:03 | stvnoyes | ugh! | |
| 19:34:34 | stvnoyes | multiattach = True | |
| 19:34:34 | stvnoyes | - Need the lvm driver to support MA - in cinder/volume/drivers/lvm.py , line 280 > | |
| 19:35:05 | stvnoyes | there are also issues in tempest detach, I'm working on that now | |
| 19:35:36 | ildikov | stvnoyes: what's the issue with detach? | |
| 19:35:59 | mriedem | tempest assumes that when you detach the volume will eventually be 'available' | |
| 19:36:10 | mriedem | but with multiattach it will go from in-use to in-use | |
| 19:36:20 | mriedem | until the last attachment is gone | |
| 19:36:24 | ildikov | stvnoyes: there's a whole chain to address shared_targets issues: https://review.openstack.org/#/c/529695/ | |
| 19:36:31 | stvnoyes | from what I see so far, at the end of the test it tries to detach, but when it detaches the vol from the first server, the vol status doesn't go to abailable (as we would expect) but the test wants to see available | |
| 19:36:35 | ildikov | however I'm not sure that's applicable for lvm... | |
| 19:36:45 | mriedem | ildikov: different issues | |
| 19:37:00 | mriedem | i didn't realize that cinder hard-coded this in all drivers across the board | |
| 19:37:11 | ildikov | ah ok, sorry, I thought actual issues and not things we need to update | |
| 19:37:19 | mriedem | that should have probably been a global policy change in the API | |
| 19:37:48 | stvnoyes | I think we will need to pass in an expected status to detach so it knows what success means | |
| 19:37:53 | ildikov | I think they also wanted to ensure that driver maintainers think about it for at least two seconds before turning it on | |
| 19:38:20 | mriedem | stvnoyes: not sure that is necessary - we can just count the attachments first, and if the volume has multiattach=True | |
| 19:38:34 | stvnoyes | y, that should work too | |
| 19:38:52 | stvnoyes | and is simpler... | |
| 19:39:06 | mriedem | ildikov: so is https://review.openstack.org/#/c/428365/ going to be reverted at the same time that a policy rule is put in place? | |
| 19:39:36 | mriedem | not even a release note on that change which effectively breaks the API | |
| 19:40:33 | ildikov | well, it was never really supported anyway... | |
| 19:40:55 | ildikov | I would think that we turn back the drivers more one-by-one | |
| 19:41:34 | mriedem | ok so i'll push a WIP cinder patch to turn this on for lvm to at least get some test coverage going | |
| 19:42:02 | ildikov | but I can double check it with jgriffith or someone who feels brave enough to answer that question... :) | |
| 19:42:18 | mriedem | i just need to move the testing along, so i'm ok for now | |
| 19:44:57 | ildikov | mriedem: is there anything stvnoyes can help out or you're dedicated to make this one work? | |
| 19:45:35 | mriedem | i'm ok for now, wait until i'm stuck or don't have time to look | |
| 19:46:12 | stvnoyes | ok, that's fine. If there's something else I can help with, let me know. | |
| 19:46:19 | ildikov | mriedem: ok, cool, tnx | |
| 19:47:01 | mriedem | stvnoyes: have you read my comments in https://review.openstack.org/#/c/271047/ ? | |
| 19:47:04 | openstackgerrit | Chris Dent proposed openstack/nova master: Document lack of side-effects in AllocationList.create_all() https://review.openstack.org/530997 | |
| 19:47:17 | mriedem | could use more eyes on what, if any, restriction we're going to put in the compute api for multiattach and the new microversion | |
| 19:47:58 | stvnoyes | mriedem: i haven't looked at it yet. I'll take a look. | |
| 19:57:58 | mriedem | oh nice, | |
| 19:57:59 | mriedem | http://paste.openstack.org/show/637525/ | |
| 19:58:06 | mriedem | trying to attach a volume to more than one instance results in a 500 | |
| 20:01:05 | mriedem | Unable to create attachment for volume (Invalid volume: Volume 373c2a29-f6e7-4931-adda-6b87a193e9f9 status must be available or downloadi | |
| 20:03:42 | ildikov | mriedem: for a multiattach volume? | |
| 20:03:51 | mriedem | no, not multiattach | |
| 20:03:59 | mriedem | i wanted to make sure that still is prohibited | |
| 20:04:16 | openstackgerrit | Chris Dent proposed openstack/nova master: Fix documentation nits in set_and_clear_allocations https://review.openstack.org/531001 | |
| 20:04:37 | ildikov | oh, ok :) | |
| 20:08:53 | mriedem | hmm, why would i get a 400 in the case of os-reserve but a 500 from cinder in the case of attachment_create? | |
| 20:10:25 | mriedem | i would think the ResourceExceptionHandler would be used in both cases | |
| 20:10:33 | mriedem | that converts InvalidVolume to a 400 response | |
| 20:44:46 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Simplify logic in get_enforcer https://review.openstack.org/531008 | |
| 20:55:10 | edleafe | mriedem: got a minute to talk about resize? | |
| 20:55:35 | mriedem | sure | |
| 20:56:42 | edleafe | we recently changed it to do 'replace_allocation_with_migration' to have the allocations use the migration uuid | |
| 20:57:19 | edleafe | It checks to verify that the instance is allocated against the source node, and if it isn't raises an error | |
| 20:57:57 | edleafe | But with claiming in the scheduler, select_destinations will claim against the target host | |
| 20:58:09 | edleafe | So the replace method always fails | |
| 20:58:56 | mriedem | edleafe: i can see that being true in the reschedule case, | |