Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-28
15:51:43 mriedem since...who knows how long, right?
15:51:48 mriedem and their CI never caught this?
15:51:54 claudiub yeah, that's pretty much what I get from it as well.
15:52:08 mriedem should be a -2 on all vmware driver specs until they can fix their CI then
15:52:24 openstackgerrit Eric Fried proposed openstack/nova master: Slugification utilities for placement names https://review.openstack.org/556628
15:52:29 melwitt yeah, I'm trying to find what's up with their CI. maybe it only runs on vmware driver patches?
15:52:40 claudiub that method is called in destroy
15:52:43 melwitt I noticed the xen driver CI works like that. it only runs on xen driver patches
15:53:51 claudiub i think that they can still attach / detach volumes, but it will fail when they're destroying instances with volumes attached.
15:54:08 claudiub still should have been caught by their CI in boot-from-volume cases
15:54:16 mriedem so maybe just got lucky by tempest always detaching volumes before they were deleted
15:54:58 claudiub can you detach a volume which is used as boot-from-volume?
15:55:12 melwitt I didn't think so
15:55:18 mriedem no
15:55:39 mriedem their CI doesn't usually report at all
15:55:45 mriedem https://review.openstack.org/#/c/553411/ was posted on march 15
15:55:48 mriedem no CI response
15:56:13 melwitt ah, bummer. I checked on the xen one recently and it has recent runs but only on xen patches
15:56:43 mriedem i'm personally fine with 3rd party CI running on restricted sets of the tree
15:56:48 mriedem for the most part
15:57:01 mriedem but to not run on changes for that driver at all, is unacceptable
15:57:05 melwitt yup, same. the only downside is it's harder to notice when it goes MIA
15:57:14 mriedem i used to have to post a quarterly thing to the ML about how the vmware CI wasn't running or was broken
15:57:15 melwitt but that's a lot more minor thing
15:57:50 melwitt yeah, I remember
16:00:00 melwitt I'll mail the list about the vmware CI, see if anyone responds this time
16:01:48 openstackgerrit Claudiu Belu proposed openstack/nova master: vmware: Fixes _detach_instance_volumes method https://review.openstack.org/557377
16:02:26 openstackgerrit Matt Riedemann proposed openstack/nova master: vmware: log quality warning on startup https://review.openstack.org/557398
16:04:27 openstackgerrit Eric Fried proposed openstack/nova master: Make generation optional in ProviderTree https://review.openstack.org/539324
16:12:32 mriedem edleafe: nvm, the docs thing for placement and 1.21 can be fixed in https://review.openstack.org/#/c/554357/
16:13:05 edleafe mriedem: heh, I was just about to push a fix
16:13:33 edleafe I'll just combine them
16:18:33 lyarwood dansmith: https://review.openstack.org/#/c/557348/ - would you mind looking at this retry_on_request removal backport to stable/pike that came up internally earlier?
16:18:58 dansmith lyarwood: I assume we don't need to do that in upstream stable because of g-r right?
16:19:12 dansmith (if it's not already broken I mean)
16:19:54 lyarwood dansmith: well upstream outside of TripleO no we don't need to do this
16:20:04 lyarwood dansmith: but even with g-r I think this is broken for TripleO
16:20:16 dansmith I would defer to mriedem on that
16:20:36 dansmith if it's capped by u-c I think we're fine as-is, and if not, we broke ourselves
16:21:02 dansmith I would suspect maybe upstream tripleo isn't honoring u-c?
16:21:15 lyarwood very likely
16:21:37 lyarwood it's all RPMs there and I don't recall seeing the same u-c rules in the specs
16:23:04 mriedem -
16:23:06 mriedem -1
16:23:08 mriedem -5
16:23:14 mriedem b/c of what dan said
16:23:25 mriedem the decorator was removed in oslo.db 4.30,
16:23:32 mriedem stable/pike is capped at 4.25.1 https://github.com/openstack/requirements/blob/stable/pike/upper-constraints.txt#L433
16:23:41 mriedem so tripleo should be relying on u-c
16:23:52 lyarwood mriedem: nice thanks
16:24:08 edleafe ugh, heavy lightning around here - power drops have kicked me off the internet 3 times already.
16:25:30 dansmith mriedem: oh they're special alright
16:28:13 cdent mriedem, melwitt: all I'm able to update on the vmware sitiuation is that you've got their attention, so reasonable strategy
16:29:29 melwitt cdent: ack
16:29:45 openstackgerrit Merged openstack/nova stable/queens: Preserve multiattach flag when refreshing connection_info https://review.openstack.org/555029
16:30:53 mriedem dansmith: tssurya: melwitt: i assume we're having a cells meeting today?
16:30:59 mriedem there is at least one new bug i wanted to talk about
16:31:25 dansmith mriedem: I was going to ask if we needed to
16:31:28 dansmith sounds like we do
16:31:40 melwitt yeah, if we have topics, we can meet
16:32:12 mriedem unless we just want to skip and talk about the specific bug here
16:32:40 melwitt either way wfm
16:33:42 dansmith I'm good to skip if it's just one bug
16:33:45 dansmith I got nothing else
16:37:04 mriedem wait to see what tssurya says, she's the busy one
16:37:57 tssurya I am good to skip too
16:38:02 mriedem hot dog
16:38:19 mriedem ok so just wanted to talk about options for https://bugs.launchpad.net/nova/+bug/1759316
16:38:19 openstack Launchpad bug 1759316 in OpenStack Compute (nova) queens "pre-cells_v2 nova-osapi_compute service in database breaks instance lookup" [Medium,Confirmed]
16:38:39 dansmith okay
16:38:39 mriedem basically an upgrade issue for someone that was hard to figure out since there are no logs
16:38:48 mriedem upgrading newton->ocata
16:39:16 mriedem at this point, if you're not using cells v1 and you get here, https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/compute/api.py#L2269 - i think we should log a warning
16:39:25 mriedem ^ was added in newton
16:39:33 mriedem so if you're hitting that in ocata+ it likely means you're going to have issues
16:39:34 dansmith so, I thought we removed some of this recently
16:39:37 dansmith when I did the instance list bit
16:40:00 mriedem i've had some patches to try and remove some things from the cells v2 transition but they are in limbo,
16:40:21 mriedem there was also a thing i tried removing from the local delete flow and was hitting weird errors, but i forget the details
16:40:43 dansmith but on ocata we can't eliminate that check just yet
16:40:53 dansmith so yeah, you want to warn if we take that path and we're not on cellsv1 right?
16:40:57 mriedem i'm not saying remove it,
16:40:59 mriedem yes
16:41:02 mriedem warn and backport that warning
16:41:03 dansmith yeah I think that makes sense
16:41:04 melwitt yeah, warning makes sense
16:41:06 mriedem ok
16:41:14 mriedem they were also asking if nova-status could check for this,
16:41:20 mriedem which isn't unreasonable
16:41:28 dansmith if you will do the nova-status change I'll do the warning :D
16:41:33 mriedem ha
16:41:52 mriedem i'm ok with nova-status, but need input on how the check is going to work, see 2nd paragraph in https://bugs.launchpad.net/nova/+bug/1759316/comments/1
16:41:52 openstack Launchpad bug 1759316 in OpenStack Compute (nova) queens "pre-cells_v2 nova-osapi_compute service in database breaks instance lookup" [Medium,Confirmed]
16:42:53 openstackgerrit Ed Leafe proposed openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357
16:43:13 edleafe jaypipes-away: mriedem: ^^ Addressed the outstanding issues
16:43:17 dansmith you can just return "maybe a problem" with basically that text right? "I found an old entry in cell foo and it might be a problem or might not, but fyi"
16:43:37 mriedem dansmith: yeah that's what i was thinking, we have ok, warning and error for nova-status
16:43:39 mriedem so this would be a warning
16:43:43 mriedem since we aren't sure how you've configured the api
16:43:46 dansmith righ

Earlier   Later