*** ktolstoy has joined #openstack-defcore | 04:24 | |
*** ktolstoy has quit IRC | 04:25 | |
*** reed_ has joined #openstack-defcore | 05:41 | |
*** reed_ has quit IRC | 06:01 | |
*** markvoelker has quit IRC | 06:16 | |
*** markvoelker has joined #openstack-defcore | 07:17 | |
*** markvoelker has quit IRC | 07:22 | |
*** ktolstoy has joined #openstack-defcore | 08:14 | |
*** alex_klimov has joined #openstack-defcore | 08:33 | |
*** ktolstoy has quit IRC | 10:59 | |
*** ktolstoy has joined #openstack-defcore | 11:00 | |
*** ktolstoy has quit IRC | 11:03 | |
*** markvoelker has joined #openstack-defcore | 11:04 | |
*** markvoelker has quit IRC | 11:09 | |
*** ktolstoy has joined #openstack-defcore | 11:09 | |
*** ktolstoy has quit IRC | 11:10 | |
*** ktolstoy has joined #openstack-defcore | 11:11 | |
*** ktolstoy has quit IRC | 11:17 | |
*** ktolstoy has joined #openstack-defcore | 11:17 | |
*** ktolstoy has quit IRC | 11:21 | |
*** ktolstoy has joined #openstack-defcore | 11:23 | |
*** ktolstoy has quit IRC | 12:06 | |
*** markvoelker has joined #openstack-defcore | 12:15 | |
*** ktolstoy has joined #openstack-defcore | 12:21 | |
*** VanL has joined #openstack-defcore | 12:59 | |
*** VanL has quit IRC | 13:04 | |
*** VanL has joined #openstack-defcore | 13:04 | |
*** frayedknot has joined #openstack-defcore | 13:15 | |
*** VanL has quit IRC | 13:57 | |
*** mestery has quit IRC | 13:57 | |
*** VanL has joined #openstack-defcore | 14:05 | |
*** mestery has joined #openstack-defcore | 14:37 | |
*** VanL_ has joined #openstack-defcore | 14:50 | |
*** VanL has quit IRC | 14:54 | |
*** reed_ has joined #openstack-defcore | 14:55 | |
*** mestery has quit IRC | 15:20 | |
*** frayedknot has quit IRC | 15:21 | |
*** kbaikov has quit IRC | 15:25 | |
*** reed_ has quit IRC | 15:38 | |
*** ktolstoy has quit IRC | 15:42 | |
*** ktolstoy has joined #openstack-defcore | 15:46 | |
*** VanL_ has quit IRC | 15:53 | |
*** VanL has joined #openstack-defcore | 16:01 | |
*** mestery has joined #openstack-defcore | 16:09 | |
*** alex_klimov has quit IRC | 16:17 | |
*** VanL has quit IRC | 16:48 | |
*** ktolstoy has quit IRC | 17:02 | |
catherineD | markvoelker: 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 |
---|---|---|
markvoelker | catherineD: 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 |
markvoelker | catherineD: 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_O | 17:27 |
catherineD | markvoelker: 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 |
markvoelker | YEah, 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 |
catherineD | markvoelker: 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 |
markvoelker | catherineD: 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.txt | 17:35 |
markvoelker | Basically I'm seeing a lot of products support one or the other but few supporting both from preliminary investigation. | 17:36 |
catherineD | markvoelker: 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.07 | 17:38 |
catherineD | in 2015.07 require supporting both | 17:39 |
markvoelker | catherineD: yeah, I noted that in the general comments on https://review.openstack.org/#/c/213330/ as well. | 17:39 |
markvoelker | So far we haven't seen objections...but we don't have anyone who has completed certification on 07 yet either. | 17:40 |
markvoelker | We 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 |
markvoelker | I'm increasingly skeptical that v3 should be required. | 17:40 |
catherineD | markvoelker: does that means that your company's cloud support both v2 and v3? | 17:42 |
markvoelker | We can, but ship with v2 only by default in the current release. | 17:43 |
markvoelker | Frankly 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 |
catherineD | at 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-defcore | 17:51 | |
markvoelker | catherineD: 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 replies | 17:52 |
markvoelker | Sorta vauguely wondering if they're similar enough for the tests to both pass on v2 | 17:52 |
markvoelker | The test just basically authenticates and creates a token, so I suppose that's not out of the realm of possibility. | 17:52 |
hogepodge | markvoelker: I guess my answer is file a bug and submit a flag | 18:19 |
markvoelker | hogepodge: I may, but want to verify whether I'm crazy or not first. =) | 18:19 |
hogepodge | It looks like we can't feasibly require anything that is in a version transition. | 18:19 |
hogepodge | so keystone and glace are definitely out | 18:20 |
markvoelker | YEah, that's a tough nut to crack right now since we handle 3 releases per Guideline and API transitions often take longer. | 18:20 |
markvoelker | We need to think about a better way to handle that. | 18:20 |
* markvoelker files another backlog item | 18:20 | |
hogepodge | I'm beginning to think our requirements aren't tight enough, or that we should consider coverage to be three releases across two guidelines | 18:21 |
hogepodge | but as it stands, it doesn't seem that our standard means much of anything any more. | 18:21 |
markvoelker | Major-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 vendors | 18:22 |
hogepodge | vendors will object to any constraints we put on them | 18:24 |
markvoelker | Possibly, 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 early | 18:25 |
markvoelker | ANd then we can decide if it's actually a valid thing to do | 18:25 |
markvoelker | E.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 |
hogepodge | I'm going to propose that Keystone v3 be the only acceptable api in 2016.01 | 18:26 |
hogepodge | If you can't hack it, use 2015.07. Get on board and upgrade. | 18:26 |
markvoelker | Generally 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 |
hogepodge | vendors also need to be active in contributing. This is a community, and vendors aren't free from contributing. | 18:27 |
hogepodge | Then let's shore up nova apis and make sure every proxy is solid. | 18:28 |
hogepodge | because 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 |
hogepodge | And require and let them flag and put pressure on the projects to fix their interfaces with other projects. | 18:29 |
markvoelker | I don't disagree. But IMHO vendors aren't the only ones to blame for those issues. | 18:29 |
hogepodge | Again, we're a community, and our core projects need to learn to play well together. | 18:29 |
markvoelker | Sure. 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-defcore | 19:20 | |
*** VanL_ has joined #openstack-defcore | 20:02 | |
*** VanL has quit IRC | 20:04 | |
*** jmckind has quit IRC | 20:18 | |
*** VanL_ has quit IRC | 20:30 | |
*** jmckind has joined #openstack-defcore | 20:30 | |
*** jmckind has quit IRC | 20:31 | |
*** jmckind has joined #openstack-defcore | 20:32 | |
*** jmckind has quit IRC | 21: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.html | 22: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.html | 23: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 IRC | 23:19 | |
*** ChanServ changes topic to "Next Meeting August 26, 10 AM CST https://etherpad.openstack.org/p/DefCoreFlag.12" | 23:38 | |
*** openstackgerrit has quit IRC | 23:46 | |
*** openstackgerrit has joined #openstack-defcore | 23:46 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!