| *** jwcroppe has joined #openstack-powervm | 00:14 | |
| *** svenkat has joined #openstack-powervm | 00:37 | |
| *** thorst has joined #openstack-powervm | 00:46 | |
| *** thorst has quit IRC | 00:51 | |
| *** esberglu has joined #openstack-powervm | 01:06 | |
| *** esberglu has quit IRC | 01:10 | |
| *** svenkat has quit IRC | 01:29 | |
| *** apearson has joined #openstack-powervm | 01:44 | |
| *** apearson has quit IRC | 01:50 | |
| *** apearson has joined #openstack-powervm | 01:51 | |
| *** apearson has quit IRC | 01:51 | |
| *** apearson has joined #openstack-powervm | 01:52 | |
| *** apearson has quit IRC | 01:52 | |
| *** esberglu has joined #openstack-powervm | 01:57 | |
| *** esberglu has quit IRC | 01:57 | |
| *** thorst has joined #openstack-powervm | 02:47 | |
| *** esberglu has joined #openstack-powervm | 02:51 | |
| *** thorst has quit IRC | 02:52 | |
| *** esberglu has quit IRC | 02:55 | |
| *** thorst has joined #openstack-powervm | 03:48 | |
| *** thorst has quit IRC | 03:53 | |
| *** chhavi has joined #openstack-powervm | 04:21 | |
| *** esberglu has joined #openstack-powervm | 05:34 | |
| *** esberglu has quit IRC | 05:35 | |
| *** esberglu has joined #openstack-powervm | 05:35 | |
| *** esberglu has quit IRC | 05:35 | |
| *** k0da has joined #openstack-powervm | 05:36 | |
| *** thorst has joined #openstack-powervm | 05:49 | |
| *** thorst has quit IRC | 05:53 | |
| *** esberglu has joined #openstack-powervm | 07:23 | |
| *** jwcroppe has quit IRC | 07:26 | |
| *** esberglu has quit IRC | 07:27 | |
| *** thorst has joined #openstack-powervm | 07:50 | |
| *** thorst has quit IRC | 07:54 | |
| *** k0da has quit IRC | 08:12 | |
| *** esberglu has joined #openstack-powervm | 09:13 | |
| *** esberglu has quit IRC | 09:13 | |
| *** esberglu has joined #openstack-powervm | 09:14 | |
| *** esberglu has quit IRC | 09:18 | |
| *** k0da has joined #openstack-powervm | 09:31 | |
| *** thorst has joined #openstack-powervm | 09:51 | |
| *** thorst has quit IRC | 09:55 | |
| *** thorst has joined #openstack-powervm | 10:12 | |
| *** thorst has quit IRC | 10:16 | |
| *** thorst has joined #openstack-powervm | 11:03 | |
| *** smatzek has joined #openstack-powervm | 11:31 | |
| *** svenkat has joined #openstack-powervm | 11:44 | |
| *** svenkat_ has joined #openstack-powervm | 11:47 | |
| *** svenkat has quit IRC | 11:48 | |
| *** svenkat_ is now known as svenkat | 11:48 | |
| *** esberglu has joined #openstack-powervm | 11:55 | |
| *** esberglu has quit IRC | 11:59 | |
| *** edmondsw has joined #openstack-powervm | 12:29 | |
| *** miltonm has joined #openstack-powervm | 12:50 | |
| *** esberglu has joined #openstack-powervm | 12:52 | |
| *** apearson has joined #openstack-powervm | 12:52 | |
| *** esberglu has quit IRC | 12:52 | |
| *** jwcroppe has joined #openstack-powervm | 12:52 | |
| *** kylek3h has joined #openstack-powervm | 12:54 | |
| *** jay1_ has joined #openstack-powervm | 12:54 | |
| *** esberglu has joined #openstack-powervm | 13:02 | |
| esberglu | #startmeeting powervm_driver_meeting | 13:03 |
|---|---|---|
| openstack | Meeting started Tue Jul 18 13:03:09 2017 UTC and is due to finish in 60 minutes. The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:03 |
| openstack | The meeting name has been set to 'powervm_driver_meeting' | 13:03 |
| thorst | o/ | 13:03 |
| efried | \o | 13:03 |
| esberglu | #topic In-tree Driver | 13:03 |
| esberglu | Any new developments here? | 13:04 |
| efried | nope | 13:04 |
| edmondsw | o/ | 13:04 |
| mdrabe | o/ | 13:05 |
| edmondsw | should be quiet on the IT driver for a bit with that blueprint done for pike | 13:05 |
| esberglu | Yep. Just a reminder that next week is the pike 3 milestone (feature freeze) | 13:05 |
| efried | Well, except for testing | 13:06 |
| esberglu | #topic OOT driver | 13:06 |
| esberglu | Anyone have discussion items OOT? | 13:07 |
| efried | Couple g-r bumps proposed by the bot. | 13:08 |
| efried | Been keeping an eye on our CI for those, haven't looked yet this morning. | 13:08 |
| mdrabe | Still waiting on an env to patch for the NVRAM event stuff | 13:08 |
| esberglu | The g-r patches were getting blocked by those subnetpool tests. Just merged that | 13:09 |
| esberglu | I'll kick off rechecks | 13:09 |
| efried | k | 13:09 |
| efried | esberglu Can you post the link to the agenda pls? | 13:11 |
| esberglu | https://etherpad.openstack.org/p/powervm_driver_meeting_agenda | 13:11 |
| esberglu | If people could start using that it would be really helpful. So I don't have to ask if there are any other topics every few minutes | 13:12 |
| thorst | :-) | 13:12 |
| esberglu | #topic PowerVM CI | 13:12 |
| esberglu | Still working on the devstack generated tempest.conf | 13:12 |
| esberglu | Gonna update the local.conf files first and make sure they don't break stacking or anything else | 13:12 |
| esberglu | Then propose any needed devstack/tempest changes | 13:13 |
| esberglu | Then make the switch to the generated tempest.conf files | 13:13 |
| esberglu | Otherwise just working through https://etherpad.openstack.org/p/powervm_ci_todos | 13:13 |
| esberglu | #topic Driver Testing | 13:14 |
| esberglu | Need discussion on PCI PassThru Investigation? | 13:14 |
| efried | esberglu That's the next topic. | 13:14 |
| edmondsw | I would have done that under other business | 13:14 |
| efried | What's the status of iSCSI, jay1_ chhavi ? | 13:14 |
| jay1_ | Yeah.. testing is inprogress | 13:15 |
| jay1_ | will update tonight | 13:15 |
| edmondsw | jay1_ nothing blocking you at the moment, though? | 13:16 |
| jay1_ | Yes edmondsw | 13:16 |
| edmondsw | I see the etherpad is still showing an issue on neo34... is that just old data? | 13:16 |
| edmondsw | https://etherpad.openstack.org/p/powervm-driver-test-status | 13:16 |
| jay1_ | Yeah.. in the evening only issue got resolved.. I will wipe out that issue info | 13:16 |
| edmondsw | tx | 13:16 |
| edmondsw | have you seen any evidence that the phyp guys are looking at neo32? | 13:17 |
| jay1_ | no, it is still in open state | 13:18 |
| efried | At this point I've forgotten what the other thing was that we were wanting a pypowervm release for. Was it power-off? | 13:19 |
| edmondsw | jay1_ please prompt them... remind them you're holding the system for them and can't do that forever | 13:19 |
| jay1_ | Yeah, just added comment | 13:19 |
| edmondsw | efried I think so? been too long | 13:19 |
| efried | back in a sec... | 13:19 |
| edmondsw | jay1_ might want to email the owner directly | 13:19 |
| thorst | jay1_: who are the PHYP guys? Not the NL guys, but actual PHYP? | 13:20 |
| edmondsw | yeah, phyp | 13:20 |
| thorst | wow | 13:20 |
| edmondsw | thorst^ | 13:20 |
| thorst | can I get subscribed to that defect? | 13:20 |
| edmondsw | thorst apparently we hit a bug they've never been able to track down, and it clears up when you restart the system, so we're leaving it for them to look at | 13:20 |
| thorst | did seroyer ask us to hold it for them? | 13:20 |
| edmondsw | thorst yes | 13:21 |
| edmondsw | jay1_ what was the phyp defect number again? | 13:21 |
| thorst | alright. Please subscribe me and I'll be a...jerk | 13:21 |
| thorst | just slack it to me | 13:21 |
| jay1_ | SW395662 | 13:21 |
| edmondsw | thorst^ | 13:21 |
| edmondsw | on to PCI? | 13:22 |
| edmondsw | #topic PCI PassThru Investigation | 13:23 |
| edmondsw | efried I started looking at the reviews you added me to | 13:23 |
| edmondsw | that's just barely getting our feet wet, of course | 13:24 |
| edmondsw | tied up with some PowerVC stuff atm, trying to get through that so I can get to the PCI stuff in earnest, but probably won't be before next week | 13:24 |
| edmondsw | efried I think it's pretty much the same for you? | 13:25 |
| edmondsw | oh, he had to step away | 13:26 |
| efried | I'm back - yeah, same. | 13:26 |
| thorst | I wasn't aware of those reviews, but I'll be looking through them shortly | 13:26 |
| thorst | as long as we can iterate what devices are there and attach them to a VM...I'm happy | 13:27 |
| efried | My plan also includes trying to familiarize myself with the current code. | 13:27 |
| thorst | basic use case to start, then complexity later :-D | 13:27 |
| efried | And then maybe try to get some time on jaypipes's calendar to talk through the vision as it relates to resource groups et al. | 13:27 |
| efried | Because I think that whole architecture may be in flux | 13:28 |
| efried | and we want to make sure that when it stabilizes, it does so in a way that's actually useful for us. | 13:28 |
| efried | Just spitballin here, but... | 13:30 |
| edmondsw | agree with all of that | 13:30 |
| thorst | efried: probability of something for queens is low, medium or? | 13:31 |
| thorst | eh, doesn't need an answer | 13:33 |
| thorst | lets just do the reviews and do our best :) | 13:33 |
| edmondsw | yeah, too early to answer that I think | 13:33 |
| thorst | next topic/ | 13:34 |
| thorst | ? | 13:34 |
| esberglu | #topic Open Discussion | 13:35 |
| edmondsw | #topic Open Discussion | 13:35 |
| esberglu | thorst: You want to abandon 4707? | 13:35 |
| esberglu | I'm gonna come back to that at some point, but I don't think that will be the final solution | 13:35 |
| edmondsw | esberglu is there anything on the TODO list for that? | 13:36 |
| edmondsw | s/list/etherpad/ | 13:36 |
| thorst | esberglu: done | 13:36 |
| esberglu | edmondsw: I'll add it if not | 13:36 |
| edmondsw | tx | 13:36 |
| thorst | just a FYI that I'm still planning to do a VIF overhaul | 13:37 |
| edmondsw | probably there, just didn't ring a bell for me | 13:37 |
| edmondsw | thorst can you add that to https://etherpad.openstack.org/p/powervm-in-tree-todos | 13:37 |
| thorst | yep yep | 13:37 |
| esberglu | Anything else before I call it? | 13:39 |
| edmondsw | call it | 13:40 |
| esberglu | #endmeeting | 13:40 |
| openstack | Meeting ended Tue Jul 18 13:40:34 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:40 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.html | 13:40 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.txt | 13:40 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.log.html | 13:40 |
| *** smatzek has quit IRC | 13:40 | |
| efried | So thorst edmondsw A bit more on the PCI thing. | 13:42 |
| efried | I'm wondering if it would be reasonable for us to suggest the following basic architecture for nova: | 13:42 |
| efried | 1) Based on a conf option, don't use pci.passthrough_whitelist at all. Let the compute driver take responsibility for "whitelisting" (deciding which devices are allowed to go where). | 13:43 |
| efried | 2) A driver method, to be optionally overridden per driver, that provides the list of PCI devices back to the scheduler. It's possible that this part actually gels with the resource provider direction anyway. | 13:45 |
| efried | ^ as part of get_inventory. | 13:45 |
| *** esberglu has quit IRC | 13:45 | |
| efried | Thoughts? | 13:46 |
| edmondsw | efried does that work if your environment uses multiple drivers, and some support #2 but some need to use whitelisting? | 13:46 |
| efried | multiple drivers on the same compute host?? | 13:46 |
| edmondsw | no, different hosts | 13:46 |
| edmondsw | oh, the whitelisting is on the host... so yeah, that should work, I think | 13:47 |
| efried | Oh, that ought to be fine, I would have thought. Perhaps I'm misunderstanding the question. | 13:47 |
| edmondsw | sorry, you are much more familiar with how things work today than I am :) | 13:47 |
| efried | I doubt that. | 13:47 |
| efried | A year ago, maybe. | 13:47 |
| efried | I've slept since then. | 13:47 |
| efried | Anyway, that's kinda the initial plan in the back of my head. Once we are able to take control in our driver, the rest should be fairly straightforward. | 13:48 |
| edmondsw | I think that makes sense. I'd say run it by pipes and see what he thinks. | 13:48 |
| efried | edmondsw Yeah, will do. Want to get a bit more familiar with the code and the resource stuff first. | 13:49 |
| edmondsw | efried does that gel with the review you pointed me to about adding tags to the whitelist? how would you do that without a whitelist? | 13:50 |
| efried | edmondsw I wanted us to keep an eye on those blueprints in case we wind up getting rejected and having to use those instead. | 13:51 |
| edmondsw | would the driver have it's own whitelist of some kind? | 13:51 |
| edmondsw | efried the review I'm thinking of seemed like a parallel effort, not something really in conflict with what we want | 13:52 |
| efried | The problem with the whitelist in general is that it's based on hardware addresses that are looked up by bits of nova that are out of the control of our compute driver, and which assume those devices are accessible on the compute host via Linux /dev special files | 13:52 |
| edmondsw | sure, I get that we don't want nova doing that, we want the driver doing that... | 13:52 |
| edmondsw | but the driver would need its own whitelisting mechanism, correct? | 13:53 |
| efried | edmondsw My thought was that we maybe ought to be pushing those "parallel" blueprints in a direction that would help us (or at least not hinder us) in case we don't get what we want. | 13:53 |
| edmondsw | yes | 13:53 |
| edmondsw | totally | 13:53 |
| efried | edmondsw So the driver's concept of whitelisting isn't really the same as what goes in the conf. | 13:54 |
| *** jay1_ has quit IRC | 13:54 | |
| efried | Because the former doesn't allow the operator control, except via the latter. | 13:54 |
| edmondsw | even if we do get what we want, we need those blueprints to fit with what we do | 13:54 |
| efried | edmondsw Yes | 13:54 |
| edmondsw | the former doesn't... ? | 13:55 |
| efried | I should probably have said admin, not operator, though the distinction is still fuzzy to me. | 13:56 |
| efried | The guy who writes the conf - let's call him the admin - is not necessarily the guy who does the deploys - let's call him the operator. | 13:57 |
| efried | The admin wants to be able to control which devices are allowed to be deployed on VMs. | 13:57 |
| efried | And set it up in such a way that the operator can use them, but not control that list. | 13:57 |
| efried | That's the whitelist. | 13:57 |
| edmondsw | the guy who writes the conf is the operator | 13:57 |
| edmondsw | the guy who does the deploy... call him user | 13:57 |
| efried | Okay, soit. | 13:57 |
| edmondsw | efried I think we're in agreement... | 13:58 |
| efried | So that's where I suspect we'd get pushback - if we're just giving the operator a way to say "use whatever you can find". | 13:58 |
| edmondsw | still need a whitelist, but it will just be different from the current whitelist (driver-run instead of nova-run) | 13:58 |
| efried | Well, that's the thing. I think we would still need a way for the operator to determine that whitelist, even if it's driver-run. | 13:59 |
| edmondsw | I think that's what I said, no? | 13:59 |
| edmondsw | are you still using operator to mean the person that does a deploy (user)? | 14:00 |
| *** esberglu has joined #openstack-powervm | 14:00 | |
| edmondsw | in openstack parlance, operator is the person that sets up and administers the cloud | 14:00 |
| efried | No, we switched to operator-owns-conf, user-does-deploys. | 14:00 |
| edmondsw | k good | 14:00 |
| efried | It's unfortunately going to boil down to the same thing, I'm afraid - the conf needs to contain a whitelist of some form. | 14:00 |
| edmondsw | so yes, the guy who does the conf needs to create the whitelist | 14:00 |
| *** smatzek has joined #openstack-powervm | 14:00 | |
| edmondsw | efried yep, agreed | 14:00 |
| efried | So we have two options. | 14:01 |
| efried | Either we tell nova to ignore pci.passthrough_whitelist (namely its absence - don't use the thing) and introduce some other powervm-specific conf option that we use as our own whitelist... | 14:02 |
| efried | Or we make the existing pci.passthrough_whitelist actually be usable by powervm, which it basically ain't today. | 14:02 |
| efried | And that second thing is where I thought a couple of those blueprints could come into play. | 14:02 |
| efried | Basically, if we have the ability to give arbitrary names (which may be these "alias" things) to our PCI devices, and NOT have nova try to find them under /dev... | 14:03 |
| efried | We can make those names correspond to device IDs that make sense to our REST API (think like DRC names) | 14:05 |
| efried | The operator populates the whitelist based on the output of some kind of `pvmctl pci list` or whatever. | 14:05 |
| efried | And we could use "tags" to designate switches/fabrics/ports/whatever for things (like SR-IOV) that aren't generic (like GPUs). | 14:07 |
| efried | But that info seems like it would be more appropriate for the other side - the get_inventory() side. | 14:07 |
| edmondsw | efried I suspect we'll need driver-specific whitelisting formats, and so be unable to have drivers use pci.passthrough_whitelist... but we could try | 14:07 |
| efried | edmondsw Right, I believe that's what we need to dig into. Can we piggyback of the existing pci.passthrough_whitelist, or do we need a bypass that lets us roll our own? | 14:08 |
| edmondsw | maybe allowing drivers to add driver-specific options to that pci conf section in addition to standard options | 14:08 |
| efried | Nothing stopping us from registering options in the [pci] section. | 14:09 |
| efried | But it would have to start with an option that nova proper understands that lets us say "don't use pci.passthrough_whitelist". | 14:09 |
| edmondsw | efried well, except that you have to be careful not to name them in a way that could conflict with another driver | 14:09 |
| efried | yahyah, but that gets caught immediately. | 14:09 |
| efried | The driver won't start if you try to register something with a name conflict. | 14:10 |
| efried | back in 10. | 14:10 |
| edmondsw | efried yes, but then you have one driver taking a name that shouldn't belong to it if we're not careful... just need to make drivers prefix their options with something specific to their driver e.g. "powervm_" | 14:12 |
| *** jay1_ has joined #openstack-powervm | 14:32 | |
| efried | edmondsw Yes, or put them in the [powervm] section. | 14:44 |
| edmondsw | exactly | 14:45 |
| *** tjakobs has joined #openstack-powervm | 14:48 | |
| openstackgerrit | Merged openstack/ceilometer-powervm master: Updated from global requirements https://review.openstack.org/477917 | 15:02 |
| openstackgerrit | Merged openstack/networking-powervm master: Updated from global requirements https://review.openstack.org/477976 | 15:11 |
| openstackgerrit | Taylor Jakobson proposed openstack/nova-powervm master: Add support for ceph volumes https://review.openstack.org/484478 | 15:20 |
| *** k0da has quit IRC | 15:31 | |
| *** jay1_ has quit IRC | 15:33 | |
| *** jay1_ has joined #openstack-powervm | 15:46 | |
| *** smatzek has quit IRC | 16:00 | |
| *** smatzek has joined #openstack-powervm | 16:02 | |
| *** smatzek has quit IRC | 17:02 | |
| *** smatzek has joined #openstack-powervm | 17:11 | |
| *** smatzek has quit IRC | 17:15 | |
| *** smatzek has joined #openstack-powervm | 17:15 | |
| *** chhavi has quit IRC | 18:17 | |
| *** jay1_ has quit IRC | 18:17 | |
| *** k0da has joined #openstack-powervm | 19:54 | |
| *** smatzek has quit IRC | 20:06 | |
| *** esberglu has quit IRC | 20:31 | |
| edmondsw | esberglu 5571 is still WIP, right? | 20:31 |
| edmondsw | remove that from the commit message when you want a real review, but looks ok so far | 20:32 |
| *** esberglu has joined #openstack-powervm | 20:44 | |
| *** esberglu has quit IRC | 20:44 | |
| *** esberglu has joined #openstack-powervm | 20:44 | |
| *** svenkat has quit IRC | 21:02 | |
| *** apearson has quit IRC | 21:16 | |
| *** thorst has quit IRC | 21:30 | |
| *** svenkat has joined #openstack-powervm | 21:35 | |
| *** thorst has joined #openstack-powervm | 21:42 | |
| *** thorst has quit IRC | 21:44 | |
| *** svenkat has quit IRC | 21:49 | |
| edmondsw | esberglu 5571 is still WIP, right? remove that from the commit message when you want a real review, but looks ok so far | 22:04 |
| edmondsw | efried what are your thoughts on my latest comments in https://review.openstack.org/#/c/467599 ? | 22:05 |
| efried | edmondsw Haven't looked yet. | 22:05 |
| edmondsw | efried yeah, I just added them :) Look when you get a chance | 22:05 |
| efried | edmondsw Oh, that happened in the last hour. Yeah, tomorrow probably. | 22:05 |
| edmondsw | sure | 22:05 |
| esberglu | edmondsw: Yep still WIP | 22:16 |
| *** kylek3h has quit IRC | 22:23 | |
| *** miltonm has quit IRC | 22:41 | |
| *** edmondsw has quit IRC | 22:47 | |
| *** jwcroppe has quit IRC | 23:00 | |
| *** jwcroppe has joined #openstack-powervm | 23:01 | |
| *** jwcroppe_ has joined #openstack-powervm | 23:03 | |
| *** thorst has joined #openstack-powervm | 23:04 | |
| *** jwcroppe has quit IRC | 23:05 | |
| *** thorst has quit IRC | 23:06 | |
| *** k0da has quit IRC | 23:12 | |
| *** tjakobs has quit IRC | 23:17 | |
| *** esberglu has quit IRC | 23:36 | |
| *** jwcroppe_ has quit IRC | 23:45 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!