Tuesday, 2017-07-18

*** jwcroppe has joined #openstack-powervm00:14
*** svenkat has joined #openstack-powervm00:37
*** thorst has joined #openstack-powervm00:46
*** thorst has quit IRC00:51
*** esberglu has joined #openstack-powervm01:06
*** esberglu has quit IRC01:10
*** svenkat has quit IRC01:29
*** apearson has joined #openstack-powervm01:44
*** apearson has quit IRC01:50
*** apearson has joined #openstack-powervm01:51
*** apearson has quit IRC01:51
*** apearson has joined #openstack-powervm01:52
*** apearson has quit IRC01:52
*** esberglu has joined #openstack-powervm01:57
*** esberglu has quit IRC01:57
*** thorst has joined #openstack-powervm02:47
*** esberglu has joined #openstack-powervm02:51
*** thorst has quit IRC02:52
*** esberglu has quit IRC02:55
*** thorst has joined #openstack-powervm03:48
*** thorst has quit IRC03:53
*** chhavi has joined #openstack-powervm04:21
*** esberglu has joined #openstack-powervm05:34
*** esberglu has quit IRC05:35
*** esberglu has joined #openstack-powervm05:35
*** esberglu has quit IRC05:35
*** k0da has joined #openstack-powervm05:36
*** thorst has joined #openstack-powervm05:49
*** thorst has quit IRC05:53
*** esberglu has joined #openstack-powervm07:23
*** jwcroppe has quit IRC07:26
*** esberglu has quit IRC07:27
*** thorst has joined #openstack-powervm07:50
*** thorst has quit IRC07:54
*** k0da has quit IRC08:12
*** esberglu has joined #openstack-powervm09:13
*** esberglu has quit IRC09:13
*** esberglu has joined #openstack-powervm09:14
*** esberglu has quit IRC09:18
*** k0da has joined #openstack-powervm09:31
*** thorst has joined #openstack-powervm09:51
*** thorst has quit IRC09:55
*** thorst has joined #openstack-powervm10:12
*** thorst has quit IRC10:16
*** thorst has joined #openstack-powervm11:03
*** smatzek has joined #openstack-powervm11:31
*** svenkat has joined #openstack-powervm11:44
*** svenkat_ has joined #openstack-powervm11:47
*** svenkat has quit IRC11:48
*** svenkat_ is now known as svenkat11:48
*** esberglu has joined #openstack-powervm11:55
*** esberglu has quit IRC11:59
*** edmondsw has joined #openstack-powervm12:29
*** miltonm has joined #openstack-powervm12:50
*** esberglu has joined #openstack-powervm12:52
*** apearson has joined #openstack-powervm12:52
*** esberglu has quit IRC12:52
*** jwcroppe has joined #openstack-powervm12:52
*** kylek3h has joined #openstack-powervm12:54
*** jay1_ has joined #openstack-powervm12:54
*** esberglu has joined #openstack-powervm13:02
esberglu#startmeeting powervm_driver_meeting13:03
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:03
openstackThe meeting name has been set to 'powervm_driver_meeting'13:03
esberglu#topic In-tree Driver13:03
esbergluAny new developments here?13:04
edmondswshould be quiet on the IT driver for a bit with that blueprint done for pike13:05
esbergluYep. Just a reminder that next week is the pike 3 milestone (feature freeze)13:05
efriedWell, except for testing13:06
esberglu#topic OOT driver13:06
esbergluAnyone have discussion items OOT?13:07
efriedCouple g-r bumps proposed by the bot.13:08
efriedBeen keeping an eye on our CI for those, haven't looked yet this morning.13:08
mdrabeStill waiting on an env to patch for the NVRAM event stuff13:08
esbergluThe g-r patches were getting blocked by those subnetpool tests. Just merged that13:09
esbergluI'll kick off rechecks13:09
efriedesberglu Can you post the link to the agenda pls?13:11
esbergluIf 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 minutes13:12
esberglu#topic PowerVM CI13:12
esbergluStill working on the devstack generated tempest.conf13:12
esbergluGonna update the local.conf files first and make sure they don't break stacking or anything else13:12
esbergluThen propose any needed devstack/tempest changes13:13
esbergluThen make the switch to the generated tempest.conf files13:13
esbergluOtherwise just working through  https://etherpad.openstack.org/p/powervm_ci_todos13:13
esberglu#topic Driver Testing13:14
esbergluNeed discussion on PCI PassThru Investigation?13:14
efriedesberglu That's the next topic.13:14
edmondswI would have done that under other business13:14
efriedWhat's the status of iSCSI, jay1_ chhavi ?13:14
jay1_Yeah.. testing is inprogress13:15
jay1_will update tonight13:15
edmondswjay1_ nothing blocking you at the moment, though?13:16
jay1_Yes edmondsw13:16
edmondswI see the etherpad is still showing an issue on neo34... is that just old data?13:16
jay1_Yeah.. in the evening only issue got resolved.. I will wipe out that issue info13:16
edmondswhave you seen any evidence that the phyp guys are looking at neo32?13:17
jay1_no, it is still in open state13:18
efriedAt this point I've forgotten what the other thing was that we were wanting a pypowervm release for.  Was it power-off?13:19
edmondswjay1_ please prompt them... remind them you're holding the system for them and can't do that forever13:19
jay1_Yeah, just added comment13:19
edmondswefried I think so? been too long13:19
efriedback in a sec...13:19
edmondswjay1_ might want to email the owner directly13:19
thorstjay1_: who are the PHYP guys?  Not the NL guys, but actual PHYP?13:20
edmondswyeah, phyp13:20
thorstcan I get subscribed to that defect?13:20
edmondswthorst 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 at13:20
thorstdid seroyer ask us to hold it for them?13:20
edmondswthorst yes13:21
edmondswjay1_ what was the phyp defect number again?13:21
thorstalright.  Please subscribe me and I'll be a...jerk13:21
thorstjust slack it to me13:21
edmondswon to PCI?13:22
edmondsw#topic PCI PassThru Investigation13:23
edmondswefried I started looking at the reviews you added me to13:23
edmondswthat's just barely getting our feet wet, of course13:24
edmondswtied 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 week13:24
edmondswefried I think it's pretty much the same for you?13:25
edmondswoh, he had to step away13:26
efriedI'm back - yeah, same.13:26
thorstI wasn't aware of those reviews, but I'll be looking through them shortly13:26
thorstas long as we can iterate what devices are there and attach them to a VM...I'm happy13:27
efriedMy plan also includes trying to familiarize myself with the current code.13:27
thorstbasic use case to start, then complexity later  :-D13:27
efriedAnd 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
efriedBecause I think that whole architecture may be in flux13:28
efriedand we want to make sure that when it stabilizes, it does so in a way that's actually useful for us.13:28
efriedJust spitballin here, but...13:30
edmondswagree with all of that13:30
thorstefried: probability of something for queens is low, medium or?13:31
thorsteh, doesn't need an answer13:33
thorstlets just do the reviews and do our best  :)13:33
edmondswyeah, too early to answer that I think13:33
thorstnext topic/13:34
esberglu#topic Open Discussion13:35
edmondsw#topic Open Discussion13:35
esbergluthorst: You want to abandon 4707?13:35
esbergluI'm gonna come back to that at some point, but I don't think that will be the final solution13:35
edmondswesberglu is there anything on the TODO list for that?13:36
thorstesberglu: done13:36
esbergluedmondsw: I'll add it if not13:36
thorstjust a FYI that I'm still planning to do a VIF overhaul13:37
edmondswprobably there, just didn't ring a bell for me13:37
edmondswthorst can you add that to https://etherpad.openstack.org/p/powervm-in-tree-todos13:37
thorstyep yep13:37
esbergluAnything else before I call it?13:39
edmondswcall it13:40
openstackMeeting ended Tue Jul 18 13:40:34 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:40
openstackMinutes:        http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.html13:40
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.txt13:40
openstackLog:            http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2017/powervm_driver_meeting.2017-07-18-13.03.log.html13:40
*** smatzek has quit IRC13:40
efriedSo thorst edmondsw A bit more on the PCI thing.13:42
efriedI'm wondering if it would be reasonable for us to suggest the following basic architecture for nova:13:42
efried1) 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
efried2) 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 IRC13:45
edmondswefried does that work if your environment uses multiple drivers, and some support #2 but some need to use whitelisting?13:46
efriedmultiple drivers on the same compute host??13:46
edmondswno, different hosts13:46
edmondswoh, the whitelisting is on the host... so yeah, that should work, I think13:47
efriedOh, that ought to be fine, I would have thought.  Perhaps I'm misunderstanding the question.13:47
edmondswsorry, you are much more familiar with how things work today than I am :)13:47
efriedI doubt that.13:47
efriedA year ago, maybe.13:47
efriedI've slept since then.13:47
efriedAnyway, 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
edmondswI think that makes sense. I'd say run it by pipes and see what he thinks.13:48
efriededmondsw Yeah, will do.  Want to get a bit more familiar with the code and the resource stuff first.13:49
edmondswefried 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
efriededmondsw 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
edmondswwould the driver have it's own whitelist of some kind?13:51
edmondswefried the review I'm thinking of seemed like a parallel effort, not something really in conflict with what we want13:52
efriedThe 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 files13:52
edmondswsure, I get that we don't want nova doing that, we want the driver doing that...13:52
edmondswbut the driver would need its own whitelisting mechanism, correct?13:53
efriededmondsw 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
efriededmondsw So the driver's concept of whitelisting isn't really the same as what goes in the conf.13:54
*** jay1_ has quit IRC13:54
efriedBecause the former doesn't allow the operator control, except via the latter.13:54
edmondsweven if we do get what we want, we need those blueprints to fit with what we do13:54
efriededmondsw Yes13:54
edmondswthe former doesn't... ?13:55
efriedI should probably have said admin, not operator, though the distinction is still fuzzy to me.13:56
efriedThe 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
efriedThe admin wants to be able to control which devices are allowed to be deployed on VMs.13:57
efriedAnd set it up in such a way that the operator can use them, but not control that list.13:57
efriedThat's the whitelist.13:57
edmondswthe guy who writes the conf is the operator13:57
edmondswthe guy who does the deploy... call him user13:57
efriedOkay, soit.13:57
edmondswefried I think we're in agreement...13:58
efriedSo 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
edmondswstill need a whitelist, but it will just be different from the current whitelist (driver-run instead of nova-run)13:58
efriedWell, 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
edmondswI think that's what I said, no?13:59
edmondsware you still using operator to mean the person that does a deploy (user)?14:00
*** esberglu has joined #openstack-powervm14:00
edmondswin openstack parlance, operator is the person that sets up and administers the cloud14:00
efriedNo, we switched to operator-owns-conf, user-does-deploys.14:00
edmondswk good14:00
efriedIt'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
edmondswso yes, the guy who does the conf needs to create the whitelist14:00
*** smatzek has joined #openstack-powervm14:00
edmondswefried yep, agreed14:00
efriedSo we have two options.14:01
efriedEither 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
efriedOr we make the existing pci.passthrough_whitelist actually be usable by powervm, which it basically ain't today.14:02
efriedAnd that second thing is where I thought a couple of those blueprints could come into play.14:02
efriedBasically, 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
efriedWe can make those names correspond to device IDs that make sense to our REST API (think like DRC names)14:05
efriedThe operator populates the whitelist based on the output of some kind of `pvmctl pci list` or whatever.14:05
efriedAnd we could use "tags" to designate switches/fabrics/ports/whatever for things (like SR-IOV) that aren't generic (like GPUs).14:07
efriedBut that info seems like it would be more appropriate for the other side - the get_inventory() side.14:07
edmondswefried I suspect we'll need driver-specific whitelisting formats, and so be unable to have drivers use pci.passthrough_whitelist... but we could try14:07
efriededmondsw 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
edmondswmaybe allowing drivers to add driver-specific options to that pci conf section in addition to standard options14:08
efriedNothing stopping us from registering options in the [pci] section.14:09
efriedBut it would have to start with an option that nova proper understands that lets us say "don't use pci.passthrough_whitelist".14:09
edmondswefried well, except that you have to be careful not to name them in a way that could conflict with another driver14:09
efriedyahyah, but that gets caught immediately.14:09
efriedThe driver won't start if you try to register something with a name conflict.14:10
efriedback in 10.14:10
edmondswefried 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-powervm14:32
efriededmondsw Yes, or put them in the [powervm] section.14:44
*** tjakobs has joined #openstack-powervm14:48
openstackgerritMerged openstack/ceilometer-powervm master: Updated from global requirements  https://review.openstack.org/47791715:02
openstackgerritMerged openstack/networking-powervm master: Updated from global requirements  https://review.openstack.org/47797615:11
openstackgerritTaylor Jakobson proposed openstack/nova-powervm master: Add support for ceph volumes  https://review.openstack.org/48447815:20
*** k0da has quit IRC15:31
*** jay1_ has quit IRC15:33
*** jay1_ has joined #openstack-powervm15:46
*** smatzek has quit IRC16:00
*** smatzek has joined #openstack-powervm16:02
*** smatzek has quit IRC17:02
*** smatzek has joined #openstack-powervm17:11
*** smatzek has quit IRC17:15
*** smatzek has joined #openstack-powervm17:15
*** chhavi has quit IRC18:17
*** jay1_ has quit IRC18:17
*** k0da has joined #openstack-powervm19:54
*** smatzek has quit IRC20:06
*** esberglu has quit IRC20:31
edmondswesberglu 5571 is still WIP, right?20:31
edmondswremove that from the commit message when you want a real review, but looks ok so far20:32
*** esberglu has joined #openstack-powervm20:44
*** esberglu has quit IRC20:44
*** esberglu has joined #openstack-powervm20:44
*** svenkat has quit IRC21:02
*** apearson has quit IRC21:16
*** thorst has quit IRC21:30
*** svenkat has joined #openstack-powervm21:35
*** thorst has joined #openstack-powervm21:42
*** thorst has quit IRC21:44
*** svenkat has quit IRC21:49
edmondswesberglu 5571 is still WIP, right? remove that from the commit message when you want a real review, but looks ok so far22:04
edmondswefried what are your thoughts on my latest comments in https://review.openstack.org/#/c/467599 ?22:05
efriededmondsw Haven't looked yet.22:05
edmondswefried yeah, I just added them :) Look when you get a chance22:05
efriededmondsw Oh, that happened in the last hour.  Yeah, tomorrow probably.22:05
esbergluedmondsw: Yep still WIP22:16
*** kylek3h has quit IRC22:23
*** miltonm has quit IRC22:41
*** edmondsw has quit IRC22:47
*** jwcroppe has quit IRC23:00
*** jwcroppe has joined #openstack-powervm23:01
*** jwcroppe_ has joined #openstack-powervm23:03
*** thorst has joined #openstack-powervm23:04
*** jwcroppe has quit IRC23:05
*** thorst has quit IRC23:06
*** k0da has quit IRC23:12
*** tjakobs has quit IRC23:17
*** esberglu has quit IRC23:36
*** jwcroppe_ has quit IRC23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!