Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-20
21:03:23 efried jaypipes So here's what I'm thinking.
21:04:24 efried jaypipes Today the report client keeps aggregate associations outside of ProviderTree. I believe we need to move what is currently SchedulerReportClient._provider_aggregate_map into ProviderTree. Specifically, _Provider has a set() of aggregate UUIDs.
21:05:23 efried jaypipes Because the virt driver will ultimately be in charge of assigning aggregate associations, so we'll want the same suite of methods on ProviderTree to ask if a given RP is "in" an aggregate, add (or replace) aggregate associations; etc.
21:06:17 efried jaypipes Same thing for traits, which is where that change set of a couple hours ago was coming from - to be followed up by SRC methods to populate/query it.
21:11:14 jaypipes efried: not sure the virt driver will be responsible for associated an aggregate to a provider -- unless the virt driver is also creating those aggregates. Does PowerVM do that?
21:11:40 jaypipes efried: for traits, yeah, totes agree.
21:12:18 efried jaypipes In the only real world case we have right now - shared storage pool - yes. I can't think how else the aggregate would get created.
21:12:45 jaypipes efried: it was originally intended to be created by an admin or an external agent (for example, Cinder...)
21:14:03 efried jaypipes Yeah, I suppose I can see that. In our case, we use SSP for ephemeral, so it would have to be more like the admin. It would just be another step they have to do when they're setting up the host.
21:14:22 jaypipes efried: understood.
21:14:26 efried jaypipes BTW, is there any rule against me using the same UUID for an aggregate and a RP that's in it?
21:14:42 efried I mean, I'm sure you'll say that's not a good idea, but is anything gonna stop me?
21:15:00 jaypipes efried: not a good idea, but nothing will prevent you from doing that.
21:15:14 efried k
21:18:18 efried jaypipes Okay, so one more thing: If we're moving aggregates (and adding traits) to ProviderTree, we could keep track of the last-refreshed time in either place. I'm assuming we'd like to keep doing that part at the SRC rather than in ProviderTree?
21:18:55 efried since he's the one doing the refreshing.
21:21:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove the deprecated TrustedFilter and related options https://review.openstack.org/521659
21:26:07 jaypipes efried: yes
21:26:15 efried ight
21:30:15 openstackgerrit Dan Smith proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
21:30:16 openstackgerrit Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
21:38:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Use the RequestSpec when getting scheduler_hints in compute https://review.openstack.org/515461
21:38:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass RequestSpec to ConductorTaskAPI.build_instances https://review.openstack.org/515495
21:47:37 openstackgerrit Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
21:57:06 efried jaypipes Confirm: We weren't actually using the SRC aggregate map for anything yet?
22:12:37 mriedem efried: what happened here? https://review.openstack.org/#/q/status:abandoned+topic:bp/add-trait-support-in-allocation-candidates
22:12:44 mriedem is that all superseded by jay's other series?
22:13:15 efried mriedem Most of it, yes.
22:13:20 efried Let me look for outliers...
22:14:20 efried mriedem Yeah; alex_xu started off doing the refactor one way; then jaypipes did it a different way and jaypipes "prevailed" :)
22:14:50 mriedem ok, the new series isn't tracked in launchpad as far as i can tell so i don't know what's going on there
22:17:06 efried mriedem TBH, add-trait-support-in-allocation-candidates may be superseded by granular-resource-requests, depending on timing.
22:17:22 hangyang Hi there, I have some questions for time sync in vm and its KVM host. I have some RHEL7 instances in Ocata openstack cluster. The VMs are not running ntpd and after suspend/resume, I notice there is a time drift between the VM and its KVM host and the VM will never catch up with host. But for stop/start, the vm can keep time in sync with its host. Any idea about how to solve the suspend issue? Should I run ntpd in the guest
22:17:29 efried mriedem See my comments in https://review.openstack.org/#/c/479776/
22:17:36 efried (which is the last open one tracked by that bp)
22:23:15 efried mriedem Since you seem to be looking, the rest of the ksa patches are gonna be based on https://review.openstack.org/#/c/490057/
22:23:27 efried ...which I believe you once referred to as "scary".
22:23:51 mriedem yes
22:24:12 mriedem i'm going through all of our queens blueprints and tracking latest status in https://etherpad.openstack.org/p/nova-queens-blueprint-status
22:24:14 mriedem if you must know
22:24:25 mriedem only about 35 more to go
22:24:35 flwang mriedem: sorry for chiming in
22:24:46 flwang mriedem: question about the poverVM driver, does it support Power 720 series?
22:26:39 efried flwang I *think* so. Note that we have a dedicated #openstack-powervm channel - though it's not going to help you much today as everyone else is on vacation already. But let me see if I can find out that answer for sure...
22:27:21 flwang efried: BIG thanks from an ex-IBMer
22:29:03 tonyb dansmith: What are the ds* flavors in devstack used for?
22:29:07 efried flwang The answer is: nope, P8 and up.
22:29:59 tonyb flwang: I have a 720 in my garage, and yeah no KVM, PowerVM or even wemu(TCG) love there :(
22:30:53 flwang really? that's a pitty
22:31:13 flwang but I found this https://www-01.ibm.com/events/wwe/grp/grp020.nsf/vLookupPDFs/Demo%20days%20LoP%20-%20Cloud%20on%20Power%20-%2018%20Mag%202015/$file/Demo%20days%20LoP%20-%20Cloud%20on%20Power%20-%2018%20Mag%202015.pdf
22:31:16 flwang see page 18
22:32:26 efried flwang Was just about to say: *PowerVC* supports 720.
22:32:59 efried flwang It runs through HMC, not community code, but the interface is seamlessly identical I believe.
22:33:48 flwang efried: I see. so that only means PowerVC can via HMC manage 720, right?
22:33:58 jaypipes efried, mriedem: off for the night. will review all the things in the morning.
22:34:01 efried flwang Correct
22:34:10 efried jaypipes Have a good evening.
22:34:21 efried jeez, it got late
22:34:28 flwang efried: where can i double check if there is a KVM/PowerVM support for Power 720?
22:34:31 tonyb efried: Yeah but not helpful for people lik me that don't have an HMC or PowerVC, still I only use mine for testing yaboot which is nearly dead on 64-bit anyway ... longlive grub!
22:35:36 efried flwang Let me PM you an email address to get that conversation started...
22:35:46 flwang efried: thank you so much
22:37:13 tonyb that'd be kinda cool from a geeky POV
22:38:14 mriedem tonyb: i'm sure mrodden and lbragstad would like to help with that
22:38:36 tonyb mriedem: \o/
22:39:50 tonyb the more I think about it the more fun I think that'd be
22:40:27 efried tonyb I'll review your code :)
22:48:06 tonyb efried: :)
23:04:37 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
23:04:37 openstackgerrit Ildiko Vancsa proposed openstack/nova master: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
23:11:22 ildikov mriedem: so quickly, did you think of something like this for the Nova side check: https://review.openstack.org/#/c/330285/148..149/nova/compute/api.py ?
23:14:32 mriedem ildikov: close
23:14:34 mriedem but -1
23:14:37 mriedem muwahahahaha
23:14:52 mriedem we should only do that for the new flow
23:14:59 mriedem cinder will check it otherwise during reserve()
23:15:03 mriedem which is why we removed check_attach in the first place
23:15:16 ildikov mriedem: ok, so do a microversion check before the check calls, right?
23:15:58 ildikov yeah, I know, I just wasn't sure whether this is the right direction and didn't want to overcomplicate this before asking for your opinion
23:16:23 mriedem well, presumably we know if we're doing the new flow or not based on the attachment stuff we do
23:16:23 ildikov as I expected something, 'no, that's insane, you should've done this and that instead', lol
23:16:30 mriedem like for swap_volume we check if the old bdm has an attachment_id i think
23:16:47 mriedem for attach_volume it's probably trickier, because i think we try to call attachment_create and if that fails we fallback to calling reserve()
23:16:54 ildikov yeah, but for the regular attach the first time we check is _check_attach_and_reserve_volume
23:17:13 ildikov yep, so by that time we created a new BDM, etc
23:17:16 mriedem yeah, so we probably have to do this before attachment_create() for the attach_volume case
23:17:23 ildikov hence I would do this check before that
23:17:30 mriedem but for swap_volume i think we can not do this if we're old flow
23:17:32 mriedem and we know that
23:17:43 mriedem you also have to handle that bdm method raising a VolumeBDMNotFound error
23:17:47 ildikov sure, I'll check that part
23:18:12 ildikov ah, right, forgot that
23:18:19 mriedem otherwise yeah i think this is what i was thinking of
23:18:34 ildikov ok, cool, I'll fix up the nits then
23:18:36 ildikov thanks!
23:19:09 mriedem yw
23:20:23 mriedem Kevin_Zheng: have you started any of the neutron code for this yet? https://bugs.launchpad.net/neutron/+bug/1718605
23:20:23 openstack Launchpad bug 1718605 in neutron "[RFE] Support regex matching when filtering port with IP address" [Wishlist,Triaged] - Assigned to Zhenyu Zheng (zhengzhenyu)
23:21:31 Kevin_Zheng mriedem I’ve wrote some poc code
23:21:52 Kevin_Zheng Didn’t push to gerrit yet

Earlier   Later