Wednesday, 2016-12-07

*** lamt has quit IRC00:14
*** tovin07 has joined #openstack-meeting-cp00:52
*** lamt has joined #openstack-meeting-cp01:11
*** zhurong has joined #openstack-meeting-cp01:14
*** zhurong has quit IRC01:25
*** zhurong has joined #openstack-meeting-cp01:26
*** david-lyle has joined #openstack-meeting-cp01:33
*** zhurong has quit IRC01:34
*** zhurong has joined #openstack-meeting-cp01:35
*** mars has joined #openstack-meeting-cp01:50
*** hogepodge has quit IRC02:38
*** prateek has joined #openstack-meeting-cp03:22
*** prateek has quit IRC03:32
*** zhurong has quit IRC04:27
*** Rocky_g has quit IRC04:45
*** jamespage has quit IRC05:02
*** jamespag` has joined #openstack-meeting-cp05:03
*** ameade_ has joined #openstack-meeting-cp05:14
*** ameade has quit IRC05:14
*** lbragstad has quit IRC05:14
*** mgagne has quit IRC05:15
*** sballe_ has quit IRC05:15
*** dirk has quit IRC05:15
*** samueldmq_ has joined #openstack-meeting-cp05:15
*** DuncanT_ has joined #openstack-meeting-cp05:15
*** ildikov has quit IRC05:15
*** DuncanT has quit IRC05:15
*** ildikov has joined #openstack-meeting-cp05:16
*** DuncanT_ is now known as DuncanT05:16
*** samueldmq has quit IRC05:16
*** ameade_ is now known as ameade05:16
*** samueldmq_ is now known as samueldmq05:17
*** coolsvap has joined #openstack-meeting-cp05:19
*** dirk has joined #openstack-meeting-cp05:19
*** lbragstad has joined #openstack-meeting-cp05:20
*** prateek has joined #openstack-meeting-cp05:20
*** sballe_ has joined #openstack-meeting-cp05:22
*** zhurong has joined #openstack-meeting-cp05:27
*** zhurong has quit IRC05:30
*** zhurong has joined #openstack-meeting-cp05:31
*** prateek has quit IRC05:51
*** markvoelker has quit IRC06:05
*** markvoelker has joined #openstack-meeting-cp06:05
*** prateek has joined #openstack-meeting-cp06:06
*** markvoelker has quit IRC06:10
*** jgriffith is now known as jgriffith_away06:39
*** zhurong has quit IRC07:01
*** zhurong has joined #openstack-meeting-cp07:02
*** markvoelker has joined #openstack-meeting-cp07:06
*** markvoelker has quit IRC07:10
*** tovin07_ has joined #openstack-meeting-cp07:25
*** zhurong has quit IRC08:00
*** zhurong has joined #openstack-meeting-cp08:01
*** mars has quit IRC08:02
*** mars has joined #openstack-meeting-cp08:02
*** markvoelker has joined #openstack-meeting-cp08:07
*** markvoelker has quit IRC08:11
*** Rocky_g has joined #openstack-meeting-cp08:36
*** Rocky_g has quit IRC08:38
*** Rocky_g has joined #openstack-meeting-cp08:38
*** Rocky__ has joined #openstack-meeting-cp08:39
*** Rocky__ has quit IRC08:39
*** Rocky_g has quit IRC08:42
*** Rocky_g has joined #openstack-meeting-cp08:42
*** Rocky_g has quit IRC08:46
*** Rocky_g has joined #openstack-meeting-cp08:47
*** Rocky_g has quit IRC08:48
*** Rockyg has quit IRC08:49
*** Rockyg has joined #openstack-meeting-cp08:50
*** MarkBaker has quit IRC08:56
*** MarkBaker has joined #openstack-meeting-cp08:59
*** garloff has joined #openstack-meeting-cp09:06
*** markvoelker has joined #openstack-meeting-cp09:07
*** markvoelker has quit IRC09:12
*** cartik has joined #openstack-meeting-cp09:33
*** tovin07_ has quit IRC10:02
*** zhurong has quit IRC10:03
*** markvoelker has joined #openstack-meeting-cp10:08
*** markvoelker has quit IRC10:13
*** mars has quit IRC10:19
*** DuncanT has quit IRC10:33
*** DuncanT has joined #openstack-meeting-cp10:33
*** david-lyle_ has joined #openstack-meeting-cp10:35
*** david-lyle has quit IRC10:37
*** cartik has quit IRC10:43
*** mgagne has joined #openstack-meeting-cp10:47
*** mgagne is now known as Guest261510:47
*** ildikov has quit IRC11:00
*** ildikov has joined #openstack-meeting-cp11:00
*** sdague has joined #openstack-meeting-cp11:08
*** igormarnat_ has quit IRC11:22
*** igormarnat_ has joined #openstack-meeting-cp11:22
*** asingh_ has quit IRC11:26
*** asingh_ has joined #openstack-meeting-cp11:26
*** markvoelker has joined #openstack-meeting-cp12:09
*** markvoelker has quit IRC12:15
*** prateek has quit IRC12:19
*** mars has joined #openstack-meeting-cp12:21
*** lamt has quit IRC13:01
*** markvoelker has joined #openstack-meeting-cp13:12
*** markvoelker has quit IRC13:16
*** markvoelker has joined #openstack-meeting-cp13:19
*** lamt has joined #openstack-meeting-cp13:41
*** Guest2615 is now known as mgagne13:54
*** mgagne has quit IRC13:54
*** mgagne has joined #openstack-meeting-cp13:54
*** prateek has joined #openstack-meeting-cp14:03
*** lamt has quit IRC14:03
*** lamt has joined #openstack-meeting-cp14:06
*** prateek_ has joined #openstack-meeting-cp14:06
*** prateek has quit IRC14:08
*** parora has joined #openstack-meeting-cp14:17
*** prateek_ has quit IRC14:19
*** prateek has joined #openstack-meeting-cp14:19
*** parora has quit IRC14:22
*** coolsvap has quit IRC14:27
*** prateek_ has joined #openstack-meeting-cp14:29
*** prateek has quit IRC14:30
*** gouthamr has joined #openstack-meeting-cp14:37
*** parora has joined #openstack-meeting-cp14:39
*** prateek_ has quit IRC14:42
*** prateek_ has joined #openstack-meeting-cp14:43
*** zhipengh has joined #openstack-meeting-cp14:45
*** parora has quit IRC14:47
*** skazi_ has joined #openstack-meeting-cp14:49
*** jamespag` is now known as jamespage14:53
*** tongli has joined #openstack-meeting-cp14:53
Rockyghey15:00
topolHi15:01
markvoelkero/15:01
topol#startmeeting interop_challenge15:01
openstackMeeting started Wed Dec  7 15:01:16 2016 UTC and is due to finish in 60 minutes.  The chair is topol. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
tonglio/15:01
*** openstack changes topic to " (Meeting topic: interop_challenge)"15:01
openstackThe meeting name has been set to 'interop_challenge'15:01
Rockygo/15:01
MarkBakero/15:01
skazi_o/15:01
topolHi everyone, who is here for the interop challenge meeting today?15:01
topolThe agenda for today can be found at:15:01
topol#link https://etherpad.openstack.org/p/interop-challenge-meeting-2016-12-0715:01
topolWe can use this same etherpad to take notes15:01
zhipengho/15:02
topol#topic review action items from previous meeting15:02
*** openstack changes topic to "review action items from previous meeting (Meeting topic: interop_challenge)"15:02
topol#link http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-11-30-15.00.html15:02
luzCo/15:02
topolall, please use #link https://etherpad.openstack.org/p/interop-challenge-postmortem for lessons learned doc and add content15:02
topolSo did anyone add some content here?15:03
topolI know its hard to find time to do this but please do your best.15:03
* markvoelker added some a while bc15:03
markvoelker*back15:03
topolcool15:03
RockygDo you feel like an old school marm, topol?15:03
topolI'll give it until next meeting and we can then all look at it together :-)15:04
topolRockyg I taught a class or two way back when...15:04
RockygChiding the recalcitrant children ;-)15:04
topoldinosaurs roamed the earth15:04
RockygOh, I can imagine it...15:04
topolSo hopefully everyone saw we got our repo! YAY!15:05
topolwhich brings us to15:05
topoltongli to migrate doc to repo when ready15:05
tonglishould we reformat that etherpad into a lessonslearned.rst in our repo?15:05
topolIm taking tongli to a fancy lunch today so no guilt on harassing him on todos!15:06
tongliour repo is ready and ansible and terraform scripts all have been migrated over.15:06
topoltongli I think so!15:06
markvoelkerseems like we have enough content to make a start15:06
tongliwe have a doc directory where I think we should start using the folder for docs like this.15:06
tongli@markvoelker, @topol. cool.15:06
tongliI will take a first stab and put up a patch set.15:06
tonglifor the doc, then we can review and add more stuff over the time.15:07
*** mpaolino_ has joined #openstack-meeting-cp15:07
topolOk, so folks let's not add any more content to the etherpad version. Let's let tongli push a patch with an rst15:07
*** gema has joined #openstack-meeting-cp15:07
topol#action tongli to push the our postmortem doc as a patch to the new repo!15:08
gemao/15:08
*** rarcea has joined #openstack-meeting-cp15:08
* gema is at a sprint, sorry for the delay15:08
topoltongli hopefully you are finding reviews are getting done quicker.15:08
tonglitotally, day and night.15:08
*** moshele has joined #openstack-meeting-cp15:08
Rockygyay!15:08
tonglithanks to all the reviewers.15:08
RockygThat's the  important part15:08
*** edand has joined #openstack-meeting-cp15:09
topolBTW,  are we using standard OpenStack core reviewer rules?  need two reviews from other than the author to +2 before someone can +A15:09
topoland not all reviewers from the same company as the author15:09
topoleveryone okay with those?15:09
markvoelkersure15:10
luzCyes15:10
tongli@topol, we should. yes.15:10
Rockygyup15:10
topol#agree Standard OpenStack core reviewing guidelines are in effect for the new interop repo15:10
*** mpaolino_ has left #openstack-meeting-cp15:10
topolnext item15:10
topolmarkvoelker to review user survey to look for more possible work items to add to doodle poll15:11
topolmarkvoelker any luck?15:11
markvoelkerYeah, I took a look around.15:11
topolany gold nuggets?15:11
markvoelkerWe already had some container and NFV stuff on our list15:11
topolK15:11
markvoelkerOther than that, some other areas of interest included:15:11
markvoelkerbare metal (probably not a good candidate on account of how few clouds support it)15:12
topolgood point :-)15:12
markvoelkerhybrid cloud (this is something we might be able to showcase partly through tooling...e.g. can part of a workload run on OpenStack and part on something else, or parts on two different openstack clouds, etc)15:12
tongli@markvoelker, I would love to try some of bare metal, bringing ironic in the picture.15:12
markvoelkerPaaS (we mentioned CloudFoundry already)15:12
markvoelkerIoT (this could be done mostly as "the app that rides on top of OS"...e.g. maybe we spin up a ZettaJS service or something)15:13
tongliyeah, I like that as well. all openstack clouds or openstack and microsoft or aws?15:13
topoltongli you could try bare metal as an incubator to investigate15:13
markvoelkerAnd finally hardware accelerators, whcih again may not be a real good candidate15:13
Rockygfederation....but usually that's not a tenant cloud-tenant cloud thing15:13
Rockygi.e. multicloud15:14
tongliamong these 3, I think hybrid sounds sexy.15:14
topolsounds like a lot of stuff we could add to the doodle poll15:14
tongliok, multicloud == hybrid?15:14
markvoelkerI'd probably say hybrid and IoT are viable options for the doodle poll.  We'd probably want to flesh them out a bit though, particularly hybrid.15:15
Rockygkinda.  but openstack to openstack other vendor15:15
Rockygand usually geo location spaced15:16
tonglinot sure if OS + AWS (or Microsoft) is an option.15:17
zhipenghIoT is a little bit too broad15:17
topolwe need to have some we for sure can complete during the upcoming cycle15:17
tongli@zhipengh, right. need a bit more specific.15:17
MarkBakertongli using Juju we can deploy to OS + AWS15:18
tongliand it needs to be attractive as well.15:18
Rockygthat would be cool.15:18
zhipenghi think play with oak-tree and tricircle for multi-cloud, could be attractive :P15:19
topolMy guess is we should have one that we all start with first that is pretty solid. and at the same time have others as incubators where individual folks could investigate those15:19
topoldoes that make sense?15:19
Rockygthat too ;-)  but oaktree is just starting, so not sure this cycle would work for that.15:20
topolSo if someone is excited about IOT or bare metal I dont want to stop them even they might take some time to bake15:20
topolor oak-tree for that matter15:21
*** bastafidli has joined #openstack-meeting-cp15:21
tongliyeah, get it done in two cycles if need more time.15:21
Rockyg++15:21
tonglioak-tree is based on shade.15:22
topolso even if the doodle poll doesnt come back with your favorite feel free to do it as an incubator. I think we need to start with one that we feel we can all do15:22
tongliif we do not like shade, why should we like oak-tree?15:22
topolI like shade :-)15:22
tongliI thought someone has asked to fall back to OS Rest APIs.15:22
tongli@topol, I know, just saying that there are people seem really dislike shade.15:23
tongliif oak-tree is built on top of shade, would it be even worse?15:23
topolI think shade is covering up some uglies that people wish were fixed15:23
topoloak-tree just is like shae but allows you to bind to multiple languages besides python15:24
tongli@topol, I am just very skeptical about oak-tree. that is what I am trying to say.15:24
Rockyg++  arch wg is going to try to shine some light on that.  anyone interested, come and join the fun15:24
topoltongli, its like everything else.  feel free to doubt until the code talks :-)15:24
tonglihaha, yeah.15:24
topolI would view it as an incubator option15:25
tongliok, we got a quite big candidates pool now, I think.15:25
topolso let's review the candidate pool.15:25
tongli1. Cloud Foundry15:26
topolCloud Foundry, Kube, NFV, IOT, Bare Metal,15:26
tongli2. NFV15:26
tonglioh, ok.15:26
topolkeep going tongli15:26
topolyour way better15:26
tonglihybrid/multi-cloud15:26
tongliok.15:26
tongli1. Cloud Foundry15:26
tongli2. NFV15:26
tongli3. Kubernetes15:27
Rockygneed #info15:27
tongli4. Hybrid/multi-cloud15:27
tongli5. IOT15:27
tongli6. Bare Metal (or this should be a small piece of a larger workload)15:27
topoltongli I think you are being asked to put #info before each option15:27
tonglispecifics of each?15:28
Rockyg++ but I think this is liely good enough to start15:28
tonglitrying to give a list to @markvoelker for his doodle pool.15:29
topolso my question for things like IoT and Bare Metal, how close are we to having automated workloads15:29
tongli@topol, not close in my view.15:30
topolIdeally we pick something where we think we can get to having automated scripts for everyone to try in a few weeks15:30
Rockygagreed15:30
topolotherwise the options should be placed in incubator15:31
skazi_are we talking about real baremetal here or some simulated stuff (e.g. pxe-ssh)?15:31
topolskazi_ good question15:31
topolI dont even know15:31
markvoelkerIMO baremetal is going to rule out a lot of clouds that don't run ironic.  But I'll let my voting in the doodle poll reflect that opinion. =)15:32
tongli@markvoelker, yes. let the pool decide.15:32
skazi_mixing baremetal and VMs in one cloud is a tricky subject itself15:32
topolyes but if the poll picks something have the clouds cant support we are dead on arrival15:32
topolerr half the clouds15:33
tongliso what the goal should be?15:33
topolpoll is good for seeing what is most popular, but there maybe pragmatics we have to deal with15:33
topolgoal should be a workload we think at least has a chance of running on all the clouds15:34
skazi_tongli: what happened to the dockerswarm? is this still on the table?15:34
tongli@skazi_, great question.15:34
tonglishould we expand on that?15:34
topolif we pick something we know immediately cannot run on half the workloads that does not seem intersting15:35
tonglilet's add dockerswarm back to the list, @markvoelker,15:35
topolagreed. good point15:35
topolmy guess is bare metal perhaps should be incubator if it simply cant run on several clouds. It's like how we chose not to do Heat in the first round15:36
tongli@topol, agreed.15:36
topolBesides bare metal are there any that also seem like they could not be done by everyone?15:36
markvoelkerJust from memory: as of the April user survey less than a quarter of respondants were running ironic, and less than 10% in production.15:37
markvoelkerHardware accelerators might also be problematic15:37
topolLets keep bare metal and hardware accelerators off the doodle poll15:37
*** spilla has joined #openstack-meeting-cp15:37
topolMake sense?15:37
*** moshele has quit IRC15:37
Rockyg++15:38
topolfeel free to individually play around on those as incubators.15:38
topolfor those interested15:38
topolfor the rest of the the items is there any a particular person feels could theoretically be done on their cloud?15:39
topolerr could not be done on their cloud15:39
skazi_maybe we could combine couple of those options? e.g. kubernetes based pool of "simulated" IoT devices (agents) reporting some stats to central database cluster (InfluxDB+grafana)?15:40
topolskazi_ that may be possible15:40
topoldepends how good our skills are15:40
skazi_topol: as always :)15:41
Rockygoooh, we could do a ddos from hacked iot devices....15:41
topolHow about we go ahead with the doodle poll and see what shakes out from that and then evaluate as  a group15:42
markvoelkeryeah, I don't think these are all mutually exclusive.  I think the poll just tells us primary focus areas vs secondary.15:42
skazi_Rockyg: +1 :)15:42
tongliwe need to make a decision before Christmas.15:42
topolalso who will the poll be open to?15:42
tongliif we continue discussion, we may not be able to complete a nice workload for next summit.15:42
topolanyone in the community? Just us?15:42
topoltongli I agree we should get the poll out, and quickly after evaluate and make a decision15:43
markvoelkerIt's a nonbinding poll, so I was just figuring we'd send it to the ML per the norm15:43
topolmarkvoelker. that works15:43
tongli@markvoelker, that is right. pick a direction, and pieces here and there to make it useful and nice.15:43
*** diablo_rojo has joined #openstack-meeting-cp15:43
tonglione can vote multiple times?15:44
topolso who wants to create the poll?  Is that on tong and brad after we goto cheesecake factory today?15:44
tongliif that is the case, it is not good.15:44
topoltongli honor system?15:44
tonglisure.15:44
topoldo we need a concord poll?15:44
topolmarkvoelker what do folks typically use for these things?15:45
topoldoodle?15:45
markvoelkerdoodle usually works fine.  I don't expect it to be complicted.  If you guys are going to be in a food coma I can take care of it this afternoon. =p15:46
RockygNah.  doodle good enough.  But, need to advertise on multiple mls15:46
topolHa Ha. markvoelker. sure. its all yours15:46
tongli@markvoelker, please.15:47
topol#action markvoelker to create doodle poll and post to ML.15:47
topolTHANKS markvoelker15:47
topolk, next item15:47
*** ayoung has joined #openstack-meeting-cp15:47
tonglimeeting channels?15:48
RockygYeah.15:48
topolgema ask openstack-interop if we can use the channel and check with infra if it is ok to hold meetings in a non-meeting channel, otherwise go for own channel openstack-workloads15:48
topol    Rockyg to ask ttx if we can grab #openstack-meeting at this timeslot15:48
topolgema had a crit sit to go work but said she briefed some of you15:48
RockygSo, #openstack meeting is only available every other week.15:48
* markvoelker notes that there is currently a thread going about creating a new meeting channel15:48
RockygIn fact, our ask got a mail thread going about another meeting channel or meeting in group channels15:49
topolshould we try and wait and grab this slot on the new channel?15:49
markvoelker#info thread proposing to create #openstack-meeting-5 http://lists.openstack.org/pipermail/openstack-dev/2016-December/108604.html15:49
RockygThe one issur *we* have is that we shift times twice yearly for DST15:49
topolI think we can squat in meeting-cp a little longer as long as we afent permanent15:49
Rockygeveryone else keeps the utc time15:49
topolarent permanent15:49
Rockygagree with that, too.15:50
*** hogepodge has joined #openstack-meeting-cp15:50
tonglihmmm, so should we stick to utc time?15:50
topolRockyg yeah that happens to me with the keystone meeting. for us with DST thats just life15:50
Rockygwe should consider squatting on a single time all year long, too.15:50
Rockygwe got offered 1600 utc, I think.15:51
tonglion openstack-meeting?15:51
RockygAnd there is time at 1200 utc, just not current time15:51
topolRockyg is that one hour later - 1600 utc?15:51
tongliif we can grab that time for utc1600 every week, I would call to change our time.15:51
RockygUh, not sure which room, but ironic freed up a time slot15:51
Rockyglemme double check....15:52
tongliutc1600 is 11:00am our time now, 10:00am DST.15:52
topolcan everyone meet at 1600 utc?15:52
tongliI think.15:52
topolI can make that work15:52
markvoelker1600UTC is the defcore committee timeslot, so if we keep it on wednesdays I'll be out15:52
topolthen its no good !15:52
topolwe need markvoelker15:53
tongliwho else will be doing the pool. no way.15:53
topolexactly tongli. we know where our doodle poll bread is buttered15:53
Rockygno, it was later in the day....15:53
markvoelkerKinda feels like the meeting channel discussion is close to being resolved...maybe we just table this discussion for one more week and see if our current time becomes available on a new channel?15:53
topolmarkvoelker that sounds good15:54
tongli@Rockyg, it should be 11:00am. ours is current UTC1500.15:54
topollet's wait and see what happens with the new meeting channel15:54
tongliwhich 10:00am EDT.15:54
tongliI would think utc1600 is 11:00am EDT.15:54
topol2 more quick items15:55
* markvoelker glances at the clock and notes that (speaking of the defcore/interopWG meeting) it starts in 5 minutes...15:55
Rockygit mighta been 1800...15:55
topolim gonna move quick folks15:55
tonglik. as long as we can use this channel, I am ok.15:55
topol#item PTG meeting15:55
topolare folks going? Tong Li and I will be going15:55
* markvoelker is planning to attend15:56
Rockygbut, yeah.  I'll post the actual options.  I think we could get 1400 now, but that's 6am out here15:56
topoldo we need to ask  for our own space there15:56
topol?15:56
markvoelkertopol: PTG space is mostly reserved for big tent teams, so it may be difficult to get space there.15:56
RockygYeha, I'll be there.15:56
topolhow much time at PTG do you all want to spend on interop?15:56
topolhopefully they have some flex space15:57
Rockygwe can always meet at a coffee shop, or better, over beers15:57
topolI can ask ttx15:57
topolso let's plan on meeting a little there15:57
tonglibig thanks to Christopher for setting up the new repo.15:57
topolbut folks can still focous on their primary areas15:58
Rockygyay aedo!15:58
topol#item new repo is up15:58
topolThanks caedo15:58
tongliansible and terraform workloads are all moved already.15:58
topolnew repo structure is in15:58
topolthanks tongli15:58
tonglinow need a bit discussion on tox.15:58
tongliwhich is enabled.15:58
tonglibut we can talk about that next time.15:58
topolwe only have 1 minute15:58
topolk15:58
topol perfect15:58
topol#action topol ask ttx about flex space15:59
topol#endmeeting15:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:59
openstackMeeting ended Wed Dec  7 15:59:28 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.log.html15:59
topolthanks every one15:59
Rockygthanks!15:59
tonglithanks.15:59
*** parora has joined #openstack-meeting-cp15:59
*** skazi_ has quit IRC16:00
lbragstadping  lbragstad, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung16:00
lbragstad#startmeeting policy16:00
openstackMeeting started Wed Dec  7 16:00:47 2016 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** edmondsw has joined #openstack-meeting-cp16:00
*** openstack changes topic to " (Meeting topic: policy)"16:00
openstackThe meeting name has been set to 'policy'16:00
*** zhipengh has left #openstack-meeting-cp16:00
dstaneko/16:00
rderoseo/16:00
lbragstado/16:01
edmondswo/16:01
ayoungYehaw16:01
*** prateek_ has quit IRC16:01
lamto/16:01
dolphm\o16:01
ayoungAgenda is here https://etherpad.openstack.org/p/keystone-policy-meeting16:01
*** prateek_ has joined #openstack-meeting-cp16:01
*** edand has left #openstack-meeting-cp16:02
marsIs cinder team meeting has began?16:02
ayoungmars, wrong room, this is policy16:02
*** jaugustine has joined #openstack-meeting-cp16:02
lbragstadmars looks like it has in #openstack-meeting16:02
marsthx16:03
lbragstadmars you're more than welcome to stay and help with policy though ;)16:03
lbragstadalright - #link https://etherpad.openstack.org/p/keystone-policy-meeting16:03
*** tongli has quit IRC16:03
lbragstadeven though ayoung dropped it earlier16:03
lbragstad#topic action items from last week16:04
*** openstack changes topic to "action items from last week (Meeting topic: policy)"16:04
ayoungdo we have any Other proposals for policy at this point?16:04
marsthx,but now i must to join in the cinder and ask some questions to my ptl16:04
*** parora has quit IRC16:04
lbragstadwe all had action items to review ayoung policy spec16:04
ayoungGot that on the Agenda for this week lbragstad but put it at the end16:05
lbragstadayoung yep - i see that16:05
edmondswI like the "Role Check Check" title ;)16:05
lbragstad#topic other proposals for policy16:06
*** openstack changes topic to "other proposals for policy (Meeting topic: policy)"16:06
ayoungedmondsw, I felt that "Role Check Check Check" had better rhythm, but was just too much16:06
edmondswlol16:06
lbragstadi wish ruan was here16:06
ayoungI can start to address his question, though, on what it would take16:06
lbragstadayoung  are you referencing the external PEP and PDP bits?16:07
ayoungyep16:07
lbragstadsure - go for it. we can get his opinion if he joins16:07
ayoungOK, so, lets start with the current state of how services call Oslo-policy16:08
ayoungthere is a project called oslo-context that essentially is the contract for the set of parameters that a service should use to call policy16:08
ayoungin order to call a remote PDP, we need a contract like that16:08
ayoungand the tricky part is "what attributes are we going to use to enforce policy"16:09
*** jgriffith_away is now known as jgriffith16:09
ayoungThe current approach mixes the oslo-context set (most Keystone token validation data in dictionary form) with some of the values from the service16:09
ayounglooking at the policy rules that Neutron does can show you some of the complexity16:09
dstanekdo we have a single point of truth for the usecases we are tackling and the endstate we desire? stevemar asked for this in one of the email threads16:10
ayoungI'd group it into 2 things, though, that the service needs to pass16:10
ayoungdstanek, can you hold that question for a moment?16:10
lbragstaddstanek i think that's a good starting point16:10
ayoung1.  is the scope of the resource: what project owns it, what user, and so forth16:10
ayoung2. is sharing criteria16:11
ayoungand if you look at neutron, it is 'is this a public network'  which is also mirrored in glance16:11
ayoungso, those are the use cases solved by policy today16:11
ayoungI don;t think we have a usecase document yet for the External PDP.  If there is, I have not seen it16:12
*** gagehugo has joined #openstack-meeting-cp16:12
ayoungHowever, Access Control is not a new concept16:12
lbragstadayoung let's just talk usecases in general16:12
lbragstadayoung you example highlights at least one16:12
ayoungand we should not need to invent them all from scratch.16:13
ayoungSo...let me define the central use case:16:13
lbragstad#topic use cases for policy16:13
*** openstack changes topic to "use cases for policy (Meeting topic: policy)"16:13
ayoung"allow a set of users access to some operation on a resource based on the roles they are assigned for a project"16:14
ayoungthat is the use case that policy today almost supports16:14
ayoungthe neutron glance use case is more like:16:14
*** bastafidli has quit IRC16:14
ayoung"allow a set of users access to some operation on a resource based on attributes of the resource"16:15
lbragstadtrue16:15
ayoungwhich builds on top of the core use case16:15
ayoungI would actually say the core use case as implemented by oslo policuy today is16:15
*** thinrichs has joined #openstack-meeting-cp16:16
ayoung"allow a set of users access to some operation on a resource based on whether they are assigned any role for a project"16:16
edmondswbreaking that down into subcases, you have 1) simple cases where the decision is based purely on role and resource type, 2) cases where user attributes come into play, 3) cases where resource attributes come into play16:16
ayoungand then the admin use case IS (but not what it should be)16:16
ayoung"allow a set of users access to some operation on a resource based on whether they are assigned the admin role on any project"16:16
ayoungand we are trying to change that to16:16
ayoung"allow a set of users access to some operation on a resource based on whether they are assigned the admin role on the admin project project"16:16
ayoungedmondsw, 1) also includes the resource scope16:17
ayoungwell...16:17
ayoungOK  lets define the admin use case this way16:17
lbragstadlet's consider admin is just a role16:17
ayoung"allow a set of users access to some operation on a resource based on whether they are considered a cloud administrator"16:18
lbragstadto me - that should fall into the first use case16:18
edmondswthe admin vs. everyone else distinction we have today is a factor of not having any default roles other than admin today... default policy can't refer to roles that don't exist16:18
ayoungedmondsw, so...that gets into the second to last item I have on the agenda16:18
lbragstadadmin shouldn't be anything special - it's just a role that maps to a set of operations16:18
ayounghttps://bugs.launchpad.net/keystone/+bug/96869616:19
openstackLaunchpad bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] - Assigned to Adam Young (ayoung)16:19
ayounglbragstad, not quite.  there are 2 types of admin-ness16:19
ayoung1 is do I have admin on this specific project16:19
ayoungbut the 0 level rule is16:19
edmondswlbragstad, I wish admin wasn't special. I would like to get there someday. We are a long way from that16:19
ayoungthis Operation is special.  I need admin on a special project (or projects..future work)16:20
lbragstadedmondsw agreed16:20
ayoungand, if I have admin on the special project, I can use that as an override for project scoped operations16:20
lbragstadedmondsw but ideally admin should just be a role that maps to a set of operations - right?16:20
ayounglbragstad, it is also and override16:20
dstanekfor my own sanity i'm starting to record this here: https://etherpad.openstack.org/p/keystone-policy-usecases16:20
ayoungadmin role on the admin project is a global admin, capable of fixing things for many other users16:20
ayoungdstanek, thanks16:21
lbragstaddstanek i started writing some down in the meeting but i'll port them to your etherpad16:21
edmondswlbragstad I think so... the issue may be with code needing to treat admins as special in ways that you don't want to be controllable via policy, leading to the continuation of the context_is_admin rules16:21
* dstanek really just wants to have as many of the usecase as possible first and then have a summary of end states for each solution second before he can accurately judge review proposals16:21
ayoungI want to use the term Member as opposed to user, if that is OK16:22
lbragstaddstanek ++16:22
edmondswdstanek ++16:22
ayoungWe did have jamielennox and dolphm 's attempt to set a basic set of roels that does address this16:22
ayounglet me find it16:22
lbragstadedmondsw right - i assume there are going to be usecases that don't quite match with the way things are currently - but that's fine, i'd like us to start from a ideal point16:23
edmondswlbragstad ++16:23
lbragstadif we were to start *all* over, how would this look?16:23
thinrichsIf it helps, Congress has a list of policy use cases.  Not all of them would necessarily be enforced at the API, but some of them are pretty concrete...16:24
thinrichshttps://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#heading=h.wvybnha031eu16:24
lbragstadwhich i think we'll have to take with a grain of salt when we compare those things to reality, but that's only going to further prove the areas we need to work on16:24
edmondswwe would have a global scope concept... i.e. you could assign a role to a user for a domain or a project OR globally16:24
ayoungdolphm, do you remember what it was called and who owned it?16:24
ayoungedmondsw, so that is what "admin_project" can now support16:25
edmondswadmin_project is a hack... lbragstad asked what we would do if we could do it all over again16:25
ayoungyou can write policy that says 'you have to have the admin role on the admin project" to be a global admin.  We could write more specified policy than that, too16:26
dolphmayoung: no?16:26
thinrichsMore use cases…(the ones implemented): https://docs.google.com/document/d/1w55wDighZvI9zKAtnO4jOfDMScmN7Qf5NHFtFdk8Sas/edit#heading=h.v7jiiyumrken16:26
ayoungedmondsw, it is not a hack.  It was the assumption upon which policy was written way back in the termie days,16:26
edmondswayoung I totally disagree16:27
ayoungedmondsw, yeah, well you are not the one that tried to change it and then got slammed by the operators...16:27
ayoungheh16:27
dstaneklbragstad: ++ having a vision without worrying about what we have is important. the reviews would be the baby steps to get us there16:27
ayoungbut, we need some way of saying "here is the global scope"16:27
ayoungI was originally hoping to implement it based on hierarchies but we ran into the HMT role inheritance, and, well, its hard16:28
dstanekayoung: root domain?16:28
ayoungdstanek, yes16:28
ayoungdstanek, and any role assigned on a level of the hierarchy would be valid all the way down.  However, I like the idea of "rescoping" and the operations absolutely did not want that16:29
ayoungthey are probably wrong16:29
dstanekcloud admin has admin role on root domain, domain admin has admin on any other domain and a project admin has admin on a project (i realize that domain/project admins are essentially the same)16:29
edmondswayoung I think you were looking for this a minute ago: https://review.openstack.org/#/c/274157/16:29
ayoungfrom a security standpoint, it is a frightening approach16:29
dstanekayoung: they didn't want rescoping?16:30
dstanekayoung: what is frightening?16:30
ayoungedmondsw, that was a subset, yes, but there was a more complete one.  It was jamielennox's I thouight16:30
edmondswayoung, right, that was just the first I found16:30
ayoungedmondsw, this was a cross-project spec16:30
ayoungbut I don't even know how to find those16:31
edmondswayoung https://review.openstack.org/#/c/245629/16:31
ayoungedmondsw, BINGO!16:31
ayoung#link https://review.openstack.org/#/c/245629/16:31
lbragstadhttps://specs.openstack.org/openstack/openstack-specs/16:32
lbragstad(published ones) ^16:32
ayoungSo the goal of that spec was to provide a set of roles that allowed for the above use case plus a few more16:32
ayoungObserver, as edmondsw just linked to is a big one16:32
edmondswthat's why I found it first :)16:32
ayoungthat is another one that people want with out scoping, and again, it scares me16:32
ayoungthe other is per-service admin16:33
ayoungso nova-admin can't mess up neutron and glance-admin can't touch keystone, etc16:33
ayoungso...lets skip the RBAC based use cases for the moment, as I will talk about them at the end16:33
ayoungthe other use case is this:16:34
ayoung"allow different levels of user access for a resources in a project"16:34
ayoungthat means that, in a single project, I might have vms that edmondsw can only view, and he might have ones that he can admin, but I can only view, etc16:35
ayoungthe typical way this use case is framed is based on VM ownership, at the user level, but that is not the only way it can be16:35
ayoungits a general concept, though, that the openstack model does not easily support16:36
ayoungright now, the level of abstraction is "project is the label used for access control"16:36
ayoungand in doing that, it mixes two things:16:36
ayoung1.  how do I list/create a set of objects16:36
ayoung2. how do I have access to these objects16:37
ayoungif you compare it with a unix file system, its like we force a one-to-one relationship between dentries and inodes16:37
ayoungIE.  we have not way of talking about the objects *outside* for the hierarchy used to organize them16:38
ayoungI don;t think this is something that we can easily fix, but it is one of the driving reasons people keep coming up with more complex policy schemes16:38
ayoungOK...enough lecturing from me.  Does all this (or any of it) make sense?16:38
dstanekayoung: i've long wanted to have access for a resource like 'identity:user_list' or a specific resource entity like 'identity:user_get:id=12345', which it sounds like this is allowing16:39
ayoungdstanek, well, yes, it does, but you need to store that info somewhere, and that is the problem16:39
ayoungit means that, for every resource, you need to have a shadow record in the remote PDP16:40
ayoungso, say you had an idea like, subnetwork-groups16:40
ayoungany you want to say that a subnet can be in one or more subnet groups16:40
ayoungand that access is going to be based on what subnet groups a user is enrolled in16:40
ayoungall that info has to be either in keystone, in neutron, or in the remote PDP16:41
edmondswdstanek coding the id like that probably wouldn't be practical... you need some some way of doing things more dynamically16:41
ayoungfor every user, for every subnet group, and for every subnet.16:41
edmondswdstanek e.g. owner_id=me where owner_id is an attribute of the resource stored by the relevant service16:41
dstanekayoung: edmondsw: i'm trying to tease out the usecase we care about. so specific entity isn't one of them?16:42
edmondswdstanek btw we don't have anything like owner_id today... some resources remember who created it, but that may or may not who you want to be responsible for it now, or you might want to share responsibility across a group of owners, etc.16:42
edmondswdstanek I don't think so16:42
thinrichsdstanek: I'd imagine we'd want specific entities but referenced by groups that are dynamically constructed16:43
dstanekedmondsw: can you add that to the etherpad? and anything else you are about being able to assign based on16:43
edmondswdstanek sure16:43
ayoungdstanek, I would argue that there are other was to implement what people want.  I think the use case, though, is that, for a complex setup, allow different access to resources of the same type based on *SOME* critera16:43
dstanek"this is my thing and i want to give Frank access to it" - is that a specific usecase?16:44
ayoungI would prefer to allow "mounting" an object from one project into a separate project, and have different access control rules based on which project the resource was accessed through16:44
thinrichsdstanek: I'd say so16:46
edmondswdstanek what I put in the pad make sense?16:46
lbragstadi thinks o16:46
edmondswdstanek "I want to grant Frank access"... wouldn't that get into trusts?16:47
edmondswayoung go on... I have a workitem to look at how you'd move a resource from one project to another, and some kind of mounting will probably be necessary as an interim step16:48
dstanekedmondsw: makes sense16:48
dstanekedmondsw: not sure because you could say that about most of what we are doing16:49
dstanekcloud admin (admin on root project) delegates admin on a project to Joe (a domain admin)....16:49
dstanekayoung: what an example of mounting?16:50
lbragstadlike checking the attributes of a server using Neutron?16:50
edmondswtime check: 10 minutes left16:50
lbragstadedmondsw thanks16:50
lbragstador are we talking about mounting as in take this VM and mount it on this other project?16:51
edmondswdstanek mounting example: I have a VM in project A, and I want to make that visible in project B as well16:51
ayoungok...let me cover my last two items, please?16:52
ayoungBug 968696 Work16:52
openstackbug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung)16:52
ayoungI need some help here.  Made some progress but...16:52
lbragstad#topic the infamous bug 96869616:53
*** openstack changes topic to "the infamous bug 968696 (Meeting topic: policy)"16:53
ayoungA little background:16:53
*** Kiall has quit IRC16:53
ayoungthis is the admin_project stuff edmondsw and I were discussing earlier16:53
ayoungwe need to add a rule to each of the policy files to check that field for admin-over ride16:53
*** Kiall has joined #openstack-meeting-cp16:53
ayoungand glance and cinder now pass16:53
edmondswayoung where do we stand on the nova patch we'd put up?16:53
ayoungbut..nova does not, and Keystone is a mess16:53
ayoungedmondsw, so I got the roll back on the devstack change that was getting in the way16:53
ayoungbut nova has a different gate job that seems to it via some other mechanism.16:54
edmondsw:)16:54
ayoungLInk in a sec...16:54
ayounghttps://review.openstack.org/#/c/384642/  is a successful one for comparison16:54
edmondswI am happy to try to help there when I can spare cycles16:54
ayounghttps://review.openstack.org/#/c/384148/  is the nova one16:54
ayoungso that has fewer failing jobs, but I think they are for the same reason"16:55
ayoungsomething is setting is_admin_project16:55
ayoungthere are also a handful of changes that keystone needs as prereq, but I can handle those16:55
ayoungedmondsw, if you could see the nova one on through, that would be the most help16:55
edmondswcan you point me to the devstack roll back for comparison?16:55
ayoungedmondsw, it was just a removal of setting is_admin_project by default...let me see...16:56
ayoungI'll do that later...one other thing first16:56
edmondswlater's fine16:56
ayoungI'll keep working on Keystone, but there are some refactorings that need to happen frist...16:56
ayounghttps://review.openstack.org/#/c/387161/  and16:57
ayounghttps://review.openstack.org/#/c/387710/16:57
ayoungplease review and move those along16:57
ayoungthose are prereqs for16:57
ayounghttps://review.openstack.org/#/c/257636/16:57
ayoungwhich I will rename to be consistent with the nova and glance reviews16:57
ayoungok last thing, rushed16:58
ayoungRBAC in m,iddleware16:58
lbragstad#topic rbac in middleware status16:58
*** openstack changes topic to "rbac in middleware status (Meeting topic: policy)"16:58
ayoungreview has 2 +2s, and some comments from lbragstad to address16:58
ayoungI think it is going to make it in to the "approved for Ocata" pile16:58
lbragstad#link https://review.openstack.org/#/c/391624/16:58
lbragstadayoung dstanek had a bunch of comments on patch set 11 that i attempted to port16:59
ayoungthis is a layer on top of policy, and should only be hardening, will not open new ways around16:59
ayounglbragstad, ++ and I will address16:59
ayoungis everyone comfortable with the approach?16:59
lbragstadi have a couple big concerns16:59
lbragstadi reviewed it last night16:59
ayoungperf, security, or other?16:59
lbragstadthe splitting of rbac into it's own check17:00
lbragstadwe're out of time17:00
lbragstadwe can continue in -keystone17:00
lbragstad#endmeeting17:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:00
openstackMeeting ended Wed Dec  7 17:00:28 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.html17:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.txt17:00
openstackLog:            http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.log.html17:00
edmondswI had a lot of concerns last I read, but I haven't read the latest yet... I think I can get to it tomorrow17:00
*** thinrichs has left #openstack-meeting-cp17:00
*** mars has quit IRC17:07
*** moshele has joined #openstack-meeting-cp17:09
*** moshele has quit IRC17:17
*** gagehugo has left #openstack-meeting-cp17:21
*** reed has quit IRC17:32
*** dhellmann has quit IRC17:33
*** gouthamr has quit IRC17:37
*** gouthamr has joined #openstack-meeting-cp17:39
*** spilla has left #openstack-meeting-cp17:55
*** dhellmann has joined #openstack-meeting-cp18:00
*** reed has joined #openstack-meeting-cp18:00
*** david-lyle_ is now known as david-lyle18:02
*** parora has joined #openstack-meeting-cp18:10
*** bastafidli has joined #openstack-meeting-cp18:12
*** prateek_ has quit IRC18:13
*** rarcea has quit IRC18:13
*** reed has quit IRC18:14
*** dhellmann has quit IRC18:15
*** prateek has joined #openstack-meeting-cp18:21
*** parora has quit IRC18:24
*** prateek has quit IRC18:43
*** garloff has quit IRC18:51
*** garloff has joined #openstack-meeting-cp18:51
*** bastafidli has quit IRC19:04
*** gouthamr has quit IRC19:30
*** gouthamr has joined #openstack-meeting-cp19:33
*** piet has joined #openstack-meeting-cp19:39
*** lamt has quit IRC19:49
*** dhellmann_ has joined #openstack-meeting-cp19:52
*** dhellmann_ is now known as dhellmann19:59
*** reed has joined #openstack-meeting-cp20:03
*** gouthamr has quit IRC20:32
*** harlowja has quit IRC20:41
*** edmondsw has quit IRC20:43
*** kbyrne has quit IRC20:43
*** kbyrne has joined #openstack-meeting-cp20:45
*** lamt has joined #openstack-meeting-cp20:47
*** xyang1 has joined #openstack-meeting-cp20:58
*** bastafidli has joined #openstack-meeting-cp21:05
*** bastafidli has quit IRC21:13
*** harlowja has joined #openstack-meeting-cp21:41
*** diablo_rojo has quit IRC22:04
*** itisha has joined #openstack-meeting-cp22:06
*** bastafidli has joined #openstack-meeting-cp22:09
*** diablo_rojo has joined #openstack-meeting-cp22:17
*** piet has quit IRC22:29
*** diablo_rojo has quit IRC22:33
*** ayoung has quit IRC22:48
*** lamt has quit IRC22:48
*** jaugustine has quit IRC22:50
*** piet has joined #openstack-meeting-cp23:11
*** harlowja has quit IRC23:16
*** bastafidli has quit IRC23:17
*** david-lyle_ has joined #openstack-meeting-cp23:20
*** david-lyle_ has quit IRC23:20
*** xyang1 has quit IRC23:22
*** piet has quit IRC23:41

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