| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-16 | |||
| 17:24:19 | mriedem | BobBall: johnthetubaguy: ^ | |
| 17:24:29 | mriedem | dansmith: sdague: ^ let me know if you think that's wacky | |
| 17:24:35 | mriedem | but i kind of want to get that into ocata to set the timer | |
| 17:27:09 | sdague | mriedem: I'd be fine with it. I think that given the lower level of xenserver usage, things like that can move a bit more nimbly | |
| 17:27:20 | dansmith | mriedem: why is it whacky? | |
| 17:27:22 | cfriesen | andreykurilin: mriedem: would it make sense to push https://review.openstack.org/#/c/429512 for Ocata so that the client/server match up on their max version support? Then we can go back and fix up the intermediate versions where tags were broken. | |
| 17:27:26 | dansmith | er, wacky.. heh | |
| 17:27:33 | mriedem | dansmith: just b/c i want to get it into ocata | |
| 17:27:37 | mriedem | not really wacky | |
| 17:28:01 | mriedem | cfriesen: huh? | |
| 17:28:04 | dansmith | seems decidedly unwacky to me | |
| 17:28:12 | mriedem | cfriesen: novaclient is frozen for ocata | |
| 17:28:16 | mriedem | except for backporting fixes | |
| 17:28:47 | sdague | BobBall: mriedem: why is this failing xenserver ci? - https://review.openstack.org/#/c/424428/12 | |
| 17:29:11 | cfriesen | mriedem: so we have nova with max version 2.42 but novaclient with 2.41? | |
| 17:29:38 | mriedem | sdague: everything is | |
| 17:29:39 | cfriesen | mriedem: and no way to make use of the fact that 2.42 fixes tags? | |
| 17:29:40 | mriedem | known issue | |
| 17:29:53 | mriedem | cfriesen: novaclient will work with 2.42 | |
| 17:30:05 | mriedem | oh i guess we didn't set the max api thing in novaclient | |
| 17:30:08 | cfriesen | API_MAX_VERSION = api_versions.APIVersion("2.41") | |
| 17:30:22 | cfriesen | that's what https://review.openstack.org/#/c/429512 does | |
| 17:30:26 | mriedem | yeah, well, we can't release novaclient for ocata right now | |
| 17:30:37 | mriedem | cfriesen: i think we'll just need to backport that as a bug fix later | |
| 17:30:39 | mriedem | to stable/ocata | |
| 17:31:10 | sdague | mriedem: ok, so are we waiting for it to work? | |
| 17:31:18 | sdague | or is it safe to push it in | |
| 17:31:52 | mriedem | sdague: it's safe | |
| 17:32:07 | mriedem | the xenserver ci uses the ovs vif driver already | |
| 17:32:11 | mriedem | i checked that earlier | |
| 17:32:20 | mriedem | b/c the xenserver ci on master is neutron, and has to use the ovs driver | |
| 17:34:06 | sdague | mriedem: eta on xenserver ci coming back to life? | |
| 17:34:32 | mriedem | sdague: (10:50:14 AM) BobBall: mriedem: sorry for the sadness in the XenServer CI - as mentioned to frickler above, we have identified the probable cause for the ssh timeouts (we had two neutron agents with the same hostname - which meant sometimes the wrong agent was picked for something or other...). A fix was made today, but further investigation is being done to prove it doesn't break secure groups (there was some suggestion yesterd | |
| 17:34:39 | mriedem | (10:52:02 AM) BobBall: Indeed. There are many false negatives today - but rechecks should fix them now. Hopefully we'll have the proper fix in the CI early next week and we will re-enable these tests. | |
| 17:35:07 | openstackgerrit | Roman Podoliaka proposed openstack/nova-specs master: Strict isolation of group of hosts for image and flavor https://review.openstack.org/381912 | |
| 17:36:12 | mriedem | sdague: so maybe results within the hour or two? | |
| 17:36:25 | mriedem | sdague: keeping in mind i need to backport this to ocata and get it merged there before we can cut rc2 today | |
| 17:37:53 | mriedem | sdague: oh you got the bottom change too, thanks | |
| 17:37:59 | mriedem | fwiw john was +2 on that yesterday | |
| 17:38:07 | mriedem | i just found some corner cases that needed updating, so the bottom change is safe | |
| 17:38:13 | sdague | mriedem: yeh | |
| 17:51:28 | mriedem | backports are up for those xen patches | |
| 17:51:30 | mriedem | going to lunch | |
| 17:51:51 | openstackgerrit | Ben Nemec proposed openstack/nova-specs master: Configurable PXE Boot for Instances https://review.openstack.org/435052 | |
| 18:12:36 | openstackgerrit | Sujitha proposed openstack/nova master: Change tags to default field in Instance object. https://review.openstack.org/415298 | |
| 18:12:48 | openstackgerrit | MarkMielke proposed openstack/nova master: DiskFilter should only apply when storage is requested https://review.openstack.org/430091 | |
| 18:18:27 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: rename can_host to shared https://review.openstack.org/433977 | |
| 18:18:27 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: get inventory shared with provider https://review.openstack.org/433978 | |
| 18:25:22 | openstack | Launchpad bug 1581230 in OpenStack Compute (nova) "Nova should not inspect cinder volume state during attach" [Medium,In progress] - Assigned to Ildiko Vancsa (ildiko-vancsa) | |
| 18:25:22 | jaypipes | mriedem1: on https://bugs.launchpad.net/nova/+bug/1581230, walt asks "Nova shouldn't care about the internal state management of Cinder Volumes. What happens if Cinder adds a new state that Nova doesn't know about?" | |
| 18:25:45 | jaypipes | mriedem1: I guess I'm wondering why internal state is being exposed out of Cinder's API, then? | |
| 18:26:24 | mriedem | jaypipes: well it's true that nova doesn't need or want to check the attached state of a volume if we're just going to reserve it, because the reserve action will do that atomically for us on the cinder side | |
| 18:26:31 | mriedem | the resulting error from the nova side is the same either way | |
| 18:26:46 | jaypipes | mriedem: k. | |
| 18:26:47 | mriedem | unreserve on the cinder side is idempotent | |
| 18:27:03 | mriedem | i think all of that old attach status checking is probably from nova-volume | |
| 18:27:06 | jaypipes | mriedem: cool (as it should be) | |
| 18:27:21 | jaypipes | the idempotency, not the nova-volume :) | |
| 18:28:01 | mriedem | right | |
| 18:28:21 | jaypipes | mriedem: in any case, I'm reviewing the patch now... | |
| 18:29:02 | mriedem | cool, it's going to be discussed next week too, and i've sort of started thinking a spec for this might be nice | |
| 18:29:12 | mriedem | since it's pretty invasive about how much of the machinery it's touching | |
| 18:29:21 | mriedem | api, conductur, upgrades, bfv, etc | |
| 18:31:48 | openstack | Launchpad bug 1665370 in tripleo "api db_sync fails on upgrade due to duplicate migration files" [Critical,Triaged] - Assigned to Steven Hardy (shardy) | |
| 18:31:48 | mriedem | shardy_afk: owalsh: any updates on https://bugs.launchpad.net/nova/+bug/1665370 ? | |
| 18:31:56 | mriedem | i'm unclear on if we're making a change in nova for that | |
| 18:32:18 | dansmith | mriedem: we think not | |
| 18:33:21 | owalsh | mrodden: I think it's a pkg issue in this case, shardy_afk is trying to reproduce it | |
| 18:33:32 | mriedem | uh oh | |
| 18:33:36 | mriedem | someone woke the mrodden troll | |
| 18:33:38 | owalsh | oop ^^ | |
| 18:36:48 | owalsh | mriedem (too many m... nicks here), dansmith do we need to worry about it for pip or setup.py? | |
| 18:37:19 | dansmith | owalsh: pip will do the right thing I think | |
| 18:37:28 | dansmith | owalsh: setup.py has this kind of issue in other places, so I think we're probably okay there | |
| 18:43:40 | mordred | mriedem, jaypipes: just reading a little scrollback - may or may not be relevant - but we're seeing not-infrequent flaky test issues in shades functional tests these days inside the flow "delete server ; delete volumes that were attached to server" | |
| 18:44:06 | mordred | mriedem, jaypipes: specifically because the volume throws an error that you can't delete an attached volume | |
| 18:44:22 | mordred | I know that's a cinder not a nova thing - but since you're tlaking about the attach flow I figured I'd mention it | |
| 18:45:17 | mriedem | mordred: you're racing | |
| 18:45:32 | smcginnis | Yeah, that sounds like the attach hasn't finished before trying to delete. | |
| 18:45:34 | melwitt | does anyone know if there's a way to see all of the code module docs on https://docs.openstack.org/developer/nova ? | |
| 18:45:37 | smcginnis | *dettach | |
| 18:45:40 | mriedem | smcginnis: the detach | |
| 18:45:43 | mriedem | yeah | |
| 18:45:53 | smcginnis | Keyboard... | |
| 18:46:04 | mriedem | mordred: tempest flow is usually create volume, create server, attach volume to server, detach volume, delete volume, delete server, | |
| 18:46:06 | mriedem | sometihng like that | |
| 18:46:21 | sdague | melwitt: we pulled that part out of the docs a while ago because so little was actually docs | |
| 18:46:24 | sdague | docced | |
| 18:46:27 | mriedem | nova will detach the volume, but you have to wait for the volume to be 'available' before you can delete it | |
| 18:46:33 | melwitt | k, thanks sdague | |
| 18:50:46 | mordred | mriedem: yah - that's the basic flow we're doing now (I just recently added the wait-for-volume-available) - tempest is apparently also seeing some flakiness in the same general flow | |
| 18:50:56 | mordred | mriedem: jordanP is looking in to it some | |
| 18:51:15 | mriedem | guess it depends on the specific low, | |
| 18:51:16 | mriedem | *flow | |
| 18:51:29 | mriedem | if you do boot from volume with delete_on_termination=True, then nova deletes the volume | |
| 18:51:37 | mriedem | when you delete the server | |
| 18:55:49 | mordred | yah. we have different tests for that - it was "boot server ; create volume ; attach volume ; delete server ; delete volume" that's the issue - but I'll keep working to figure out more places I can poll :) | |
| 19:12:23 | dansmith | mriedem: melwitt: do you have any opinion on this? https://review.openstack.org/#/c/433362/3/nova/api/openstack/compute/servers.py@1159 | |
| 19:12:47 | dansmith | like, whether we should target from the REST API side, or modify every compute/api method to take the mapping, | |
| 19:12:59 | dansmith | or stash the mapping legally or illegally inside the instance somewhere? | |