Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-16
17:23:36 cfriesen mriedem: so we want to disallow rebuild even to the same image? (I think it can fix some problems, like rebuilding cinder volume connections)
17:24:20 mriedem cfriesen: look at the patch
17:24:27 mriedem instance.image_ref != image_href
17:24:58 cfriesen mriedem: okay, but then we'll update the image ref in the instance to point to the new image (instead of having nothing like it did at boot)
17:25:19 mriedem cfriesen: huh?
17:25:31 mriedem we don't save the instance.image_ref until later, after we've already failed here
17:26:07 cfriesen mriedem: in the case of a rebuild-to-same image, before the rebuild the instance image ref is empty, after the rebuild it points to that image
17:26:41 mriedem why is the instance.image_ref empty?
17:27:19 cfriesen mriedem: dunno, it's always been that way. novaclient keys off an empty image ref to say "Attempt to boot from volume - no image supplied"
17:28:05 mriedem if the instance.image_ref is empty because it's a boot from volume, then "and compute_utils.is_volume_backed_instance" is True and we raise an exception so you can't rebuild, correct?
17:28:11 mriedem which means we don't get to the code that calls instance.save()
17:29:09 cfriesen mriedem: yeah, it actually means your proposed patch will result disallowing all rebuilds of boot-from-volume.
17:29:23 cfriesen mriedem: I think we need to look at the image specified in the volume metadata
17:29:50 mriedem oh i see what you're saying
17:30:15 mriedem cfriesen: ok comment and -1 the patch
17:30:24 mriedem i'm dealing with novaclient atm
17:30:59 cfriesen mriedem: one other related thing is that there's no easy way to tell using the HTTP API if an instance is boot-from-volume other than that image field.
17:31:20 cfriesen mriedem: no worries, will poke at it. we've got a customer issue around this
17:31:49 mriedem you mean there isn't an easy way for the user to discover if they have a boot from volume instance and shouldn't attempt a rebuild with a different image to avoid the 400?
17:32:02 openstackgerrit Merged openstack/nova stable/newton: Validate new image via scheduler during rebuild https://review.openstack.org/519684
17:32:36 cfriesen mriedem: we have some orchestration code that does stuff differently for boot-from-volume (not just for rebuild, but that's one case)
17:32:45 mriedem we == nova?
17:32:50 mriedem or we == windriver?
17:32:55 cfriesen mriedem: no, windriver.
17:33:21 cfriesen but I suspect others have similar issues. if you don't know how something was booted, it's hard to tell just by looking at instance details if it's boot-from-volume or not
17:35:49 mriedem https://developer.openstack.org/api-ref/compute/#show-server-details
17:35:54 mriedem "The UUID and links for the image for your server instance. The image object might be an empty string when you boot the server from a volume."
17:36:11 cfriesen mriedem: "might" is not definitive
17:36:18 mriedem well,
17:36:24 mriedem if we know that it's always the case, we can change the docs
17:36:33 mriedem but that would require some investigation
17:36:55 mriedem "The image object is totes empty when you BFV bra!"
17:36:58 mriedem let's change to that
17:37:11 mriedem our docs are boring
17:37:19 mriedem are you totes down?
17:37:21 mriedem bra?
17:37:40 cfriesen I think there's a bra around here somewhere...
17:38:05 mriedem bzzt, wrong
17:38:11 mriedem incorrect usage of the term
17:38:18 mriedem you are now in PC jail, welcome
17:38:31 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient._get_resource_provider_tree https://review.openstack.org/520663
17:39:15 efried jaypipes ^ -- and the next one will do a public method that uses that result to populate ProviderTree.
17:39:31 jaypipes efried: sounds good.
17:47:56 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Remove SecretsHelper https://review.openstack.org/520666
17:47:57 mriedem andreykurilin: ^
17:50:55 mriedem cfriesen: i'm not actually sure how we get the volume image_id info
17:51:05 mriedem not seeing that in the volume response body
17:53:33 openstackgerrit Merged openstack/nova stable/newton: Add security release note for OSSA-2017-005 https://review.openstack.org/519755
18:09:30 cfriesen mriedem: I think it's in the volume metadata...but let me check
18:10:13 cfriesen mriedem: also, is_volume_backed_instance() has a comment about a "very old instance without root bdm"...do we need to worry about that case? if so, how would we find the root volume?
18:10:37 mriedem i doubt we need to worry about that, it's probably referring to bdmv1 stuff
18:14:43 cfriesen in cinder v2 api it was under volume_image_metadata, as "image_id"
18:40:36 efried jaypipes See https://review.openstack.org/#/c/520246/1/nova/compute/resource_tracker.py@825 for why I think I need that iterator.
18:41:53 efried jaypipes Sorry, that guy kinda fell off the series because I'm stuffing the guts in the middle. But that's where I started; now building up the intervening pieces.
18:42:40 jaypipes efried: k, lemme review that then
18:44:27 efried jaypipes Agree about thread safety, though. It doesn't need to be an iterator; I could just build it as a list under lock and return that. We shouldn't be talking about a huge number of providers in one of these things.
18:45:18 jaypipes efried: ya. my point was that it should be a method on ProviderTree. But actually, I'm still not convinced it's necessary (yet). Still reviewing this...
18:53:20 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM - test updated releasenotes job https://review.openstack.org/520677
18:55:23 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Remove the py27 tox target https://review.openstack.org/520680
18:56:08 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Remove the py27 tox target https://review.openstack.org/520680
18:57:34 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Set the 'Upgrade impact' subsection as optional https://review.openstack.org/517223
19:03:31 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Remove the py27 tox target https://review.openstack.org/520680
19:04:54 openstackgerrit Merged openstack/python-novaclient master: Stop posting to os-volumes_boot https://review.openstack.org/473833
19:07:16 jaypipes efried: k, see review on that one with a proposed alternative.
19:07:24 efried jaypipes Ack.
19:07:45 jaypipes efried: I see where you're going. just have some thoughts on a way to hide some of that complexity behind the ProviderTree and reportclient interfaces.
19:08:29 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Fix the formatting for the 2.54 microversion REST API version history https://review.openstack.org/519940
19:09:21 mriedem thanks oomichi_afk
19:10:53 efried jaypipes I understand, and am on board. BUT 1) I still need to _normalize_inventory_from_cn_obj for each provider in the tree; and 2) the virt driver is going to have to have some way to walk the tree it's given.
19:14:44 jaypipes efried: agreed on the first point, for sure. on the second, I'll have to think more about that.
19:15:00 efried k
19:23:08 efried jaypipes Just throwing this out there: What if we didn't pass virt the provider tree at all - it's responsible for building one from scratch and sending it back to us. Then we get to go figure out whether anything has changed and flush changes accordingly.
19:24:03 efried jaypipes That would be easier for virt to handle than having to go around figuring out where it needs to add stuff, whether it needs to prune stuff, etc.
19:28:58 efried jaypipes And it's the same paradigm we've had up to now with get_available_resource and get_inventory.
19:35:16 jaypipes efried: the virt driver likely will not be iterating over the provider tree in that way. instead, the virt driver will be querying for things like PCI devices and NUMA nodes etc and will simply be doing a ProviderTree.find() for that device name or NUMA node. it will then add it if the tree doesn't have it or change its traits/inventory if the find() returns a node.
19:37:50 efried jaypipes Giving virt a whole ProviderTree gives them the ability to muck with roots too. Is that a good thing?
19:38:11 efried I guess that's how they would operate on sharing providers.
19:46:33 openstackgerrit Andreas Jaeger proposed openstack/python-novaclient master: Remove setting of version/release from releasenotes https://review.openstack.org/520733
19:56:42 mriedem edleafe: ok comments in https://review.openstack.org/#/c/495854/ - mostly small,
19:57:11 mriedem edleafe: we might want to discuss the thing here https://review.openstack.org/#/c/495854/31/nova/scheduler/filter_scheduler.py@389
19:57:33 mriedem about the scheduler assuming/defining behavior for conductor based on whether or not the first Selection in the list has allocation_request in it
20:06:15 jaypipes efried: not entirely sure, but I'm sure once we get to those patches, things will start to shake out.
20:07:59 mriedem edleafe: ah i see you are relying on that in conductor https://review.openstack.org/#/c/511358/24/nova/conductor/manager.py@582
20:14:38 openstackgerrit Eric Fried proposed openstack/nova master: WIP: ProviderTree.from_list and SRC.get_provider_tree https://review.openstack.org/520756
20:14:51 efried jaypipes You probably want to ignore this one ^
20:15:37 efried although... I suppose the principle may be used for the method you suggested; just moving a bunch of the code from ProviderTree into report client.
20:21:07 mriedem jaypipes: jgriffith and i were musing about the need to include the 'deleted' column in an index,
20:21:12 mriedem and i think i asked you about this a few weeks ago,
20:21:23 mriedem and i thought you said it wouldn't make a noticeable difference, but i could be mistaken,
20:21:33 mriedem but deleted can be 0 or any positive int for a deleted record
20:26:44 openstackgerrit Merged openstack/python-novaclient master: Remove SecretsHelper https://review.openstack.org/520666
20:32:18 efried jaypipes It's been bugging me that the working title for the new virt driver method is `update_inventory`. Shouldn't it be `update_provider_tree`? Since ProviderTree is what we're passing in, and they're updating more than just the inventory therein?
20:39:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix TypeError in nova-manage db archive_deleted_rows https://review.openstack.org/520765
20:57:29 efried jaypipes How do you feel about this: If my virt driver is using update_provider_tree, I'm advanced enough to set my own allocation ratios and reserved amounts and whatnot - which I can do from the compute conf if I feel like it - so in that scenario we should NOT call _normalize_inventory_from_cn_obj at all.
21:00:50 openstackgerrit Andreas Jaeger proposed openstack/os-vif master: Remove setting of version/release from releasenotes https://review.openstack.org/520788
21:08:16 openstackgerrit Merged openstack/nova-specs master: Fix "Line limited to a maximum of 79 characters" https://review.openstack.org/520281
21:08:17 openstackgerrit Merged openstack/nova-specs master: Set the 'Upgrade impact' subsection as optional https://review.openstack.org/517223
21:21:54 openstackgerrit Michael Still proposed openstack/nova master: Convert ext filesystem resizes to privsep. https://review.openstack.org/517516
21:21:54 openstackgerrit Michael Still proposed openstack/nova master: Move flushing block devices to privsep. https://review.openstack.org/519010
21:21:55 openstackgerrit Michael Still proposed openstack/nova master: Start moving users of parted to privsep. https://review.openstack.org/519011

Earlier   Later