Friday, 2015-09-11

*** ktolstoy has joined #openstack-defcore04:24
*** ktolstoy has quit IRC04:25
*** reed_ has joined #openstack-defcore05:41
*** reed_ has quit IRC06:01
*** markvoelker has quit IRC06:16
*** markvoelker has joined #openstack-defcore07:17
*** markvoelker has quit IRC07:22
*** ktolstoy has joined #openstack-defcore08:14
*** alex_klimov has joined #openstack-defcore08:33
*** ktolstoy has quit IRC10:59
*** ktolstoy has joined #openstack-defcore11:00
*** ktolstoy has quit IRC11:03
*** markvoelker has joined #openstack-defcore11:04
*** markvoelker has quit IRC11:09
*** ktolstoy has joined #openstack-defcore11:09
*** ktolstoy has quit IRC11:10
*** ktolstoy has joined #openstack-defcore11:11
*** ktolstoy has quit IRC11:17
*** ktolstoy has joined #openstack-defcore11:17
*** ktolstoy has quit IRC11:21
*** ktolstoy has joined #openstack-defcore11:23
*** ktolstoy has quit IRC12:06
*** markvoelker has joined #openstack-defcore12:15
*** ktolstoy has joined #openstack-defcore12:21
*** VanL has joined #openstack-defcore12:59
*** VanL has quit IRC13:04
*** VanL has joined #openstack-defcore13:04
*** frayedknot has joined #openstack-defcore13:15
*** VanL has quit IRC13:57
*** mestery has quit IRC13:57
*** VanL has joined #openstack-defcore14:05
*** mestery has joined #openstack-defcore14:37
*** VanL_ has joined #openstack-defcore14:50
*** VanL has quit IRC14:54
*** reed_ has joined #openstack-defcore14:55
*** mestery has quit IRC15:20
*** frayedknot has quit IRC15:21
*** kbaikov has quit IRC15:25
*** reed_ has quit IRC15:38
*** ktolstoy has quit IRC15:42
*** ktolstoy has joined #openstack-defcore15:46
*** VanL_ has quit IRC15:53
*** VanL has joined #openstack-defcore16:01
*** mestery has joined #openstack-defcore16:09
*** alex_klimov has quit IRC16:17
*** VanL has quit IRC16:48
*** ktolstoy has quit IRC17:02
catherineDmarkvoelker: hogepodge: 2015.07 includes identity-v3-tokens-create with status required.  Since this spec cover Icehouse, Juno, Kilo ... Do I assume that any cloud applying for OpenStack logo from now on have to supoort Keystone V3 API? My question is is it reasonable to ask an Icehouse based cloud to support Keystone V3 API?17:11
markvoelkercatherineD: I've been looking at that myself, and I sorta think not.  I'm not totally convinced Juno is even fair based on adoption.17:27
markvoelkercatherineD: however, I'm also staring at a temepst result set right now which shows the v3 test as passed even though I was pretty sure the cloud under test only exposed v2. o_O17:27
catherineDmarkvoelker: that  is not good it the V3 test pass with only V2 expose ... I will take a look on that on my clouds ..17:30
markvoelkerYEah, unfortunately this environment is in Singapore and I can't get into it right at the moment, but I'll definitely be looking at that a little harder.17:31
catherineDmarkvoelker: The reason I ask the question is that we are now trying to look at using Keystone Catalog response to fetch CPID (cloud provider ID as identigy service id).  The response on V2 and V3 are different ... If base on the spec , all cloud has to support V3 then refstack-client can just ignore V2 and using V3 on all cases ...17:34
markvoelkercatherineD: I see.  FWIW, I made some comments here that relevant to the v2 vs v3 discussion: https://review.openstack.org/#/c/213330/3/working_materials/scoring.txt17:35
markvoelkerBasically I'm seeing a lot of products support one or the other but few supporting both from preliminary investigation.17:36
catherineDmarkvoelker: currently in the 2015.07 spec ... we already require one V3 test (identity-v3-tokens-create) ... for the clouds that do not support V3 ... they will not be able to pass 2015.0717:38
catherineDin 2015.07 require supporting both17:39
markvoelkercatherineD: yeah, I noted that in the general comments on https://review.openstack.org/#/c/213330/ as well.17:39
markvoelkerSo far we haven't seen objections...but we don't have anyone who has completed certification on 07 yet either.17:40
markvoelkerWe do have a couple that are in progress now (in fact I think my company has a passing result now), so hopefully we'll be getting feedback soon.17:40
markvoelkerI'm increasingly skeptical that v3 should be required.17:40
catherineDmarkvoelker: does that means that your company's cloud support both v2 and v3?17:42
markvoelkerWe can, but ship with v2 only by default in the current release.17:43
markvoelkerFrankly I've found a number of apps that manage to get confused when both are enabled, and v3 had some interesting issues in the releases covered by 2015.07.17:44
catherineDat the minimum from our experience, in the keystone catalog outputs what being returned with the ID lable are different between v2 and v3.17:48
*** VanL has joined #openstack-defcore17:51
markvoelkercatherineD: yeah, there's quite a bit different.  When I get out of this meeting I'm going to go hash through the one v3 test we currently require and see what's different in the v2/v3 request and replies17:52
markvoelkerSorta vauguely wondering if they're similar enough for the tests to both pass on v217:52
markvoelkerThe test just basically authenticates and creates a token, so I suppose that's not out of the realm of possibility.17:52
hogepodgemarkvoelker: I guess my answer is file a bug and submit a flag18:19
markvoelkerhogepodge: I may, but want to verify whether I'm crazy or not first. =)18:19
hogepodgeIt looks like we can't feasibly require anything that is in a version transition.18:19
hogepodgeso keystone and glace are definitely out18:20
markvoelkerYEah, that's a tough nut to crack right now since we handle 3 releases per Guideline and API transitions often take longer.18:20
markvoelkerWe need to think about a better way to handle that.18:20
* markvoelker files another backlog item18:20
hogepodgeI'm beginning to think our requirements aren't tight enough, or that we should consider coverage to be three releases across two guidelines18:21
hogepodgebut as it stands, it doesn't seem that our standard means much of anything any more.18:21
markvoelkerMajor-version API transitions feel like an area where we'd want to check in with the API WG I suppose, but maybe it's partly a need to set expectations for vendors18:22
hogepodgevendors will object to any constraints we put on them18:24
markvoelkerPossibly, but I'm more thinking of it as "if they know that from now on we're going to require a new major-version API starting w/the fist Guideline to cover the release in which it becomes CURRENT" then maybe they'll be more proactive about loging protests early18:25
markvoelkerANd then we can decide if it's actually a valid thing to do18:25
markvoelkerE.g. if v3 actually has a lot of problems with clients and isn't "complete" and vendors can show examples of that, it might not score high enoguh to get in to begin with.18:25
hogepodgeI'm going to propose that Keystone v3 be the only acceptable api in 2016.0118:26
hogepodgeIf you can't hack it, use 2015.07. Get on board and upgrade.18:26
markvoelkerGenerally I'm ok with that, but IIRC even other OpenStack projects supported v3 relatively poorly as recently as Juno and Kilo.  TC governance needed in such cases IMHO.18:27
hogepodgevendors also need to be active in contributing. This is a community, and vendors aren't free from contributing.18:27
hogepodgeThen let's shore up nova apis and make sure every proxy is solid.18:28
hogepodgebecause it's ridiculous that we can't do basic things like guarantee consistent auth, or be able to list images. These are problems that should be easy and instead we're still fighting about them.18:28
hogepodgeAnd require and let them flag and put pressure on the projects to fix their interfaces with other projects.18:29
markvoelkerI don't disagree.  But IMHO vendors aren't the only ones to blame for those issues.18:29
hogepodgeAgain, we're a community, and our core projects need to learn to play well together.18:29
markvoelkerSure. If other projects aren't fully supporting a API that's been declared CURRENT then the community fell down somewhere. Feels wrong to penalize only one part of that community though, and not ask for improved technical governance.18:30
*** jmckind has joined #openstack-defcore19:20
*** VanL_ has joined #openstack-defcore20:02
*** VanL has quit IRC20:04
*** jmckind has quit IRC20:18
*** VanL_ has quit IRC20:30
*** jmckind has joined #openstack-defcore20:30
*** jmckind has quit IRC20:31
*** jmckind has joined #openstack-defcore20:32
*** jmckind has quit IRC21:00
-openstackstatus- NOTICE: 30 minute warning, Gerrit will be offline from 23:00 to 23:30 UTC while some projects are renamed http://lists.openstack.org/pipermail/openstack-dev/2015-September/074235.html22:31
-openstackstatus- NOTICE: Gerrit is offline from 23:00 to 23:30 UTC while some projects are renamed. http://lists.openstack.org/pipermail/openstack-dev/2015-September/074235.html23:01
*** ChanServ changes topic to "Gerrit is offline from 23:00 to 23:30 UTC while some projects are renamed. http://lists.openstack.org/pipermail/openstack-dev/2015-September/074235.html"23:01
*** markvoelker has quit IRC23:19
*** ChanServ changes topic to "Next Meeting August 26, 10 AM CST https://etherpad.openstack.org/p/DefCoreFlag.12"23:38
*** openstackgerrit has quit IRC23:46
*** openstackgerrit has joined #openstack-defcore23:46

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