Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-16
16:57:58 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
16:57:58 openstackgerrit Ed Leafe proposed openstack/nova master: Refactor the code to check for sufficient hosts https://review.openstack.org/520242
16:57:58 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
16:57:59 openstackgerrit Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159
16:58:00 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
16:58:00 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
16:58:00 openstackgerrit Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
17:02:02 mriedem andreykurilin: fixed!
17:02:50 mriedem well, i'm prompted for a password now, but apparently it's not used
17:06:16 openstackgerrit Surya Seetharaman proposed openstack/nova master: instance_mapping/request_spec records exist even after the instances are archived https://review.openstack.org/515034
17:06:31 mriedem andreykurilin: so given this has been broken since liberty and no one noticed or cared, i'm thinking we could just remove it
17:06:37 mriedem there is no point in even deprecating it
17:07:50 cfriesen mriedem: for https://bugs.launchpad.net/nova/+bug/1482040 would it maybe make sense to disallow rebuild of boot-from-volume instance to a different image (but allow it for the same image)?
17:07:50 openstack Launchpad bug 1482040 in OpenStack Compute (nova) "rebuild volume-backed instance with image does not replace image in root disk" [Undecided,Confirmed]
17:08:20 mriedem https://bugs.launchpad.net/python-novaclient/+bug/1732744
17:08:20 openstack Launchpad bug 1732744 in python-novaclient "SecretsHelper has not worked since 2015" [Undecided,Triaged] - Assigned to Matt Riedemann (mriedem)
17:08:33 cfriesen mriedem: or should we completely disallow it for boot-from-volume since the image isn't replaced (but other stuff is, so it's still somewhat useful)
17:08:45 mriedem cfriesen: i think you ask me this at least once per week
17:08:54 cfriesen mriedem: last time you said to disallow it
17:09:08 cfriesen mriedem: but I'm wondering about the case where the image matches what was on the volume
17:10:40 mriedem sec
17:20:42 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Fail fast if changing image on a volume-backed server rebuild https://review.openstack.org/520660
17:20:43 mriedem cfriesen: there you go ^ needs tests
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.

Earlier   Later