Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-23
07:26:06 lyarwood namnh: I don't no sorry
07:36:57 openstackgerrit Merged openstack/nova stable/ocata: Account for compute.metrics.update in legacy notification whitelist https://review.openstack.org/509440
07:37:04 openstackgerrit Merged openstack/nova stable/pike: Add _wait_for_action_fail_completion to InstanceHelperMixin https://review.openstack.org/509922
07:37:08 openstackgerrit Merged openstack/nova stable/pike: Add recreate test for live migrate rollback not cleaning up dest allocs https://review.openstack.org/509923
08:03:57 openstackgerrit Michael Still proposed openstack/nova master: Move nbd commands to privsep. https://review.openstack.org/500351
08:03:58 openstackgerrit Michael Still proposed openstack/nova master: Move blkid calls to privsep. https://review.openstack.org/500398
08:03:58 openstackgerrit Michael Still proposed openstack/nova master: Move kpartx calls to privsep. https://review.openstack.org/500354
08:31:48 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526
08:53:14 openstackgerrit sahid proposed openstack/nova master: libvirt: rework _get_vpcu_total to return online pCPUs https://review.openstack.org/509730
08:53:15 openstackgerrit sahid proposed openstack/nova master: libvirt: set emulator threads on isolated host cpus https://review.openstack.org/510897
09:01:29 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Change Subnet.dhcp_server to contain multiple IPs https://review.openstack.org/509107
09:17:38 ygl hi all
09:18:43 ygl can some one point me to the exact code the libvirt uses to launch a vm on kvm hypervisor in nova ?
09:24:48 ygl can some one point me to the exact code the libvirt uses to launch a vm on kvm hypervisor in nova ?
09:25:00 ygl does it use qemu-kvm binary or virt-install ?
09:29:52 openstackgerrit sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457
09:33:03 stephenfin bauzas: How much do you know about gate jobs?
09:49:24 openstackgerrit Alex Xu proposed openstack/nova master: Add _get_provider_ids_with_any_trait method https://review.openstack.org/511184
09:49:25 openstackgerrit Alex Xu proposed openstack/nova master: Add get_resource_provider_with_any_resource method https://review.openstack.org/514197
09:49:25 openstackgerrit Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766
09:49:26 openstackgerrit Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary https://review.openstack.org/514199
09:49:26 openstackgerrit Alex Xu proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198
09:49:27 openstackgerrit Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200
09:52:15 openstackgerrit zhangyanxian proposed openstack/nova-specs master: Sriov-bond https://review.openstack.org/463526
10:02:22 bauzas stephenfin: hi, sorry about the delay
10:02:31 bauzas stephenfin: I have a plumber at home
10:02:38 bauzas (not mario FTW)
10:02:45 bauzas how can I help you ?
10:06:37 sahid ygl: we use qemu-kvm, but that through libvirt
10:07:34 ygl sahid: thanks very much
10:17:59 stephenfin bauzas: I _think_ I might be OK for now but stay away from the mushrooms til I know for sure ;)
10:50:45 openstackgerrit Merged openstack/nova stable/pike: Add live.migration.force.complete to the legacy notification whitelist https://review.openstack.org/508877
10:50:49 openstackgerrit Merged openstack/nova stable/ocata: Make conductor create InstanceAction in the proper cell https://review.openstack.org/511307
10:50:54 openstackgerrit Merged openstack/nova stable/ocata: Target context for build notification in conductor https://review.openstack.org/511325
10:51:05 openstackgerrit Merged openstack/nova master: propagate OSError to MigrationPreCheckError https://review.openstack.org/469779
10:51:11 openstackgerrit Merged openstack/nova stable/ocata: Handle keypair not found from metadata server using cells https://review.openstack.org/500954
11:00:15 efried alex_xu Good evening, you still around?
11:13:42 openstackgerrit OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035
11:51:48 efried cdent Ready for a lunchtime spitballing session?
11:51:59 cdent one moment please caller
11:55:59 openstackgerrit Eric Fried proposed openstack/nova master: Include /resource_providers/uuid/allocations link https://review.openstack.org/499826
11:58:37 cdent efried: k, was just finishing up an email about correcting a draft of my will. what’s up?
11:58:52 efried heh, that seems fairly important.
11:59:21 efried cdent I was reviewing your 'limit allocation candidates' patch and it occurred to me that the 'randomize' conf setting should apply whether we're limiting or not.
11:59:40 efried Left a comment to that effect, but wanted to brainstorm with you and see if you agree.
12:00:43 cdent I’m guessing you’re thinking: if we’re going to randomize at all, it should be whether there is a limit or not, and if it going to happen it should happen in one place, not in multiple clients?
12:00:59 efried cdent Javol
12:01:10 efried Were we randomizing from the scheduler somehow?
12:01:27 cdent we were leaving todos about needing to decide if/how to select from too many candidates
12:02:10 efried Oh, then yeah, IMO this is that decision, and this is the sensible place to do it.
12:02:18 cdent the belief is that most people will not want to randomize, as that will tend to spread, which is apparently not a common desire (I don’t actually know how certain or true that is)
12:02:35 cdent yeah, I think you’re right.
12:03:06 efried Okay, that answers the other point of whether we should default to True - sounds like no.
12:03:49 cdent I think we should, but apparently that would change behaviors in an unacceptable way
12:04:10 efried Even though the order of candidates is undefined today.
12:04:12 cdent and bias in favor of the user rather than ops or something
12:04:22 cdent it is undefined, but semi-static
12:04:34 efried But if we've ascertained that the general preference is pack vs. spread, we should indeed preserve that behavior.
12:04:40 cdent the database will do its own ordering, with some bias
12:04:55 efried Which will be deterministic, but not really predictable by a human.
12:05:26 cdent however, I expect that the complexity of the queries thes days, and the inclusion of usage informatin throws off a lot of that ordering
12:05:51 cdent but it was deemed an important part of the plan when discussed in denver
12:06:02 efried cdent Also, just a point of curiosity, were we planning to use the limit param from the scheduler? I would think so - it should be fairly simple to come up with a number that would always give us enough candidates. And that number would be pretty small, too, like on the order of a dozen or so.
12:06:17 cdent so I reckon the change is fairly simple: if not limit and conf thing true: random.shuffle(allocs)
12:06:45 cdent efried: yes, that’s eventual hope: that the scheduler would retrieve much less data
12:07:21 cdent some math of needed instances X needed alternates X fudge factor
12:07:41 efried Yeah, cause at this point we haven't chosen a cell yet, right?
12:08:11 efried Once we pick a cell we get down to three alternates (per instance)
12:08:13 cdent the cell is chosen based on the “claimed” destination
12:08:25 cdent three isn’t static is it, that comes from conf, yeah?
12:08:32 efried edleafe ^ ?
12:08:52 efried In any case, that would make the math simple. #alternates * #instances
12:08:54 cdent needed x retries x cells
12:09:15 efried Okay. Not critical right now, but it's on the radar - cool.
12:09:34 cdent if we don’t include X cells, we may not end up with enough space to pick from
12:09:48 cdent yeah, on the radar - cool
12:09:54 cdent glad you though of that
12:11:10 cdent efried: if you want another thing to do with with your copious free time, I’ve got some microversion_parse changes that need some thinking about and there are few people who are aware of all the bits of context, you might be a good reviewer: https://review.openstack.org/#/c/496212/ and https://review.openstack.org/#/c/495356/
12:11:33 cdent no rush on that (at all) just stuff I’m sort of rolling around for the cool radar
12:11:59 efried For my part, I got started on numbered groupings in GET /allocation_candidates
12:12:13 efried We've got like a 5-way race to placement microversion 1.11.
12:13:28 cdent Is it only 5?
12:44:43 efried dtantsur|brb I'd like to be invited to the discussion of ironic traits vs. configurables if possible. Thanks!
12:47:49 openstackgerrit Jan Zerebecki proposed openstack/nova master: Only log not correcting allocation once per period https://review.openstack.org/508262
12:48:52 openstackgerrit jichenjc proposed openstack/nova master: Remove duplicate error info https://review.openstack.org/510719
12:56:52 cdent maybe we should put traits in etcc and make them watchable
12:56:59 cdent jk/2
12:57:15 cdent s/etcc/etcd/
13:01:05 openstackgerrit Stephen Finucane proposed openstack/nova master: zuul: Move legacy jobs to project https://review.openstack.org/514309
13:12:13 bauzas efried: traits are not boolean
13:12:41 efried bauzas In the sense that they're True if they're present and False if they're absent, kinda?
13:12:45 bauzas efried: turning off a capability means we remove the trait
13:13:02 efried oh, no, I'm pretty sure that's the entire bone of contention here.
13:13:13 bauzas lemme respond on the ML thread
13:13:36 efried Though to be precise, you're correct: if we remove a *capability* (which is different from turning off a setting), we should remove the trait from that RP.
13:13:52 efried bauzas Which is consistent with what I said, though I should have been explicit about it.
13:13:56 cdent removing and turning off not the same thing
13:14:08 efried Right.
13:14:24 efried If I make it so the RP can no longer do the thing, that should come with removing the trait.
13:14:38 efried If the RP is still capable of doing the thing, and I just switch it off, I should leave the trait in place.

Earlier   Later