| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-20 | |||
| 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: libvirt: Allow multiple volume attachments https://review.openstack.org/267587 | |
| 23:04:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 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 | ildikov | as I expected something, 'no, that's insane, you should've done this and that instead', lol | |
| 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: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 | openstack | Launchpad bug 1718605 in neutron "[RFE] Support regex matching when filtering port with IP address" [Wishlist,Triaged] - Assigned to Zhenyu Zheng (zhengzhenyu) | |
| 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: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 | |
| 23:25:22 | clarkb | mriedem: hey, so one of the reasons logstash is so behind right now is we keep trying to push million line libvirtd log files through it. How huge of a loss would it be if we stopped indexing those files? | |
| 23:26:22 | mriedem | clarkb: i didn't think we indexed those, so not a loss i'd say | |
| 23:26:26 | clarkb | mostly trying to get it back to manageable then add things back in while we can address potential problems with it | |
| 23:26:33 | clarkb | mriedem: ok cool I'm going to go ahead and drop indexing for them then | |
| 23:26:34 | mriedem | if anything, i've needed the qemu guest logs indexed at times for things like live migration failures | |
| 23:27:02 | mriedem | that reminds me that i need to cleanup our e-r queries | |
| 23:29:06 | clarkb | mriedem: https://review.openstack.org/521681 fyi | |
| 23:30:43 | mriedem | +1 | |
| 23:55:04 | dansmith | tonyb: when we removed the default flavors from the db migrations we added those in devstack setup so you could depend on some flavors in a default devstack environment | |
| 23:55:18 | dansmith | tonyb: I think we re-added the original ones to devstack after that when people complained (IIRC | |
| 23:58:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Move aggregates from report client to ProviderTree https://review.openstack.org/521685 | |
| 23:58:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Traits ops on ProviderTree https://review.openstack.org/521605 | |
| 23:58:56 | openstackgerrit | Eric Fried proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686 | |
| #openstack-nova - 2017-11-21 | |||
| 00:33:22 | openstackgerrit | Vipin Balachandran proposed openstack/nova master: VMware: Support volumes backed by VStorageObject https://review.openstack.org/521690 | |
| 01:28:49 | tonyb | dansmith: Thanks. | |
| 02:00:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Fix an example in "Delete Assisted Volume Snapshot" https://review.openstack.org/514128 | |
| 02:00:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add a description of 'key_name' in rebuild https://review.openstack.org/519993 | |
| 02:01:41 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Update document related to host aggregate https://review.openstack.org/514499 | |
| 02:29:34 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Regenerate and pass configdrive when rebuild Ironic nodes https://review.openstack.org/503088 | |
| 02:29:38 | openstackgerrit | Merged openstack/nova master: Include project_id and user_id in AllocationList.get_all_by_consumer_id https://review.openstack.org/512420 | |
| 02:34:49 | dims | mriedem_away : you need to send a translation for your team meeting email :) | |
| 02:45:04 | gmann | alex_xu: can you re review this -https://review.openstack.org/#/c/516104/9 | |
| 02:48:51 | gmann | yikun: i replied on this, can you check - https://review.openstack.org/#/c/515413/ | |
| 03:03:22 | Kevin_Zheng | gmann: yikun is on his trip to bug smash, maybe not available for the next 6 hours | |
| 03:04:38 | gmann | Kevin_Zheng: ohk, thanks for info. | |