Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-11
22:43:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Confirm cross-cell resize from the API https://review.openstack.org/637316
22:43:25 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add revert_snapshot_based_resize_at_dest compute method https://review.openstack.org/637630
22:43:26 openstackgerrit Matt Riedemann proposed openstack/nova master: Deal with cross-cell resize in _remove_deleted_instances_allocations https://review.openstack.org/639453
22:43:26 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add finish_revert_snapshot_based_resize_at_source compute method https://review.openstack.org/637647
22:43:27 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add RevertResizeTask https://review.openstack.org/638046
22:43:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Add revert_snapshot_based_resize conductor RPC method https://review.openstack.org/638047
23:33:21 openstackgerrit Merged openstack/nova master: Handle templated cell mappings in nova-status https://review.openstack.org/641021
23:53:21 openstackgerrit Takashi NATSUME proposed openstack/nova master: Update compute rpc version alias for stein https://review.openstack.org/642599
#openstack-nova - 2019-03-12
00:12:33 openstackgerrit Merged openstack/nova master: Remove fake_libvirt_utils from the cache concurrency tests. https://review.openstack.org/642556
00:28:51 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: qemu: Make disk image conversion dramatically faster https://review.openstack.org/640781
00:28:51 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode for Nova instances https://review.openstack.org/641981
00:44:06 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: WIP: Gracefully handle QEMU machine types for guests https://review.openstack.org/631154
01:03:59 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Handle templated cell mappings in nova-status https://review.openstack.org/642611
05:57:15 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Add description for BDM volume_size https://review.openstack.org/641255
05:57:19 openstackgerrit Takashi NATSUME proposed openstack/nova master: api-ref: Add description for BDM volume_size https://review.openstack.org/641255
07:01:14 openstackgerrit Ying Wang proposed openstack/nova stable/rocky: Modified the filter regulation of 'Instance Name' for filter instance https://review.openstack.org/642659
07:37:57 openstackgerrit Boxiang Zhu proposed openstack/nova master: Remove the unsafe convert of lvm imagebackend https://review.openstack.org/642667
07:54:57 openstackgerrit Ying Wang proposed openstack/nova master: It was modified to the exact filter regulation of 'Instance Name' for filter instance https://review.openstack.org/642675
08:51:38 openstackgerrit Boxiang Zhu proposed openstack/nova master: Remove the unsafe convert of lvm imagebackend https://review.openstack.org/642667
09:59:32 openstackgerrit ya.wang proposed openstack/nova master: Update docs: User token times out during long-running operations https://review.openstack.org/642410
13:13:27 mriedem lyarwood: a few small things in https://review.openstack.org/#/c/551349/
13:26:33 mriedem gibi: heh found a use case for something we talked about recently https://review.openstack.org/#/c/387687/
13:27:01 mriedem compute node went down, admin unbinds a port to re-use it elsewhere, compute node comes back up and delete the old server and nova deletes the port
13:27:11 mriedem or unbinds it from the server it was currently bound to
13:31:52 gibi mriedem: hm, that sounds like a bug
13:32:23 gibi mriedem: nova should check if the port is bound to the same server as nova things to bound to before unbind
13:34:19 mriedem yeah there is an old bug for it
13:34:23 mriedem https://bugs.launchpad.net/nova/+bug/1634269
13:34:23 openstack Launchpad bug 1634269 in OpenStack Compute (nova) "Incorrect port unbind request on instance delete" [Low,In progress] - Assigned to AJAY KALAMBUR (akalambu)
13:34:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix incorrect port unbind request in nova on instance delete https://review.openstack.org/387687
13:37:36 gibi OK, so in the fix we simply refresh nova's view based on neutron's view and only unbind if the vif is still belongs to the instance
13:37:42 gibi that could work
13:38:32 gibi in a similar scenario with bandwidth when neutron admin forcefully unbind the port then the resource allocation view will become inaccurate
13:39:39 gibi then when the old nova instance is deleted the whole resource allocation is deleted in placement so the inventory become correct eventually
13:41:06 gibi hm, in the bug, the instance is deleted while the compute was still down. I'm not sure when the allocation for such instance is deleted from placement
13:43:46 gibi OK. compute.api._local_delete calls delete_allocation_for_instance() so if the admin unbinds the port _after_ the instance is local deleted then the resource view is in a correct state
13:46:42 gibi mriedem: So I don't see that this sceanrio leads to any issue with bandwidth resource
13:46:48 mriedem this bug predates placement by a long shot
13:46:53 mriedem i'm not saying it does,
13:47:04 mriedem we have just talked about the weird corner case of unbinding ports out of band
13:51:18 gibi mriedem: yeah, the use case seems valid
13:53:50 openstackgerrit Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646
13:56:13 mriedem melwitt: is this really stein rc potential? https://bugs.launchpad.net/nova/+bug/1816399 - isn't that a latent issue since rocky?
13:56:13 openstack Launchpad bug 1816399 in OpenStack Compute (nova) "The periodic task to clean up expired console_auth tokens is invalid" [Undecided,In progress] - Assigned to Takashi NATSUME (natsume-takashi)
16:10:08 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Re-propose cross-cell-resize spec for Train https://review.openstack.org/642807
16:12:15 dansmith mriedem: regarding this: https://review.openstack.org/#/c/567701, where is the az set on the reqspec during live migration?
16:14:41 mriedem the request spec az is set on server create and never changes
16:15:10 dansmith okay I'm missing something about your assertion in the commit message then
16:16:07 dansmith you say the reqspec.az is what the az filter looks at, and that means the instance can be moved across azs, which I assumed meant we update it so after you move it it's correct,
16:16:20 dansmith but if not, then if you force a move across azs, and then do something like a resize,
16:16:34 dansmith the instance will pop back over to the old az during scheduling, yeah? Is that what you meant?
16:19:33 mriedem replied inline
16:20:38 dansmith mriedem: okay I'm more talking about the case where az *is* set
16:20:56 dansmith agree that if it's not set, it shouldn't matter, that's the easy case
16:21:18 mriedem i wasn't considering the force case here,
16:21:25 mriedem that's a separate f'ed up issue that evacuate will also suffer from
16:21:53 mriedem but yeah, if you request server create in AZ1, admin forces live migrate or evacuate to AZ2, and then the user resizes, they'll wind up back in AZ1
16:21:56 mriedem b/c of the request spec
16:22:07 mriedem another example of why we removed the force parameter
16:22:13 mriedem but it's a separate bug imo
16:24:25 dansmith mriedem: I'm more interested in the v2.1 case, since that's all that osc seems to support right now, which by my reading is kinda equivalent to force=True with a destination right?
16:24:43 dansmith mriedem: I'm actually asking about this for another reason, not for confirmation of your patch itself
16:26:54 mriedem "which by my reading is kinda equivalent to force=True with a destination right" yup
16:27:10 mriedem also,
16:27:16 mriedem https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-migrate is totally borked in this regard,
16:27:24 dansmith yes
16:27:26 mriedem if you're using osc to do live migrations, you're *always* forcing by default
16:27:29 mriedem it's mega fucked
16:28:05 mriedem i've talked with dean about this and unfucking it means essentially a major version bump
16:28:10 mriedem b/c it has to be an interface change
16:28:46 mriedem what you're talking about with force not updating the request spec az is a latent bug yeah
16:29:41 mriedem https://review.openstack.org/#/c/627801/
16:30:20 mriedem maybe should queue that up for the ptg
16:33:48 mriedem mordred: i added an item to the nova train ptg etherpad about finally unbreaking the osc server migrate interface, since we should shit or get off that pot
16:34:05 mriedem ~L104 https://etherpad.openstack.org/p/nova-ptg-train
16:34:41 dansmith mriedem: on the --force removal, we just removed that flag and use the presence of the host parameter to indicate that we're serious?
16:34:59 dansmith because I thought the point was to be able to provide a host and let the scheduler sanity check it, and force was "this is an emergency just do it"
16:35:17 mriedem yeah - the provided host is a requested destination and the only one the scheduler will look at
16:35:44 dansmith so we've lost the emergency button?
16:35:57 mriedem if you're using the latest microversion yes,
16:36:07 mriedem but you can still 2.1 yourself into oblivion if you want
16:36:22 dansmith I vaguely recall these discussions of course, I'm just trying to fit my head around the current state
16:36:31 mriedem we also intentionally broke force for any servers that have nested allocations
16:36:48 mriedem regardless of microversion
16:37:07 dansmith if we start saying 2.1 is how you override things in an emergency then we really need to put the cap on "we're never bumping the minimum" :)
16:37:34 dansmith in the 2.1 case where you provide a host, we're still updating allocations though as far as I can see
16:37:39 dansmith you just mean nested allocs specifically?
16:37:40 mriedem we'll just do something dumb like adding the force parameter back
16:37:44 mriedem forcev2!
16:38:24 mriedem dansmith: yes if you force (2.1 where host is not None), we copy the allocations over to the forced dest compute node provider
16:38:29 mriedem but only if they are flat allocations
16:38:44 mordred mriedem: ok. happy to help fixing that
16:39:02 mriedem dansmith: that's this part https://github.com/openstack/nova/blob/e608568518ed91a0cbf08f779c5adb851762d80a/nova/conductor/tasks/live_migrate.py#L111
16:40:42 dansmith mriedem: ack eyah
16:42:17 mriedem so it sounds like you want me to change https://review.openstack.org/#/c/567701/ to at the very least save off the current instance.availabilty_zone before setting it based on the new dest host selection and then if we hit rollback to set it back to the saved off value?
16:42:27 mriedem which would only happen if i guess the rpc cast blew up?
16:43:15 mriedem dansmith: doing it on the compute when we change instance.host is a non-starter if you care about up-calls
16:44:22 dansmith mriedem: you can do it in the cell on the instance :)
16:44:46 dansmith as long as we pass the az into compute so it doesn't have to look it up, which is what I was saying was likely an rpc change
16:45:21 dansmith mriedem: I don't know what I want really.. what you're doing seems wrong, but what I did was equally wrong although slightly less concerning because of how those actions work

Earlier   Later