*** lamt has quit IRC | 00:14 | |
*** tovin07 has joined #openstack-meeting-cp | 00:52 | |
*** lamt has joined #openstack-meeting-cp | 01:11 | |
*** zhurong has joined #openstack-meeting-cp | 01:14 | |
*** zhurong has quit IRC | 01:25 | |
*** zhurong has joined #openstack-meeting-cp | 01:26 | |
*** david-lyle has joined #openstack-meeting-cp | 01:33 | |
*** zhurong has quit IRC | 01:34 | |
*** zhurong has joined #openstack-meeting-cp | 01:35 | |
*** mars has joined #openstack-meeting-cp | 01:50 | |
*** hogepodge has quit IRC | 02:38 | |
*** prateek has joined #openstack-meeting-cp | 03:22 | |
*** prateek has quit IRC | 03:32 | |
*** zhurong has quit IRC | 04:27 | |
*** Rocky_g has quit IRC | 04:45 | |
*** jamespage has quit IRC | 05:02 | |
*** jamespag` has joined #openstack-meeting-cp | 05:03 | |
*** ameade_ has joined #openstack-meeting-cp | 05:14 | |
*** ameade has quit IRC | 05:14 | |
*** lbragstad has quit IRC | 05:14 | |
*** mgagne has quit IRC | 05:15 | |
*** sballe_ has quit IRC | 05:15 | |
*** dirk has quit IRC | 05:15 | |
*** samueldmq_ has joined #openstack-meeting-cp | 05:15 | |
*** DuncanT_ has joined #openstack-meeting-cp | 05:15 | |
*** ildikov has quit IRC | 05:15 | |
*** DuncanT has quit IRC | 05:15 | |
*** ildikov has joined #openstack-meeting-cp | 05:16 | |
*** DuncanT_ is now known as DuncanT | 05:16 | |
*** samueldmq has quit IRC | 05:16 | |
*** ameade_ is now known as ameade | 05:16 | |
*** samueldmq_ is now known as samueldmq | 05:17 | |
*** coolsvap has joined #openstack-meeting-cp | 05:19 | |
*** dirk has joined #openstack-meeting-cp | 05:19 | |
*** lbragstad has joined #openstack-meeting-cp | 05:20 | |
*** prateek has joined #openstack-meeting-cp | 05:20 | |
*** sballe_ has joined #openstack-meeting-cp | 05:22 | |
*** zhurong has joined #openstack-meeting-cp | 05:27 | |
*** zhurong has quit IRC | 05:30 | |
*** zhurong has joined #openstack-meeting-cp | 05:31 | |
*** prateek has quit IRC | 05:51 | |
*** markvoelker has quit IRC | 06:05 | |
*** markvoelker has joined #openstack-meeting-cp | 06:05 | |
*** prateek has joined #openstack-meeting-cp | 06:06 | |
*** markvoelker has quit IRC | 06:10 | |
*** jgriffith is now known as jgriffith_away | 06:39 | |
*** zhurong has quit IRC | 07:01 | |
*** zhurong has joined #openstack-meeting-cp | 07:02 | |
*** markvoelker has joined #openstack-meeting-cp | 07:06 | |
*** markvoelker has quit IRC | 07:10 | |
*** tovin07_ has joined #openstack-meeting-cp | 07:25 | |
*** zhurong has quit IRC | 08:00 | |
*** zhurong has joined #openstack-meeting-cp | 08:01 | |
*** mars has quit IRC | 08:02 | |
*** mars has joined #openstack-meeting-cp | 08:02 | |
*** markvoelker has joined #openstack-meeting-cp | 08:07 | |
*** markvoelker has quit IRC | 08:11 | |
*** Rocky_g has joined #openstack-meeting-cp | 08:36 | |
*** Rocky_g has quit IRC | 08:38 | |
*** Rocky_g has joined #openstack-meeting-cp | 08:38 | |
*** Rocky__ has joined #openstack-meeting-cp | 08:39 | |
*** Rocky__ has quit IRC | 08:39 | |
*** Rocky_g has quit IRC | 08:42 | |
*** Rocky_g has joined #openstack-meeting-cp | 08:42 | |
*** Rocky_g has quit IRC | 08:46 | |
*** Rocky_g has joined #openstack-meeting-cp | 08:47 | |
*** Rocky_g has quit IRC | 08:48 | |
*** Rockyg has quit IRC | 08:49 | |
*** Rockyg has joined #openstack-meeting-cp | 08:50 | |
*** MarkBaker has quit IRC | 08:56 | |
*** MarkBaker has joined #openstack-meeting-cp | 08:59 | |
*** garloff has joined #openstack-meeting-cp | 09:06 | |
*** markvoelker has joined #openstack-meeting-cp | 09:07 | |
*** markvoelker has quit IRC | 09:12 | |
*** cartik has joined #openstack-meeting-cp | 09:33 | |
*** tovin07_ has quit IRC | 10:02 | |
*** zhurong has quit IRC | 10:03 | |
*** markvoelker has joined #openstack-meeting-cp | 10:08 | |
*** markvoelker has quit IRC | 10:13 | |
*** mars has quit IRC | 10:19 | |
*** DuncanT has quit IRC | 10:33 | |
*** DuncanT has joined #openstack-meeting-cp | 10:33 | |
*** david-lyle_ has joined #openstack-meeting-cp | 10:35 | |
*** david-lyle has quit IRC | 10:37 | |
*** cartik has quit IRC | 10:43 | |
*** mgagne has joined #openstack-meeting-cp | 10:47 | |
*** mgagne is now known as Guest2615 | 10:47 | |
*** ildikov has quit IRC | 11:00 | |
*** ildikov has joined #openstack-meeting-cp | 11:00 | |
*** sdague has joined #openstack-meeting-cp | 11:08 | |
*** igormarnat_ has quit IRC | 11:22 | |
*** igormarnat_ has joined #openstack-meeting-cp | 11:22 | |
*** asingh_ has quit IRC | 11:26 | |
*** asingh_ has joined #openstack-meeting-cp | 11:26 | |
*** markvoelker has joined #openstack-meeting-cp | 12:09 | |
*** markvoelker has quit IRC | 12:15 | |
*** prateek has quit IRC | 12:19 | |
*** mars has joined #openstack-meeting-cp | 12:21 | |
*** lamt has quit IRC | 13:01 | |
*** markvoelker has joined #openstack-meeting-cp | 13:12 | |
*** markvoelker has quit IRC | 13:16 | |
*** markvoelker has joined #openstack-meeting-cp | 13:19 | |
*** lamt has joined #openstack-meeting-cp | 13:41 | |
*** Guest2615 is now known as mgagne | 13:54 | |
*** mgagne has quit IRC | 13:54 | |
*** mgagne has joined #openstack-meeting-cp | 13:54 | |
*** prateek has joined #openstack-meeting-cp | 14:03 | |
*** lamt has quit IRC | 14:03 | |
*** lamt has joined #openstack-meeting-cp | 14:06 | |
*** prateek_ has joined #openstack-meeting-cp | 14:06 | |
*** prateek has quit IRC | 14:08 | |
*** parora has joined #openstack-meeting-cp | 14:17 | |
*** prateek_ has quit IRC | 14:19 | |
*** prateek has joined #openstack-meeting-cp | 14:19 | |
*** parora has quit IRC | 14:22 | |
*** coolsvap has quit IRC | 14:27 | |
*** prateek_ has joined #openstack-meeting-cp | 14:29 | |
*** prateek has quit IRC | 14:30 | |
*** gouthamr has joined #openstack-meeting-cp | 14:37 | |
*** parora has joined #openstack-meeting-cp | 14:39 | |
*** prateek_ has quit IRC | 14:42 | |
*** prateek_ has joined #openstack-meeting-cp | 14:43 | |
*** zhipengh has joined #openstack-meeting-cp | 14:45 | |
*** parora has quit IRC | 14:47 | |
*** skazi_ has joined #openstack-meeting-cp | 14:49 | |
*** jamespag` is now known as jamespage | 14:53 | |
*** tongli has joined #openstack-meeting-cp | 14:53 | |
Rockyg | hey | 15:00 |
---|---|---|
topol | Hi | 15:01 |
markvoelker | o/ | 15:01 |
topol | #startmeeting interop_challenge | 15:01 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
tongli | o/ | 15:01 |
*** openstack changes topic to " (Meeting topic: interop_challenge)" | 15:01 | |
openstack | The meeting name has been set to 'interop_challenge' | 15:01 |
Rockyg | o/ | 15:01 |
MarkBaker | o/ | 15:01 |
skazi_ | o/ | 15:01 |
topol | Hi everyone, who is here for the interop challenge meeting today? | 15:01 |
topol | The agenda for today can be found at: | 15:01 |
topol | #link https://etherpad.openstack.org/p/interop-challenge-meeting-2016-12-07 | 15:01 |
topol | We can use this same etherpad to take notes | 15:01 |
zhipengh | o/ | 15:02 |
topol | #topic review action items from previous meeting | 15: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.html | 15:02 |
luzC | o/ | 15:02 |
topol | all, please use #link https://etherpad.openstack.org/p/interop-challenge-postmortem for lessons learned doc and add content | 15:02 |
topol | So did anyone add some content here? | 15:03 |
topol | I know its hard to find time to do this but please do your best. | 15:03 |
* markvoelker added some a while bc | 15:03 | |
markvoelker | *back | 15:03 |
topol | cool | 15:03 |
Rockyg | Do you feel like an old school marm, topol? | 15:03 |
topol | I'll give it until next meeting and we can then all look at it together :-) | 15:04 |
topol | Rockyg I taught a class or two way back when... | 15:04 |
Rockyg | Chiding the recalcitrant children ;-) | 15:04 |
topol | dinosaurs roamed the earth | 15:04 |
Rockyg | Oh, I can imagine it... | 15:04 |
topol | So hopefully everyone saw we got our repo! YAY! | 15:05 |
topol | which brings us to | 15:05 |
topol | tongli to migrate doc to repo when ready | 15:05 |
tongli | should we reformat that etherpad into a lessonslearned.rst in our repo? | 15:05 |
topol | Im taking tongli to a fancy lunch today so no guilt on harassing him on todos! | 15:06 |
tongli | our repo is ready and ansible and terraform scripts all have been migrated over. | 15:06 |
topol | tongli I think so! | 15:06 |
markvoelker | seems like we have enough content to make a start | 15:06 |
tongli | we 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 |
tongli | I will take a first stab and put up a patch set. | 15:06 |
tongli | for the doc, then we can review and add more stuff over the time. | 15:07 |
*** mpaolino_ has joined #openstack-meeting-cp | 15:07 | |
topol | Ok, so folks let's not add any more content to the etherpad version. Let's let tongli push a patch with an rst | 15:07 |
*** gema has joined #openstack-meeting-cp | 15:07 | |
topol | #action tongli to push the our postmortem doc as a patch to the new repo! | 15:08 |
gema | o/ | 15:08 |
*** rarcea has joined #openstack-meeting-cp | 15:08 | |
* gema is at a sprint, sorry for the delay | 15:08 | |
topol | tongli hopefully you are finding reviews are getting done quicker. | 15:08 |
tongli | totally, day and night. | 15:08 |
*** moshele has joined #openstack-meeting-cp | 15:08 | |
Rockyg | yay! | 15:08 |
tongli | thanks to all the reviewers. | 15:08 |
Rockyg | That's the important part | 15:08 |
*** edand has joined #openstack-meeting-cp | 15:09 | |
topol | BTW, are we using standard OpenStack core reviewer rules? need two reviews from other than the author to +2 before someone can +A | 15:09 |
topol | and not all reviewers from the same company as the author | 15:09 |
topol | everyone okay with those? | 15:09 |
markvoelker | sure | 15:10 |
luzC | yes | 15:10 |
tongli | @topol, we should. yes. | 15:10 |
Rockyg | yup | 15:10 |
topol | #agree Standard OpenStack core reviewing guidelines are in effect for the new interop repo | 15:10 |
*** mpaolino_ has left #openstack-meeting-cp | 15:10 | |
topol | next item | 15:10 |
topol | markvoelker to review user survey to look for more possible work items to add to doodle poll | 15:11 |
topol | markvoelker any luck? | 15:11 |
markvoelker | Yeah, I took a look around. | 15:11 |
topol | any gold nuggets? | 15:11 |
markvoelker | We already had some container and NFV stuff on our list | 15:11 |
topol | K | 15:11 |
markvoelker | Other than that, some other areas of interest included: | 15:11 |
markvoelker | bare metal (probably not a good candidate on account of how few clouds support it) | 15:12 |
topol | good point :-) | 15:12 |
markvoelker | hybrid 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 |
markvoelker | PaaS (we mentioned CloudFoundry already) | 15:12 |
markvoelker | IoT (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 |
tongli | yeah, I like that as well. all openstack clouds or openstack and microsoft or aws? | 15:13 |
topol | tongli you could try bare metal as an incubator to investigate | 15:13 |
markvoelker | And finally hardware accelerators, whcih again may not be a real good candidate | 15:13 |
Rockyg | federation....but usually that's not a tenant cloud-tenant cloud thing | 15:13 |
Rockyg | i.e. multicloud | 15:14 |
tongli | among these 3, I think hybrid sounds sexy. | 15:14 |
topol | sounds like a lot of stuff we could add to the doodle poll | 15:14 |
tongli | ok, multicloud == hybrid? | 15:14 |
markvoelker | I'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 |
Rockyg | kinda. but openstack to openstack other vendor | 15:15 |
Rockyg | and usually geo location spaced | 15:16 |
tongli | not sure if OS + AWS (or Microsoft) is an option. | 15:17 |
zhipengh | IoT is a little bit too broad | 15:17 |
topol | we need to have some we for sure can complete during the upcoming cycle | 15:17 |
tongli | @zhipengh, right. need a bit more specific. | 15:17 |
MarkBaker | tongli using Juju we can deploy to OS + AWS | 15:18 |
tongli | and it needs to be attractive as well. | 15:18 |
Rockyg | that would be cool. | 15:18 |
zhipengh | i think play with oak-tree and tricircle for multi-cloud, could be attractive :P | 15:19 |
topol | My 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 those | 15:19 |
topol | does that make sense? | 15:19 |
Rockyg | that too ;-) but oaktree is just starting, so not sure this cycle would work for that. | 15:20 |
topol | So if someone is excited about IOT or bare metal I dont want to stop them even they might take some time to bake | 15:20 |
topol | or oak-tree for that matter | 15:21 |
*** bastafidli has joined #openstack-meeting-cp | 15:21 | |
tongli | yeah, get it done in two cycles if need more time. | 15:21 |
Rockyg | ++ | 15:21 |
tongli | oak-tree is based on shade. | 15:22 |
topol | so 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 do | 15:22 |
tongli | if we do not like shade, why should we like oak-tree? | 15:22 |
topol | I like shade :-) | 15:22 |
tongli | I 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 |
tongli | if oak-tree is built on top of shade, would it be even worse? | 15:23 |
topol | I think shade is covering up some uglies that people wish were fixed | 15:23 |
topol | oak-tree just is like shae but allows you to bind to multiple languages besides python | 15: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 fun | 15:24 |
topol | tongli, its like everything else. feel free to doubt until the code talks :-) | 15:24 |
tongli | haha, yeah. | 15:24 |
topol | I would view it as an incubator option | 15:25 |
tongli | ok, we got a quite big candidates pool now, I think. | 15:25 |
topol | so let's review the candidate pool. | 15:25 |
tongli | 1. Cloud Foundry | 15:26 |
topol | Cloud Foundry, Kube, NFV, IOT, Bare Metal, | 15:26 |
tongli | 2. NFV | 15:26 |
tongli | oh, ok. | 15:26 |
topol | keep going tongli | 15:26 |
topol | your way better | 15:26 |
tongli | hybrid/multi-cloud | 15:26 |
tongli | ok. | 15:26 |
tongli | 1. Cloud Foundry | 15:26 |
tongli | 2. NFV | 15:26 |
tongli | 3. Kubernetes | 15:27 |
Rockyg | need #info | 15:27 |
tongli | 4. Hybrid/multi-cloud | 15:27 |
tongli | 5. IOT | 15:27 |
tongli | 6. Bare Metal (or this should be a small piece of a larger workload) | 15:27 |
topol | tongli I think you are being asked to put #info before each option | 15:27 |
tongli | specifics of each? | 15:28 |
Rockyg | ++ but I think this is liely good enough to start | 15:28 |
tongli | trying to give a list to @markvoelker for his doodle pool. | 15:29 |
topol | so my question for things like IoT and Bare Metal, how close are we to having automated workloads | 15:29 |
tongli | @topol, not close in my view. | 15:30 |
topol | Ideally we pick something where we think we can get to having automated scripts for everyone to try in a few weeks | 15:30 |
Rockyg | agreed | 15:30 |
topol | otherwise the options should be placed in incubator | 15:31 |
skazi_ | are we talking about real baremetal here or some simulated stuff (e.g. pxe-ssh)? | 15:31 |
topol | skazi_ good question | 15:31 |
topol | I dont even know | 15:31 |
markvoelker | IMO 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 itself | 15:32 |
topol | yes but if the poll picks something have the clouds cant support we are dead on arrival | 15:32 |
topol | err half the clouds | 15:33 |
tongli | so what the goal should be? | 15:33 |
topol | poll is good for seeing what is most popular, but there maybe pragmatics we have to deal with | 15:33 |
topol | goal should be a workload we think at least has a chance of running on all the clouds | 15:34 |
skazi_ | tongli: what happened to the dockerswarm? is this still on the table? | 15:34 |
tongli | @skazi_, great question. | 15:34 |
tongli | should we expand on that? | 15:34 |
topol | if we pick something we know immediately cannot run on half the workloads that does not seem intersting | 15:35 |
tongli | let's add dockerswarm back to the list, @markvoelker, | 15:35 |
topol | agreed. good point | 15:35 |
topol | my 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 round | 15:36 |
tongli | @topol, agreed. | 15:36 |
topol | Besides bare metal are there any that also seem like they could not be done by everyone? | 15:36 |
markvoelker | Just 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 |
markvoelker | Hardware accelerators might also be problematic | 15:37 |
topol | Lets keep bare metal and hardware accelerators off the doodle poll | 15:37 |
*** spilla has joined #openstack-meeting-cp | 15:37 | |
topol | Make sense? | 15:37 |
*** moshele has quit IRC | 15:37 | |
Rockyg | ++ | 15:38 |
topol | feel free to individually play around on those as incubators. | 15:38 |
topol | for those interested | 15:38 |
topol | for the rest of the the items is there any a particular person feels could theoretically be done on their cloud? | 15:39 |
topol | err could not be done on their cloud | 15: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 |
topol | skazi_ that may be possible | 15:40 |
topol | depends how good our skills are | 15:40 |
skazi_ | topol: as always :) | 15:41 |
Rockyg | oooh, we could do a ddos from hacked iot devices.... | 15:41 |
topol | How about we go ahead with the doodle poll and see what shakes out from that and then evaluate as a group | 15:42 |
markvoelker | yeah, 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 |
tongli | we need to make a decision before Christmas. | 15:42 |
topol | also who will the poll be open to? | 15:42 |
tongli | if we continue discussion, we may not be able to complete a nice workload for next summit. | 15:42 |
topol | anyone in the community? Just us? | 15:42 |
topol | tongli I agree we should get the poll out, and quickly after evaluate and make a decision | 15:43 |
markvoelker | It's a nonbinding poll, so I was just figuring we'd send it to the ML per the norm | 15:43 |
topol | markvoelker. that works | 15: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-cp | 15:43 | |
tongli | one can vote multiple times? | 15:44 |
topol | so who wants to create the poll? Is that on tong and brad after we goto cheesecake factory today? | 15:44 |
tongli | if that is the case, it is not good. | 15:44 |
topol | tongli honor system? | 15:44 |
tongli | sure. | 15:44 |
topol | do we need a concord poll? | 15:44 |
topol | markvoelker what do folks typically use for these things? | 15:45 |
topol | doodle? | 15:45 |
markvoelker | doodle 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. =p | 15:46 |
Rockyg | Nah. doodle good enough. But, need to advertise on multiple mls | 15:46 |
topol | Ha Ha. markvoelker. sure. its all yours | 15:46 |
tongli | @markvoelker, please. | 15:47 |
topol | #action markvoelker to create doodle poll and post to ML. | 15:47 |
topol | THANKS markvoelker | 15:47 |
topol | k, next item | 15:47 |
*** ayoung has joined #openstack-meeting-cp | 15:47 | |
tongli | meeting channels? | 15:48 |
Rockyg | Yeah. | 15:48 |
topol | gema 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-workloads | 15:48 |
topol | Rockyg to ask ttx if we can grab #openstack-meeting at this timeslot | 15:48 |
topol | gema had a crit sit to go work but said she briefed some of you | 15:48 |
Rockyg | So, #openstack meeting is only available every other week. | 15:48 |
* markvoelker notes that there is currently a thread going about creating a new meeting channel | 15:48 | |
Rockyg | In fact, our ask got a mail thread going about another meeting channel or meeting in group channels | 15:49 |
topol | should 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.html | 15:49 |
Rockyg | The one issur *we* have is that we shift times twice yearly for DST | 15:49 |
topol | I think we can squat in meeting-cp a little longer as long as we afent permanent | 15:49 |
Rockyg | everyone else keeps the utc time | 15:49 |
topol | arent permanent | 15:49 |
Rockyg | agree with that, too. | 15:50 |
*** hogepodge has joined #openstack-meeting-cp | 15:50 | |
tongli | hmmm, so should we stick to utc time? | 15:50 |
topol | Rockyg yeah that happens to me with the keystone meeting. for us with DST thats just life | 15:50 |
Rockyg | we should consider squatting on a single time all year long, too. | 15:50 |
Rockyg | we got offered 1600 utc, I think. | 15:51 |
tongli | on openstack-meeting? | 15:51 |
Rockyg | And there is time at 1200 utc, just not current time | 15:51 |
topol | Rockyg is that one hour later - 1600 utc? | 15:51 |
tongli | if we can grab that time for utc1600 every week, I would call to change our time. | 15:51 |
Rockyg | Uh, not sure which room, but ironic freed up a time slot | 15:51 |
Rockyg | lemme double check.... | 15:52 |
tongli | utc1600 is 11:00am our time now, 10:00am DST. | 15:52 |
topol | can everyone meet at 1600 utc? | 15:52 |
tongli | I think. | 15:52 |
topol | I can make that work | 15:52 |
markvoelker | 1600UTC is the defcore committee timeslot, so if we keep it on wednesdays I'll be out | 15:52 |
topol | then its no good ! | 15:52 |
topol | we need markvoelker | 15:53 |
tongli | who else will be doing the pool. no way. | 15:53 |
topol | exactly tongli. we know where our doodle poll bread is buttered | 15:53 |
Rockyg | no, it was later in the day.... | 15:53 |
markvoelker | Kinda 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 |
topol | markvoelker that sounds good | 15:54 |
tongli | @Rockyg, it should be 11:00am. ours is current UTC1500. | 15:54 |
topol | let's wait and see what happens with the new meeting channel | 15:54 |
tongli | which 10:00am EDT. | 15:54 |
tongli | I would think utc1600 is 11:00am EDT. | 15:54 |
topol | 2 more quick items | 15:55 |
* markvoelker glances at the clock and notes that (speaking of the defcore/interopWG meeting) it starts in 5 minutes... | 15:55 | |
Rockyg | it mighta been 1800... | 15:55 |
topol | im gonna move quick folks | 15:55 |
tongli | k. as long as we can use this channel, I am ok. | 15:55 |
topol | #item PTG meeting | 15:55 |
topol | are folks going? Tong Li and I will be going | 15:55 |
* markvoelker is planning to attend | 15:56 | |
Rockyg | but, yeah. I'll post the actual options. I think we could get 1400 now, but that's 6am out here | 15:56 |
topol | do we need to ask for our own space there | 15:56 |
topol | ? | 15:56 |
markvoelker | topol: PTG space is mostly reserved for big tent teams, so it may be difficult to get space there. | 15:56 |
Rockyg | Yeha, I'll be there. | 15:56 |
topol | how much time at PTG do you all want to spend on interop? | 15:56 |
topol | hopefully they have some flex space | 15:57 |
Rockyg | we can always meet at a coffee shop, or better, over beers | 15:57 |
topol | I can ask ttx | 15:57 |
topol | so let's plan on meeting a little there | 15:57 |
tongli | big thanks to Christopher for setting up the new repo. | 15:57 |
topol | but folks can still focous on their primary areas | 15:58 |
Rockyg | yay aedo! | 15:58 |
topol | #item new repo is up | 15:58 |
topol | Thanks caedo | 15:58 |
tongli | ansible and terraform workloads are all moved already. | 15:58 |
topol | new repo structure is in | 15:58 |
topol | thanks tongli | 15:58 |
tongli | now need a bit discussion on tox. | 15:58 |
tongli | which is enabled. | 15:58 |
tongli | but we can talk about that next time. | 15:58 |
topol | we only have 1 minute | 15:58 |
topol | k | 15:58 |
topol | perfect | 15:58 |
topol | #action topol ask ttx about flex space | 15:59 |
topol | #endmeeting | 15:59 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 15:59 | |
openstack | Meeting ended Wed Dec 7 15:59:28 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:59 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.html | 15:59 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.txt | 15:59 |
openstack | Log: http://eavesdrop.openstack.org/meetings/interop_challenge/2016/interop_challenge.2016-12-07-15.01.log.html | 15:59 |
topol | thanks every one | 15:59 |
Rockyg | thanks! | 15:59 |
tongli | thanks. | 15:59 |
*** parora has joined #openstack-meeting-cp | 15:59 | |
*** skazi_ has quit IRC | 16:00 | |
lbragstad | ping lbragstad, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung | 16:00 |
lbragstad | #startmeeting policy | 16:00 |
openstack | Meeting 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
*** edmondsw has joined #openstack-meeting-cp | 16:00 | |
*** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
openstack | The meeting name has been set to 'policy' | 16:00 |
*** zhipengh has left #openstack-meeting-cp | 16:00 | |
dstanek | o/ | 16:00 |
rderose | o/ | 16:00 |
lbragstad | o/ | 16:01 |
edmondsw | o/ | 16:01 |
ayoung | Yehaw | 16:01 |
*** prateek_ has quit IRC | 16:01 | |
lamt | o/ | 16:01 |
dolphm | \o | 16:01 |
ayoung | Agenda is here https://etherpad.openstack.org/p/keystone-policy-meeting | 16:01 |
*** prateek_ has joined #openstack-meeting-cp | 16:01 | |
*** edand has left #openstack-meeting-cp | 16:02 | |
mars | Is cinder team meeting has began? | 16:02 |
ayoung | mars, wrong room, this is policy | 16:02 |
*** jaugustine has joined #openstack-meeting-cp | 16:02 | |
lbragstad | mars looks like it has in #openstack-meeting | 16:02 |
mars | thx | 16:03 |
lbragstad | mars you're more than welcome to stay and help with policy though ;) | 16:03 |
lbragstad | alright - #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:03 |
*** tongli has quit IRC | 16:03 | |
lbragstad | even though ayoung dropped it earlier | 16:03 |
lbragstad | #topic action items from last week | 16:04 |
*** openstack changes topic to "action items from last week (Meeting topic: policy)" | 16:04 | |
ayoung | do we have any Other proposals for policy at this point? | 16:04 |
mars | thx,but now i must to join in the cinder and ask some questions to my ptl | 16:04 |
*** parora has quit IRC | 16:04 | |
lbragstad | we all had action items to review ayoung policy spec | 16:04 |
ayoung | Got that on the Agenda for this week lbragstad but put it at the end | 16:05 |
lbragstad | ayoung yep - i see that | 16:05 |
edmondsw | I like the "Role Check Check" title ;) | 16:05 |
lbragstad | #topic other proposals for policy | 16:06 |
*** openstack changes topic to "other proposals for policy (Meeting topic: policy)" | 16:06 | |
ayoung | edmondsw, I felt that "Role Check Check Check" had better rhythm, but was just too much | 16:06 |
edmondsw | lol | 16:06 |
lbragstad | i wish ruan was here | 16:06 |
ayoung | I can start to address his question, though, on what it would take | 16:06 |
lbragstad | ayoung are you referencing the external PEP and PDP bits? | 16:07 |
ayoung | yep | 16:07 |
lbragstad | sure - go for it. we can get his opinion if he joins | 16:07 |
ayoung | OK, so, lets start with the current state of how services call Oslo-policy | 16:08 |
ayoung | there is a project called oslo-context that essentially is the contract for the set of parameters that a service should use to call policy | 16:08 |
ayoung | in order to call a remote PDP, we need a contract like that | 16:08 |
ayoung | and the tricky part is "what attributes are we going to use to enforce policy" | 16:09 |
*** jgriffith_away is now known as jgriffith | 16:09 | |
ayoung | The current approach mixes the oslo-context set (most Keystone token validation data in dictionary form) with some of the values from the service | 16:09 |
ayoung | looking at the policy rules that Neutron does can show you some of the complexity | 16:09 |
dstanek | do 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 threads | 16:10 |
ayoung | I'd group it into 2 things, though, that the service needs to pass | 16:10 |
ayoung | dstanek, can you hold that question for a moment? | 16:10 |
lbragstad | dstanek i think that's a good starting point | 16:10 |
ayoung | 1. is the scope of the resource: what project owns it, what user, and so forth | 16:10 |
ayoung | 2. is sharing criteria | 16:11 |
ayoung | and if you look at neutron, it is 'is this a public network' which is also mirrored in glance | 16:11 |
ayoung | so, those are the use cases solved by policy today | 16:11 |
ayoung | I don;t think we have a usecase document yet for the External PDP. If there is, I have not seen it | 16:12 |
*** gagehugo has joined #openstack-meeting-cp | 16:12 | |
ayoung | However, Access Control is not a new concept | 16:12 |
lbragstad | ayoung let's just talk usecases in general | 16:12 |
lbragstad | ayoung you example highlights at least one | 16:12 |
ayoung | and we should not need to invent them all from scratch. | 16:13 |
ayoung | So...let me define the central use case: | 16:13 |
lbragstad | #topic use cases for policy | 16: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 |
ayoung | that is the use case that policy today almost supports | 16:14 |
ayoung | the neutron glance use case is more like: | 16:14 |
*** bastafidli has quit IRC | 16:14 | |
ayoung | "allow a set of users access to some operation on a resource based on attributes of the resource" | 16:15 |
lbragstad | true | 16:15 |
ayoung | which builds on top of the core use case | 16:15 |
ayoung | I would actually say the core use case as implemented by oslo policuy today is | 16:15 |
*** thinrichs has joined #openstack-meeting-cp | 16: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 |
edmondsw | breaking 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 play | 16:16 |
ayoung | and 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 |
ayoung | and we are trying to change that to | 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 the admin project project" | 16:16 |
ayoung | edmondsw, 1) also includes the resource scope | 16:17 |
ayoung | well... | 16:17 |
ayoung | OK lets define the admin use case this way | 16:17 |
lbragstad | let's consider admin is just a role | 16: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 |
lbragstad | to me - that should fall into the first use case | 16:18 |
edmondsw | the 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 exist | 16:18 |
ayoung | edmondsw, so...that gets into the second to last item I have on the agenda | 16:18 |
lbragstad | admin shouldn't be anything special - it's just a role that maps to a set of operations | 16:18 |
ayoung | https://bugs.launchpad.net/keystone/+bug/968696 | 16:19 |
openstack | Launchpad bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] - Assigned to Adam Young (ayoung) | 16:19 |
ayoung | lbragstad, not quite. there are 2 types of admin-ness | 16:19 |
ayoung | 1 is do I have admin on this specific project | 16:19 |
ayoung | but the 0 level rule is | 16:19 |
edmondsw | lbragstad, I wish admin wasn't special. I would like to get there someday. We are a long way from that | 16:19 |
ayoung | this Operation is special. I need admin on a special project (or projects..future work) | 16:20 |
lbragstad | edmondsw agreed | 16:20 |
ayoung | and, if I have admin on the special project, I can use that as an override for project scoped operations | 16:20 |
lbragstad | edmondsw but ideally admin should just be a role that maps to a set of operations - right? | 16:20 |
ayoung | lbragstad, it is also and override | 16:20 |
dstanek | for my own sanity i'm starting to record this here: https://etherpad.openstack.org/p/keystone-policy-usecases | 16:20 |
ayoung | admin role on the admin project is a global admin, capable of fixing things for many other users | 16:20 |
ayoung | dstanek, thanks | 16:21 |
lbragstad | dstanek i started writing some down in the meeting but i'll port them to your etherpad | 16:21 |
edmondsw | lbragstad 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 rules | 16: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 proposals | 16:21 | |
ayoung | I want to use the term Member as opposed to user, if that is OK | 16:22 |
lbragstad | dstanek ++ | 16:22 |
edmondsw | dstanek ++ | 16:22 |
ayoung | We did have jamielennox and dolphm 's attempt to set a basic set of roels that does address this | 16:22 |
ayoung | let me find it | 16:22 |
lbragstad | edmondsw 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 point | 16:23 |
edmondsw | lbragstad ++ | 16:23 |
lbragstad | if we were to start *all* over, how would this look? | 16:23 |
thinrichs | If 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 |
thinrichs | https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#heading=h.wvybnha031eu | 16:24 |
lbragstad | which 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 on | 16:24 |
edmondsw | we would have a global scope concept... i.e. you could assign a role to a user for a domain or a project OR globally | 16:24 |
ayoung | dolphm, do you remember what it was called and who owned it? | 16:24 |
ayoung | edmondsw, so that is what "admin_project" can now support | 16:25 |
edmondsw | admin_project is a hack... lbragstad asked what we would do if we could do it all over again | 16:25 |
ayoung | you 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, too | 16:26 |
dolphm | ayoung: no? | 16:26 |
thinrichs | More use cases…(the ones implemented): https://docs.google.com/document/d/1w55wDighZvI9zKAtnO4jOfDMScmN7Qf5NHFtFdk8Sas/edit#heading=h.v7jiiyumrken | 16:26 |
ayoung | edmondsw, it is not a hack. It was the assumption upon which policy was written way back in the termie days, | 16:26 |
edmondsw | ayoung I totally disagree | 16:27 |
ayoung | edmondsw, yeah, well you are not the one that tried to change it and then got slammed by the operators... | 16:27 |
ayoung | heh | 16:27 |
dstanek | lbragstad: ++ having a vision without worrying about what we have is important. the reviews would be the baby steps to get us there | 16:27 |
ayoung | but, we need some way of saying "here is the global scope" | 16:27 |
ayoung | I was originally hoping to implement it based on hierarchies but we ran into the HMT role inheritance, and, well, its hard | 16:28 |
dstanek | ayoung: root domain? | 16:28 |
ayoung | dstanek, yes | 16:28 |
ayoung | dstanek, 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 that | 16:29 |
ayoung | they are probably wrong | 16:29 |
dstanek | cloud 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 |
edmondsw | ayoung I think you were looking for this a minute ago: https://review.openstack.org/#/c/274157/ | 16:29 |
ayoung | from a security standpoint, it is a frightening approach | 16:29 |
dstanek | ayoung: they didn't want rescoping? | 16:30 |
dstanek | ayoung: what is frightening? | 16:30 |
ayoung | edmondsw, that was a subset, yes, but there was a more complete one. It was jamielennox's I thouight | 16:30 |
edmondsw | ayoung, right, that was just the first I found | 16:30 |
ayoung | edmondsw, this was a cross-project spec | 16:30 |
ayoung | but I don't even know how to find those | 16:31 |
edmondsw | ayoung https://review.openstack.org/#/c/245629/ | 16:31 |
ayoung | edmondsw, BINGO! | 16:31 |
ayoung | #link https://review.openstack.org/#/c/245629/ | 16:31 |
lbragstad | https://specs.openstack.org/openstack/openstack-specs/ | 16:32 |
lbragstad | (published ones) ^ | 16:32 |
ayoung | So the goal of that spec was to provide a set of roles that allowed for the above use case plus a few more | 16:32 |
ayoung | Observer, as edmondsw just linked to is a big one | 16:32 |
edmondsw | that's why I found it first :) | 16:32 |
ayoung | that is another one that people want with out scoping, and again, it scares me | 16:32 |
ayoung | the other is per-service admin | 16:33 |
ayoung | so nova-admin can't mess up neutron and glance-admin can't touch keystone, etc | 16:33 |
ayoung | so...lets skip the RBAC based use cases for the moment, as I will talk about them at the end | 16:33 |
ayoung | the other use case is this: | 16:34 |
ayoung | "allow different levels of user access for a resources in a project" | 16:34 |
ayoung | that 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, etc | 16:35 |
ayoung | the 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 be | 16:35 |
ayoung | its a general concept, though, that the openstack model does not easily support | 16:36 |
ayoung | right now, the level of abstraction is "project is the label used for access control" | 16:36 |
ayoung | and in doing that, it mixes two things: | 16:36 |
ayoung | 1. how do I list/create a set of objects | 16:36 |
ayoung | 2. how do I have access to these objects | 16:37 |
ayoung | if you compare it with a unix file system, its like we force a one-to-one relationship between dentries and inodes | 16:37 |
ayoung | IE. we have not way of talking about the objects *outside* for the hierarchy used to organize them | 16:38 |
ayoung | I 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 schemes | 16:38 |
ayoung | OK...enough lecturing from me. Does all this (or any of it) make sense? | 16:38 |
dstanek | ayoung: 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 allowing | 16:39 |
ayoung | dstanek, well, yes, it does, but you need to store that info somewhere, and that is the problem | 16:39 |
ayoung | it means that, for every resource, you need to have a shadow record in the remote PDP | 16:40 |
ayoung | so, say you had an idea like, subnetwork-groups | 16:40 |
ayoung | any you want to say that a subnet can be in one or more subnet groups | 16:40 |
ayoung | and that access is going to be based on what subnet groups a user is enrolled in | 16:40 |
ayoung | all that info has to be either in keystone, in neutron, or in the remote PDP | 16:41 |
edmondsw | dstanek coding the id like that probably wouldn't be practical... you need some some way of doing things more dynamically | 16:41 |
ayoung | for every user, for every subnet group, and for every subnet. | 16:41 |
edmondsw | dstanek e.g. owner_id=me where owner_id is an attribute of the resource stored by the relevant service | 16:41 |
dstanek | ayoung: edmondsw: i'm trying to tease out the usecase we care about. so specific entity isn't one of them? | 16:42 |
edmondsw | dstanek 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 |
edmondsw | dstanek I don't think so | 16:42 |
thinrichs | dstanek: I'd imagine we'd want specific entities but referenced by groups that are dynamically constructed | 16:43 |
dstanek | edmondsw: can you add that to the etherpad? and anything else you are about being able to assign based on | 16:43 |
edmondsw | dstanek sure | 16:43 |
ayoung | dstanek, 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* critera | 16:43 |
dstanek | "this is my thing and i want to give Frank access to it" - is that a specific usecase? | 16:44 |
ayoung | I 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 through | 16:44 |
thinrichs | dstanek: I'd say so | 16:46 |
edmondsw | dstanek what I put in the pad make sense? | 16:46 |
lbragstad | i thinks o | 16:46 |
edmondsw | dstanek "I want to grant Frank access"... wouldn't that get into trusts? | 16:47 |
edmondsw | ayoung 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 step | 16:48 |
dstanek | edmondsw: makes sense | 16:48 |
dstanek | edmondsw: not sure because you could say that about most of what we are doing | 16:49 |
dstanek | cloud admin (admin on root project) delegates admin on a project to Joe (a domain admin).... | 16:49 |
dstanek | ayoung: what an example of mounting? | 16:50 |
lbragstad | like checking the attributes of a server using Neutron? | 16:50 |
edmondsw | time check: 10 minutes left | 16:50 |
lbragstad | edmondsw thanks | 16:50 |
lbragstad | or are we talking about mounting as in take this VM and mount it on this other project? | 16:51 |
edmondsw | dstanek mounting example: I have a VM in project A, and I want to make that visible in project B as well | 16:51 |
ayoung | ok...let me cover my last two items, please? | 16:52 |
ayoung | Bug 968696 Work | 16:52 |
openstack | bug 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 |
ayoung | I need some help here. Made some progress but... | 16:52 |
lbragstad | #topic the infamous bug 968696 | 16:53 |
*** openstack changes topic to "the infamous bug 968696 (Meeting topic: policy)" | 16:53 | |
ayoung | A little background: | 16:53 |
*** Kiall has quit IRC | 16:53 | |
ayoung | this is the admin_project stuff edmondsw and I were discussing earlier | 16:53 |
ayoung | we need to add a rule to each of the policy files to check that field for admin-over ride | 16:53 |
*** Kiall has joined #openstack-meeting-cp | 16:53 | |
ayoung | and glance and cinder now pass | 16:53 |
edmondsw | ayoung where do we stand on the nova patch we'd put up? | 16:53 |
ayoung | but..nova does not, and Keystone is a mess | 16:53 |
ayoung | edmondsw, so I got the roll back on the devstack change that was getting in the way | 16:53 |
ayoung | but nova has a different gate job that seems to it via some other mechanism. | 16:54 |
edmondsw | :) | 16:54 |
ayoung | LInk in a sec... | 16:54 |
ayoung | https://review.openstack.org/#/c/384642/ is a successful one for comparison | 16:54 |
edmondsw | I am happy to try to help there when I can spare cycles | 16:54 |
ayoung | https://review.openstack.org/#/c/384148/ is the nova one | 16:54 |
ayoung | so that has fewer failing jobs, but I think they are for the same reason" | 16:55 |
ayoung | something is setting is_admin_project | 16:55 |
ayoung | there are also a handful of changes that keystone needs as prereq, but I can handle those | 16:55 |
ayoung | edmondsw, if you could see the nova one on through, that would be the most help | 16:55 |
edmondsw | can you point me to the devstack roll back for comparison? | 16:55 |
ayoung | edmondsw, it was just a removal of setting is_admin_project by default...let me see... | 16:56 |
ayoung | I'll do that later...one other thing first | 16:56 |
edmondsw | later's fine | 16:56 |
ayoung | I'll keep working on Keystone, but there are some refactorings that need to happen frist... | 16:56 |
ayoung | https://review.openstack.org/#/c/387161/ and | 16:57 |
ayoung | https://review.openstack.org/#/c/387710/ | 16:57 |
ayoung | please review and move those along | 16:57 |
ayoung | those are prereqs for | 16:57 |
ayoung | https://review.openstack.org/#/c/257636/ | 16:57 |
ayoung | which I will rename to be consistent with the nova and glance reviews | 16:57 |
ayoung | ok last thing, rushed | 16:58 |
ayoung | RBAC in m,iddleware | 16:58 |
lbragstad | #topic rbac in middleware status | 16:58 |
*** openstack changes topic to "rbac in middleware status (Meeting topic: policy)" | 16:58 | |
ayoung | review has 2 +2s, and some comments from lbragstad to address | 16:58 |
ayoung | I think it is going to make it in to the "approved for Ocata" pile | 16:58 |
lbragstad | #link https://review.openstack.org/#/c/391624/ | 16:58 |
lbragstad | ayoung dstanek had a bunch of comments on patch set 11 that i attempted to port | 16:59 |
ayoung | this is a layer on top of policy, and should only be hardening, will not open new ways around | 16:59 |
ayoung | lbragstad, ++ and I will address | 16:59 |
ayoung | is everyone comfortable with the approach? | 16:59 |
lbragstad | i have a couple big concerns | 16:59 |
lbragstad | i reviewed it last night | 16:59 |
ayoung | perf, security, or other? | 16:59 |
lbragstad | the splitting of rbac into it's own check | 17:00 |
lbragstad | we're out of time | 17:00 |
lbragstad | we can continue in -keystone | 17:00 |
lbragstad | #endmeeting | 17:00 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:00 | |
openstack | Meeting ended Wed Dec 7 17:00:28 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.html | 17:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.txt | 17:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2016/policy.2016-12-07-16.00.log.html | 17:00 |
edmondsw | I had a lot of concerns last I read, but I haven't read the latest yet... I think I can get to it tomorrow | 17:00 |
*** thinrichs has left #openstack-meeting-cp | 17:00 | |
*** mars has quit IRC | 17:07 | |
*** moshele has joined #openstack-meeting-cp | 17:09 | |
*** moshele has quit IRC | 17:17 | |
*** gagehugo has left #openstack-meeting-cp | 17:21 | |
*** reed has quit IRC | 17:32 | |
*** dhellmann has quit IRC | 17:33 | |
*** gouthamr has quit IRC | 17:37 | |
*** gouthamr has joined #openstack-meeting-cp | 17:39 | |
*** spilla has left #openstack-meeting-cp | 17:55 | |
*** dhellmann has joined #openstack-meeting-cp | 18:00 | |
*** reed has joined #openstack-meeting-cp | 18:00 | |
*** david-lyle_ is now known as david-lyle | 18:02 | |
*** parora has joined #openstack-meeting-cp | 18:10 | |
*** bastafidli has joined #openstack-meeting-cp | 18:12 | |
*** prateek_ has quit IRC | 18:13 | |
*** rarcea has quit IRC | 18:13 | |
*** reed has quit IRC | 18:14 | |
*** dhellmann has quit IRC | 18:15 | |
*** prateek has joined #openstack-meeting-cp | 18:21 | |
*** parora has quit IRC | 18:24 | |
*** prateek has quit IRC | 18:43 | |
*** garloff has quit IRC | 18:51 | |
*** garloff has joined #openstack-meeting-cp | 18:51 | |
*** bastafidli has quit IRC | 19:04 | |
*** gouthamr has quit IRC | 19:30 | |
*** gouthamr has joined #openstack-meeting-cp | 19:33 | |
*** piet has joined #openstack-meeting-cp | 19:39 | |
*** lamt has quit IRC | 19:49 | |
*** dhellmann_ has joined #openstack-meeting-cp | 19:52 | |
*** dhellmann_ is now known as dhellmann | 19:59 | |
*** reed has joined #openstack-meeting-cp | 20:03 | |
*** gouthamr has quit IRC | 20:32 | |
*** harlowja has quit IRC | 20:41 | |
*** edmondsw has quit IRC | 20:43 | |
*** kbyrne has quit IRC | 20:43 | |
*** kbyrne has joined #openstack-meeting-cp | 20:45 | |
*** lamt has joined #openstack-meeting-cp | 20:47 | |
*** xyang1 has joined #openstack-meeting-cp | 20:58 | |
*** bastafidli has joined #openstack-meeting-cp | 21:05 | |
*** bastafidli has quit IRC | 21:13 | |
*** harlowja has joined #openstack-meeting-cp | 21:41 | |
*** diablo_rojo has quit IRC | 22:04 | |
*** itisha has joined #openstack-meeting-cp | 22:06 | |
*** bastafidli has joined #openstack-meeting-cp | 22:09 | |
*** diablo_rojo has joined #openstack-meeting-cp | 22:17 | |
*** piet has quit IRC | 22:29 | |
*** diablo_rojo has quit IRC | 22:33 | |
*** ayoung has quit IRC | 22:48 | |
*** lamt has quit IRC | 22:48 | |
*** jaugustine has quit IRC | 22:50 | |
*** piet has joined #openstack-meeting-cp | 23:11 | |
*** harlowja has quit IRC | 23:16 | |
*** bastafidli has quit IRC | 23:17 | |
*** david-lyle_ has joined #openstack-meeting-cp | 23:20 | |
*** david-lyle_ has quit IRC | 23:20 | |
*** xyang1 has quit IRC | 23:22 | |
*** piet has quit IRC | 23:41 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!