Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-11
15:33:19 tssurya mriedem: I was just getting to that actually
15:33:33 tssurya thinking if my marker should be in instance_mappings or instances
15:34:00 mriedem L39 https://etherpad.openstack.org/p/YVR18-cellsv2-migration-sync-with-operators
15:34:17 tssurya as I will be fetching deleted (or soft_deleted) instances and then updating only those instance_mappings to true
15:34:36 mriedem migrate_instances_add_request_spec puts the marker in the request_specs table
15:34:41 mriedem so again, i'd just follow that pattern :)
15:34:53 mriedem since i will assume people thought about all of this when migrate_instances_add_request_spec was written
15:35:27 tssurya mriedem: okay then! I will go for the same consistency and follow the migrate_instances_add_request_spec stuff
15:37:32 tssurya dansmith: are we having cells meeting today ? (I don't have anything new we haven't discussed and have the needed feedback for the spec to work on)
15:38:03 dansmith tssurya: I don't have anything either, mriedem, melwitt ?
15:43:13 sapd1 Hi everyone, How can I remove an object from BlockDeviceMappingList object.
15:45:31 mriedem dansmith: nothing pressing, just starting reviews on tssurya's changes and need reviews on this bug fix which is related to cells v2 (build requests and quota counting): https://review.openstack.org/#/q/topic:bug/1780373+(status:open+OR+status:merged)
15:46:09 dansmith ack\
15:46:38 mriedem sapd1: can you provide more context?
15:47:05 openstackgerrit do3meli proposed openstack/nova master: docs: add nova host-evacuate command to evacuate documentation https://review.openstack.org/578040
15:48:21 sapd1 mriedem: I would like to customize bdms list. In this function: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2752
15:50:41 mriedem sapd1: because you're trying to rebuild a volume-backed instance?
15:51:23 mriedem sapd1: if so, you should read this spec first https://review.openstack.org/#/c/532407/
15:52:47 sapd1 mriedem: I'm trying, I don't find any change which can work, So I'm trying to make it run.
15:54:15 mriedem well read the spec and discussion in there
15:54:28 mriedem or if you're going to fork it anyway, you could look at https://review.openstack.org/#/c/528740/ but i wouldn't use that method
15:55:26 mriedem there are in fact several attempts at this in https://bugs.launchpad.net/nova/+bug/1378689
15:55:27 openstack Launchpad bug 1378689 in OpenStack Compute (nova) "error when rebuilding a instance booted from volume" [Undecided,In progress] - Assigned to Jie Li (ramboman)
16:02:32 sapd1 mriedem: This feature is sound like have too many bugs :D
16:04:16 mriedem well, that's what happens when we add features without thinking about implications to existing APIs
16:04:43 mriedem i'd like to see https://review.openstack.org/#/c/532407/ get agreement on a direction in stein so we can finally fix this
16:05:36 sapd1 mriedem: Yep, Because attach/detach flow in cinder has changed. So the rebuild process will be failed.
16:05:54 mriedem i'm not sure i follow
16:06:10 mriedem are you talking about the volume attachments API in cinder?
16:06:35 sapd1 mriedem: Could you tell me how to remove an item in BlockDeviceMappingList in the function?
16:06:53 mriedem that doesn't really have anything to do with the fact nova has never supported rebuilding a volume-backed server with a new image
16:07:17 sapd1 mriedem: Yep. Because multi-attach was introduced. So attach/detach flow have to change.
16:07:35 mriedem sapd1: those are backward compatible changes and nova opts into using those apis
16:07:41 mriedem so it doesn't really mean anything for what you're trying to do
16:08:07 sapd1 I want to remove old root disk block device mapping in that list.
16:08:20 mriedem we added a change to the api in queens such that you literally cannot rebuild a volume-backed server with a new image
16:08:23 mriedem the user gets an error
16:09:33 mriedem https://review.openstack.org/#/c/520660/
16:10:58 sapd1 :D
16:10:58 sapd1 Use this patch I can bypass https://review.openstack.org/#/c/528740/8/nova/compute/api.py
16:11:30 mriedem if you want to fork a hack into your product that's up to you
16:11:36 mriedem but i'm not going to spend time helping you do it, sorry
16:11:54 mriedem i'm only interested in https://review.openstack.org/#/c/532407/
16:12:34 sapd1 mriedem: So Has anyone implemented this spec yet?
16:13:08 mriedem sapd1: no, see my -1 on the spec
16:13:14 mriedem need to agree on the design first
16:13:24 mriedem which is why the 20 other hack fixes for this problem have been rejected in the past
16:14:44 sapd1 mriedem: I'm trying :D thanks
16:15:10 mriedem my comment from march 27 is where i think it stalled
16:15:12 mriedem lume_image_metadata" information would need to be updated.We really don't want to do the volume create/delete/swap orchestration thing since that entails issues with the volume type being gone, going over quota, what to do about deleting the old volume, etc.So please propose a spec to Cinder and start working the API changes there and then nova can depend on a new Cinder API."
16:15:12 mriedem "The cleanest / best solution to this is to add a volume action API to cinder for re-imaging the volume. Once that is available in a new cinder v3 microversion, nova can use it. The reason I think this should be done in Cinder with re-imaging the volume there is (1) it's cleaner from the nova side and (2) then Cinder is in control of how that re-image should happen, along with any details it needs to update, e.g. the volume's
16:15:59 mriedem i think of this like shelve offloading and unshelving a volume-backed server but with a new image
16:16:10 mriedem and i'd like cinder to control the api for re-imaging the volume
16:16:19 mriedem because cinder owns the volume
16:17:09 mriedem maybe i need to work with tommylikehu on this in stein
16:18:50 mriedem melwitt: it might not be too early to start a stein ptg etherpad for random items
16:24:06 sapd1 mriedem: Yep. I think It can work. with this patch.
16:24:12 sapd1 mriedem: http://paste.ubuntu.com/p/V3MhY7Hp3X/
16:25:14 sapd1 I change flow to detach old root disk device and create attachment ID for new rootdisk device
16:27:37 openstackgerrit Merged openstack/nova master: Test for unsanitized consumer UUID https://review.openstack.org/581137
16:30:09 gibi mriedem: left comments in the complex-anti-affinity-policies series but I haven't finished yet. I run out of time. I can check the API patch tomorrow if needed
16:33:44 openstackgerrit Matt Rabe proposed openstack/nova master: Add destination MSP IP address to PowerVM migrate data https://review.openstack.org/579676
17:25:09 melwitt mriedem: yeah, probably a good idea to start one. I've seen others posted to the ML already, at least for cinder
17:45:02 melwitt dansmith: I don't have anything for a cells meeting
17:45:12 dansmith ack
17:50:03 melwitt mriedem: comment on https://review.openstack.org/580755 , I've wondered why we don't use the CastAsCall fixture anymore in functional tests where we want to GET servers after we create them. everything else looks good in the tests
17:56:40 mriedem melwitt: because CastAsCall isn't what you'd really get as a real user
17:56:49 mriedem so unless there is a good reason to use, it don't know why we would
17:58:47 mriedem melwitt: replied inline
17:58:49 melwitt mriedem: I was thinking because of the assumption of the servers before they're active, but in this case "active" is not needed or relevant in the test
17:59:27 mriedem right we don't care about status in these tests
17:59:34 melwitt I was thinking POST followed by GET without waiting for the status, but if you don't care about the status, then it doesn't matter. maybe that's the difference. none of the assertions you're doing depend on the boot process being further along
18:00:19 melwitt a few weeks ago I was working on a test that kept failing until I used CastAsCall, but it must have been that an assertion I had depended on the boot process getting to a certain point. sorry for the noise
18:01:14 mriedem we have utilities for waiting for the server to be a certain status as well
18:01:22 mriedem so if i needed to wait, i'd use that instead of CastAsCall
18:01:50 melwitt true, I'll keep that in mind for next time
18:20:55 openstackgerrit Merged openstack/nova master: [placement] add error.code on a ConcurrentUpdateDetected https://review.openstack.org/581742
18:34:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-status upgrade check for request spec migrations https://review.openstack.org/581813
18:41:57 melwitt mriedem: ptg etherpad if you had some topic(s) you wanted to jot down https://etherpad.openstack.org/p/nova-ptg-stein
18:42:52 mriedem thanks
19:06:03 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Add functional regressions tests for server_group_members OverQuota https://review.openstack.org/581845
19:06:04 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix server_group_members quota check https://review.openstack.org/581846
19:17:42 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add functional regressions tests for server_group_members OverQuota https://review.openstack.org/581866
19:17:43 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix server_group_members quota check https://review.openstack.org/581867
19:25:22 mriedem crazy croats
19:54:47 mriedem dansmith: comments on your bfv req spec change https://review.openstack.org/#/c/580720/
20:02:05 dansmith ooh
20:10:03 mriedem so this isn't backportable b/c of the version change, but in thinking about this more - persisting the is_bfv flag is good b/c for any new instances created after this, moving them also benefits from the flag being set
20:10:13 mriedem the only gap is existing instances that don't have is_bfv set in the request spec, as noted in the commit message
20:10:18 mriedem which we can easily detect and heal during a move
20:11:19 mriedem there are a few comments in the bug report about how once people got to ocata the allocations for volume-backed instances were fixed, and that's because the resource tracker had the is_bfv logic to not account for flavor.root_gb,
20:11:45 mriedem but then in pike we stopped creating allocations in the RT and based the allocations of the request spec, so we regressed that....
20:12:03 mriedem so this (re)fixes that
20:12:13 mriedem but we'd have a gap in pike and queens
20:12:54 dansmith sorry, was looking at the review window
20:12:56 dansmith I just replied,
20:13:14 dansmith but basically I didn't even consider this as backportable since it changes what we allocate and stuff and thought it wasn't worth the risk
20:13:15 mriedem almost seems like we could do a hybrid of https://review.openstack.org/#/c/428481/ and your new patch which could be backportable
20:13:31 dansmith I'd rather just roll forward and heal
20:14:05 mriedem i get that,

Earlier   Later