| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-20 | |||
| 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 | |
| 23:22:31 | mriedem | ok, just checking | |