| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-16 | |||
| 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? | |
| 19:14:54 | frickler | mriedem: not sure if you have seen this, there seems to be another nonvc issue, unrelated to py3, but in the multinode case. I'm thinking https://review.openstack.org/434996 might help but that surely needs some more eyes on it | |
| 19:15:54 | melwitt | dansmith: I think I remember we discussed this a bit before with alaski where an idea came up about stashing the targeted context in instance._context to avoid having to target everywhere | |
| 19:16:11 | dansmith | hmm | |
| 19:16:52 | dansmith | melwitt: the thing that kinda concerns me about that is that it becomes super obscure such that someone will come along and use that context to try to do something elsewhere and not know it's targeted | |