Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-28
17:52:22 openstackgerrit Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159
17:52:22 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
17:52:23 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
17:52:23 openstackgerrit Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
17:52:23 melwitt mriedem: ack, will look
17:52:24 openstackgerrit Ed Leafe proposed openstack/nova master: Move the to_dict() method to the Selection object https://review.openstack.org/523492
17:52:49 mriedem melwitt: it'd also be good if you could help review ed's alternate hosts series above
17:52:53 mriedem since that's related to cells v2 stuff
17:53:01 melwitt sure thing
17:53:04 mriedem thanks
18:06:40 openstackgerrit Ed Leafe proposed openstack/nova master: Move the to_dict() method to the Selection object https://review.openstack.org/523492
18:06:41 openstackgerrit Ed Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts https://review.openstack.org/510159
18:06:41 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
18:06:42 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
18:06:42 openstackgerrit Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358
18:13:36 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured https://review.openstack.org/521947
18:14:14 openstackgerrit Eric Fried proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured https://review.openstack.org/521947
18:14:23 efried ah, seriously?
18:14:35 efried mriedem ^
18:16:05 mriedem we are sympatico
18:16:36 efried mriedem Want me to unwind mine?
18:16:42 mriedem sure
18:16:44 jaypipes efried: FYI, still running tests on the n-r-p series after rebasing. (had to run tests for all 12 patches separately of course...)
18:16:55 efried jaypipes Of course.
18:20:33 efried mriedem Is there an easy way to revert to a prior patch set?
18:20:56 jaypipes efried: rm -rf /
18:21:12 jaypipes :P
18:21:57 mriedem efried: not sure of an easy way
18:22:00 clarkb efried: git review -d 123456,2 && git commit --amend # make some change to the commit message because gerrit (though new gerrit may not have this restriction any longer) && git review
18:22:15 efried clarkb Cool, thanks.
18:22:29 openstackgerrit Eric Fried proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured https://review.openstack.org/521947
18:22:42 clarkb gerrit in the past has refused to accept old identical patchsets, I think ti may not refuse those anymore so you don't need to make changes but I haven't tested it
18:22:51 melwitt cool, I learned a thing. I wondered if there was a way to pull a specific rev using git review -d
18:22:54 efried clarkb No, it did refuse.
18:23:06 efried Trivial change to the commit message worked. Thanks for that.
18:23:26 efried mriedem done, sorry about that.
18:27:25 mriedem np
18:30:50 melwitt mriedem: if we have a change that introduces a new config option but it's not useful until patch 3 in the series, is it okay to delay the reno until patch 3? example: https://review.openstack.org/#/c/345397/26/nova/conf/vnc.py
18:34:04 melwitt I'm thinking that makes sense (to reno the conf option when the feature represented in the series fully lands)
18:46:57 melwitt would anyone be willing to review this libvirt driver bug fix to save the guest XML after a volume update? has one +2 https://review.openstack.org/#/c/498983
18:47:42 zigo melwitt: Hi ! I believe I know how to write the fix for my O_DIRECT issue! :)
18:48:03 zigo melwitt: There's even a facility in nova to actually test for O_DIRECT support, but it's simply not used ... :P
18:49:03 melwitt zigo: I've seen the test for O_DIRECT support in the driver but wasn't sure how to apply it in the fail case you hit. if you could propose a patch, that would be sweet
18:49:05 zigo Please let me write it, that'd be my first patch in Nova, and that will make me very proud !!! :)
18:49:34 melwitt zigo: yup, have at it. ping me whenever you post it and I'll review it
18:49:44 zigo Cheers.
18:56:57 openstackgerrit Merged openstack/nova master: Implement query param schema for sec group APIs https://review.openstack.org/521353
18:57:11 openstackgerrit Merged openstack/nova master: Add instance action record for lock/unlock instances https://review.openstack.org/523353
18:57:33 openstackgerrit Merged openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
18:57:41 mriedem melwitt: if the config option isn't used until later in the series, why isn't it just introduced later in the series, when it's used?
18:59:50 melwitt mriedem: I think it's because in the series, patch 1 adds a base class (that uses the config option to iterate through choices), patch 2 adds one auth implementation, patch 3 adds another (and the final) auth implementation, each of which is one of the config option choices
19:00:41 zigo melwitt: How can I import nova.virt.libvirt.driver.LibvirtDriver.disk_cachemode() ? It's not ok to just import it as it's a driver, right?
19:00:56 mriedem sdague: you might have input here https://bugs.launchpad.net/nova/+bug/1734698
19:00:56 openstack Launchpad bug 1734698 in OpenStack Compute (nova) "Squash database patches" [Undecided,Invalid]
19:01:33 melwitt mriedem: er, sorry, patch 2 adds an impl, patch 3 does something else. let me look deeper into this first
19:01:38 openstackgerrit Merged openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
19:01:45 openstackgerrit Merged openstack/nova master: [placement] Fix GET PUT /allocations nits https://review.openstack.org/523401
19:03:17 melwitt zigo: where do you want to import it? just thinking ahead on whether it might need to be moved to utils to do what you want to do
19:05:00 melwitt because we don't want to import any driver stuff into imagebackend or images
19:05:04 efried jaypipes Here's a scenario: One or more sharing RPs (MISC_SHARES_VIA_AGGREGATE) in an aggregate. But that aggregate does *not* contain any non-sharing RPs. Would it be correct to say that we should *never* get allocation candidates including any RP in that aggregate?
19:08:20 zigo melwitt: In nova/virt/images.py there's def _convert_image(source, dest, in_format, out_format, run_as_root):. There, there is cmd = ('qemu-img', 'convert', '-t', 'none', '-O', out_format).
19:08:34 zigo 'none' needs to be replaced by a call to that function.
19:09:08 openstackgerrit Merged openstack/nova master: [placement] Clean up TODOs in allocations.yaml gabbit https://review.openstack.org/513057
19:09:17 openstackgerrit Merged openstack/nova master: Update the documentation links https://review.openstack.org/523288
19:10:19 jaypipes efried: wouldn't it depend on the request? I mean, if the request is only for resources that are being shared by those providers, then why wouldn't those providers be returned in allocation candidates? (note: the scheduler would throw those providers away since they wouldn't match a compute node UUID, but that's not the point, right?)
19:11:03 efried jaypipes That's indeed not the point. Hum, I guess it's legit...
19:12:37 melwitt zigo: ah, gotcha. hmm ... yeah, so virt/images.py is not *supposed* to be libvirt-specific but it obviously is. and as you can tell from the layout, we've got separation between the driver and image related code. so we wouldn't want to import from the libvirt driver there. so I'm thinking what's the least ugly way we could do this ...
19:12:45 efried jaypipes Is _get_all_with_shared supposed to return only non-sharing RPs?
19:13:09 jaypipes efried: it was supposed to, yeah. but alex_xu (and you, right?) pointed out that wasn't actually the case.
19:13:33 jaypipes efried: and upon further thought, decided to leave it as it was, returning both sharing and non-sharing.
19:13:55 jaypipes efried: and leave it up to callers to choose to ignore sharing-only allocation requests.
19:15:24 efried jaypipes Hell, I don't know anymore.
19:15:57 mriedem dansmith: this is a fun bug https://bugs.launchpad.net/nova/+bug/1734504
19:15:57 openstack Launchpad bug 1734504 in OpenStack Compute (nova) "User can't know which flavor used for resize by the result of "nova migration-list"" [Low,Triaged]
19:16:07 dansmith hmm, doesn't look fun
19:16:07 mriedem apparently we leak internal flavor primary keys out of the os-migrations REST API
19:16:26 mriedem which, whatever, we leak them out, big whoop, but they have no meaning at all to an end user since they aren't the flavorid
19:16:42 mriedem good times
19:17:03 mriedem and the columns on the migrations table that stores those ids is an integer column so we can't store string flavorid in there anyway :)
19:17:11 efried jaypipes Is there any meaning to MISC_SHARES_VIA_AGGREGATE if that's the case?
19:17:32 efried jaypipes What semantic does it provide beyond just being associated with a given aggregate?
19:18:36 jaypipes efried: it says "I share my inventory with any provider in any aggregate I'm associated with"
19:18:59 mriedem as far as i can tell, there is no reason that we even store the flavor.id on the migration record *except* to return it out of the API
19:19:03 mriedem nothing else in the code depends on it
19:19:22 dansmith "no reason to store it other than to return the wrong thing out of the API" <-- FTFY
19:19:29 mriedem yes correct
19:19:33 dansmith \o/
19:20:17 melwitt zigo: okay, after looking through the code, what I'll guess is a decent way to try first is, move the static _supports_direct_io function into nova/utils.py and make it public, then call that in both the libvirt driver and virt/images.py to find out how to set cachemode
19:20:45 efried jaypipes Are we allowed to have more than one non-MISC_SHARES_VIA_AGGREGATE in a given aggregate? I mean, nothing stops us from doing that; but what does it mean?
19:20:46 melwitt because AFAICT, the test for direct io support is just a linux thing, not specific to libvirt
19:22:32 jaypipes efried: aggregates don't have traits. only providers have traits.
19:22:42 jaypipes efried: aggregates are simply groups of providers, nothing more.
19:23:10 efried jaypipes I understand that. Rephrase: Are we allowed to have more than one RP without the MISC_SHARES_VIA_AGGREGATE trait in a given aggregate? I mean, nothing stops us from doing that; but what does it mean?
19:23:13 jaypipes efried: are you asking whether it's allowed to have >1 provider sharing the same resource class to other providers in its aggregates?
19:23:20 efried no
19:23:43 efried jaypipes In today's terms: Am I allowed to have more than one "compute node" in the same aggregate?
19:23:46 jaypipes efried: *most* providers in an aggregate will *not* have the MISC_SHARES_VIA_AGGREGATE trait.
19:24:01 jaypipes efried: for instance, compute node providers won't (typically) have that trait.
19:24:10 mriedem how bad would an alter table be on the migrations table to change old/new_instance_type from an integer to a varchar(64)?
19:24:18 jaypipes efried: yes, it's totally expected to have >1 compute node in an aggregate

Earlier   Later