18:01:29 <stevemar> #startmeeting keystone
18:01:29 <openstack> Meeting started Tue May 10 18:01:29 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:33 <dstanek> hiya
18:01:34 <openstack> The meeting name has been set to 'keystone'
18:01:39 <stevemar> ping for keystone ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, knikolla, lbragstad, lhcheng, marekd, MaxPC, morganfainberg, nkinder, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek
18:01:43 <crinkle> o/
18:01:44 <lbragstad> o/
18:01:45 <rodrigods> hi!
18:01:50 <topol> o/
18:01:52 <henrynash> oh boy, oh boy, oh boy
18:01:57 <jorge_munoz> o/
18:02:02 <hogepodge> o/
18:02:02 <ayoung> Keystoners do keystone things!
18:02:05 <stevemar> howdy y'all!
18:02:17 <jaugustine_> O/
18:02:19 * topol I'm 98% recovered from martinellifluenza
18:02:26 <stevemar> it's a toughie eh topol
18:02:38 <dolphm> topol: you can never be 100% recovered from it
18:02:55 <stevemar> agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda
18:03:07 <topol> :-)
18:03:11 <stevemar> #topic newton release deadlines
18:03:39 <stevemar> i sent this out to the mailing list already, so i'll link it here
18:03:40 <stevemar> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093838.html
18:03:44 <morgan> o/
18:03:49 * morgan is here
18:03:53 <stevemar> I'll also be updating releases.openstack.org/newton/schedule.html
18:04:01 <stevemar> fail: http://releases.openstack.org/newton/schedule.html
18:04:17 <rderose> o/
18:04:18 <stevemar> in general, these are the deadlines:
18:04:21 <stevemar> May 30-03 -> R-18 -> Spec proposal freeze
18:04:22 <stevemar> Jul 04-06 -> R-13 -> Spec freeze
18:04:22 <stevemar> Jul 11-15 -> R-12 -> Feature proposal freeze
18:04:24 <stevemar> Aug 29-02 -> R-5 -> Feature Freeze
18:04:46 * topol are the midcycle dates/location 100% confirmed?
18:04:54 <morgan> topol: the dates are confirmed.
18:04:58 * stevemar looks at morgan
18:05:08 <stevemar> what are the dates?
18:05:10 <morgan> topol: it will be in the bay area... but the exact venue will be determined today
18:05:16 <morgan> sec.
18:05:26 <henrynash> and they are….in calendar dates, not R-xx dates
18:05:29 <henrynash> ?
18:05:40 <stevemar> henrynash: what is they?
18:05:47 <henrynash> teh dates, that is
18:06:10 <topol> ahhh Cant wait to goto to Scoma's restaurant
18:06:14 <stevemar> The R-xx dates are alongside the calendar dates
18:06:34 <morgan> its R-11, wed, thurs, friday
18:06:45 <morgan> i *think* that is 20, 21, 22 of July
18:06:52 <bknudson> which time zone?
18:06:52 <morgan> i can;t load the newton schedule/calendar atm
18:06:55 <henrynash> morgan: thx, that’s what I needed
18:06:57 <stevemar> bknudson: :)
18:07:14 <morgan> R-11 Jul 18-22
18:07:18 <stevemar> morgan: thank you sir
18:07:20 <morgan> and it will be wed, thurs, friday of that week
18:07:32 <morgan> we will either be in San Jose, or in San Francisco
18:07:35 <ayoung> Happy Birthday to me!
18:07:36 <morgan> i asked for the SF office space
18:07:39 <anteaya> http://releases.openstack.org/newton/schedule.html
18:07:41 <samueldmq> howdy
18:07:56 <morgan> because i've heard from cburgess that those offices are amazing
18:07:56 <henrynash> ayoung: today…or at the midcycle?
18:08:02 <ayoung> henrynash, mid cycle
18:08:13 <ayoung> 18 July I officially turn middle aged
18:08:16 <henrynash> ayoung: cake, me things
18:08:18 <henrynash> thinks
18:08:24 <stevemar> ayoung: we'll need to get you a cake
18:08:26 <morgan> but we will go with whichever cisco is willing to offer us, neither will be bad.
18:08:31 <ayoung> Candy is Dandy but
18:08:36 <morgan> (also Cisco is hosting us, FYI)
18:08:41 <stevemar> morgan: free routers for everyone!
18:09:04 <cburgess> If only it was free routers for everyone...
18:09:05 <morgan> stevemar: ask cburgess about that, i'm not promising free anythings ;)
18:09:07 <dstanek> yesss!!!! i'll need at least 48 ports on mine
18:09:07 <bknudson> thank you cisco
18:09:12 <topol> liquor is quicker! What did I win?
18:09:21 <stevemar> cburgess: :)
18:09:36 <topol> will dial up be avail?
18:09:37 <dstanek> cburgess: is it more?
18:09:40 <henrynash> topol: buying the first round
18:09:47 <cburgess> I should get the answer on final location this afternoon. There is a planning meeting for the event.
18:09:57 <topol> Sure.. why pot
18:09:59 <morgan> thanks cburgess !
18:09:59 <topol> not
18:10:15 <henrynash> topol: :-)
18:10:15 <stevemar> morgan + cburgess thanks for hosting us! :)
18:10:17 <morgan> cburgess: and pass on the gratitude of the keystone team for hosting us.
18:10:25 <cburgess> Absolutely
18:10:29 <topol> +++ Tahnks morgan and cburgess
18:10:33 <lbragstad> ++
18:10:42 <henrynash> ++
18:10:46 <dstanek> ++
18:10:59 <rderose> ++
18:11:06 <stevemar> aside from midcycle, is everyone OK with the dates I proposed? lots of run way still
18:11:22 <stevemar> you can see how they line up with the release schedule: http://releases.openstack.org/newton/schedule.html
18:11:27 <lbragstad> just to reiterate - it will be Mon July 18th - Wed July 20th
18:11:37 <stevemar> lbragstad: nope, Wed - Fri
18:11:40 <lbragstad> ah
18:11:53 <stevemar> lbragstad: "14:06 morgan: its R-11, wed, thurs, friday"
18:11:55 <lbragstad> so Wednesday the 20th - Friday the 22nd
18:12:20 <stevemar> yeppers
18:13:02 <stevemar> i wonder if i'll be allowed to add the midcycle dates to the newton schedule.. guess i'll find out
18:13:30 <stevemar> i'll get http://releases.openstack.org/newton/schedule.html updated by eod
18:13:52 <morgan> stevemar: you should ask ttx :)
18:14:15 <stevemar> morgan: i'll find out when i include it in the patch :)
18:14:23 <morgan> hehe ok
18:14:35 <stevemar> #topic PTL back up
18:14:41 <ayoung> WFM
18:15:01 <stevemar> starting May 25th, i'll be out for 3-4 weeks, i don't think this is a surprise to most
18:15:24 <stevemar> jamielennox volunteers / i suckered him into it... to back me up
18:15:29 <stevemar> volunteered*
18:15:35 <ayoung> voluntold
18:15:40 <topol> wow exciting times!
18:15:47 <morgan> stevemar: OMG
18:15:52 <dstanek> ayoung: ++
18:16:02 <dstanek> stevemar: that's coming soon!
18:16:04 <stevemar> so just a heads up, i'll be transferring over the whip to him :)
18:16:28 <topol> I'll go find my men at work album to get ready
18:16:30 <ayoung> stevemar, any special permissions he's going to need, in order to unstuck things?
18:16:32 <stevemar> maybe a pinch of voluntold'ing
18:16:33 <edtubill> o/
18:16:34 <morgan> stevemar: i'll also volunteer to cver things while jamie is asleep
18:16:49 <stevemar> ayoung: see morgan's comment
18:16:52 <morgan> ayoung: nope. no special perms except stable branch things and doclph and i can handle that
18:16:53 <topol> thanks jamielennox and morgan
18:16:54 <shaleh> we are letting Jamie sleep?
18:17:01 <ayoung> I figured he still had the launch codes
18:17:20 <ayoung> Keystone team meeting moving ahead 8 hours.
18:17:22 <stevemar> i expect morgan and dolphm to help jamie when needed
18:17:45 <stevemar> i haven't asked them, i just assume these things
18:18:24 <stevemar> i don't think the meeting time will move, just jamie will have to wake up early
18:18:25 * morgan hasn't needed to fill in for stevemar much cause stevemar is mostly up late pacific time as well.
18:18:48 <stevemar> that's how i roll. in other timezones.
18:19:09 <stevemar> okie, next topic
18:19:13 <stevemar> any other q's?
18:19:17 <topol> just wait till every two hours becomes a timezone for you :-)
18:19:24 <shaleh> topol: ++
18:19:36 <stevemar> :)
18:19:39 <stevemar> #topic ldap and py3
18:20:14 <stevemar> at the summit, i asked why we don't just use pyldap instead of python-ldap (and not bother with ldap3)
18:20:23 <stevemar> the short answer was: we need ldappool too
18:20:42 <stevemar> i finally looked into it, the whole lib is only a few hundred lines
18:20:43 <morgan> do we?
18:20:46 <ayoung> stevemar, any reason to not do both?
18:20:52 <stevemar> ayoung: no
18:20:56 <morgan> because ldapool was *mostly* an eventlet solution
18:21:06 <morgan> we can hold onto normal connections etc now.
18:21:13 <ayoung> considering the mess that is the ldap code base, we would like to have the ldap3 style code cleanup
18:21:16 <stevemar> anyway, crinkle helped me out here, but we got ldap tests passing py3 https://review.openstack.org/#/c/311827/
18:21:19 <morgan> like one would with traditional python (multiprocess)
18:21:26 <ayoung> although, to be fair, the ldap code itself could be cleaned up with out that
18:21:53 <stevemar> the kicker is, we had to bring the ldappool code in-tree
18:22:00 <roxanaghe> ayoung, ++ for ldap3 :)
18:22:03 <morgan> eh, not the worst thing
18:22:07 <ayoung> can we drop ldappool?
18:22:11 <morgan> ldapool has pretty much be left dead.
18:22:16 <stevemar> since ldappool hasn't accepted any PR in years
18:22:17 <morgan> and i'm ok with carrying it locally.
18:22:21 <morgan> if we need it
18:22:23 <stevemar> ayoung: it has benefits
18:22:24 <ayoung> instead of bringing it in to the tree, just cut out using it?
18:22:34 <bknudson> where's the unit tests for ldappool?
18:22:35 <morgan> in fact, i'll even sign up to help maintain it if we need it
18:22:47 <stevemar> ayoung: i remember mfisch saying it netted him a nice gain
18:22:53 <stevemar> bknudson: i dind't pull those in tree yet
18:22:59 <stevemar> bknudson: this was just a poc
18:23:11 <morgan> also nice work stevemar and crinkle
18:23:19 <crinkle> :)
18:23:26 <stevemar> i'm not even sure if we can legally do this.... so i asked here: http://lists.openstack.org/pipermail/legal-discuss/2016-May/000404.html
18:23:43 <morgan> stevemar: what is the original license of ldappool? /me goes and looks
18:23:47 <bknudson> self.bacend = backend
18:23:52 <bknudson> they misspelled baconed.
18:23:58 <stevemar> bknudson: lol
18:24:05 <stevemar> mmm bacon
18:24:19 <morgan> stevemar: this can't be included like this in-tree iirc
18:24:23 <morgan> stevemar: this is MPL
18:24:25 <morgan> not APL
18:24:31 <stevemar> ::sadface::
18:24:36 <morgan> yep
18:24:40 <morgan> MPL/LGPL
18:24:43 <morgan> we can't do this like this
18:24:47 <morgan> we can fork/fix it
18:24:48 <dstanek> why do we need ldappool?
18:24:48 <bknudson> so somehow we'd need to get the author to agree to relicense.
18:25:04 <morgan> bknudson: nah, fork/fix and publish it again if we need.
18:25:15 <morgan> or we rewrite the parts we need.
18:25:24 <stevemar> dstanek: it nets real gains: http://www.mattfischer.com/blog/?tag=ldap
18:25:42 <morgan> stevemar: lets take this convo offline.
18:25:53 <morgan> i think i have some things to contribute to help on this front one way or another.
18:25:54 <stevemar> alrighty
18:26:06 <bknudson> we don't need ldappool if we switch to ldap3
18:26:07 <dstanek> stevemar: morgan: yes, i'd like to figure what we actually need here instead of carrying dead weight
18:26:09 <morgan> i'll bug you and crinkle later on and we'll figure it out.
18:26:15 <stevemar> bknudson: why not?
18:26:18 <morgan> and dstanek
18:26:26 <bknudson> ldap3 has connection pooling built-in.
18:26:31 <stevemar> bknudson: nice
18:26:40 <ayoung> "Finally I’m using the eventlet (keystone-all) vs apache2 to run Keystone."
18:26:47 <ayoung> lets drop pool
18:27:08 <stevemar> it would need a deprecation cycle
18:27:19 <stevemar> anyway, like morgan said, we can circle back to this topic
18:27:34 <morgan> stevemar, dstanek, crinkle: tossed a -2 on the current review for the MPL/LGPL, but saying this here so it doesn't halt work. we just *cant* import it like that.
18:27:35 <ayoung> stevemar, nope.  We can drop it for python3 only, no?
18:27:47 <morgan> not because it shouldn't be included.
18:27:56 <morgan> ayoung: that is hard to do.
18:28:09 <roxanaghe> stevemar, so are we decided to use pyldap instead of ldap3?
18:28:16 <stevemar> a big old six.PY3 wrap around everything
18:28:26 <stevemar> roxanaghe: not yet, just weighing the options
18:28:32 <stevemar> roxanaghe: we can have both
18:28:59 <stevemar> using pyldap would be a nice rip and replace of the existing code
18:29:03 <roxanaghe> stevemar, ok so nobody will shout at me if I continue to put up some patches with ldap3?
18:29:26 <stevemar> roxanaghe: of course not :)
18:29:41 <topol> morgan +++ keep the LGPL out :-)
18:29:57 <morgan> topol: i actually don't mind LGPL.
18:30:07 <morgan> but different convo for a different time
18:30:08 <dstanek> roxanaghe: nope, if you want to work on it they i say go for it
18:30:09 <roxanaghe> stevemar, pfew :)
18:30:25 <topol> morgan, perhaps over scotch in SFO
18:30:39 * topol yes I'll buy
18:30:42 <stevemar> topol: needs to happen before that :P
18:30:46 <stevemar> anyway
18:30:50 <stevemar> #topic Help update the API-ref site
18:30:51 <roxanaghe> dstanek, stevemar I just want to see how easy the unit tests code would be - replacing that fakeldap server would be a huge advantage for using ldap3
18:31:10 <stevemar> bknudson: do you know much about this?
18:31:17 <ayoung> roxanaghe, ++
18:31:20 <bknudson> a bit.
18:31:20 <stevemar> the API-ref site update-a-mania
18:31:31 <bknudson> they want to move the API-ref site off wadls and to RST
18:31:35 <stevemar> apparently the nova team is having a 2 day event for it
18:31:40 <bknudson> so sdague developed some sphinx plugins.
18:31:55 <bknudson> and there's a tool to convert WADL to RST
18:32:14 <bknudson> so someone needs to run the conversion and post the RST into keystone
18:32:31 <stevemar> "into keystone"?
18:32:32 <bknudson> probably just look at nova and see where it is.
18:32:37 <bknudson> openstack/keystone repo
18:32:54 <bknudson> or keystone-specs?
18:32:58 <stevemar> like this: https://github.com/openstack/nova/tree/master/api-ref/source ?
18:33:03 <bknudson> although I think the idea is to put it in keystone
18:33:08 <stevemar> we already have keystone-specs that has RST
18:33:29 <stevemar> looks different enough
18:33:33 <ayoung> We intentionally keeps specs separate from Keystone
18:33:33 <bknudson> the problem with keystone-specs is that it doesn't match what the server implements.
18:33:44 <ayoung> Keystone is the reference implementation of the identity API, but not the only
18:33:54 <bknudson> so for example we merged some specs that changed the API and then they didn't get implemented
18:34:00 <bknudson> so the API docs didn't match the server.
18:34:02 <stevemar> ah
18:34:07 <stevemar> i see
18:34:08 <dstanek> bknudson: yeah, specs are great to find design discussions, but not so much as documentation
18:34:15 <ayoung> disagree
18:34:17 <samueldmq> stevemar: I volunteer
18:34:29 <stevemar> samueldmq: thank you
18:34:31 <ayoung> there is a reason this is a human driven effort
18:34:32 <samueldmq> I was planning to start this work last cycle, but had some other priorities
18:34:39 <stevemar> samueldmq: do you have enough to get started?
18:34:50 <bknudson> samueldmq: put your name here: https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
18:34:52 <stevemar> samueldmq: you can ping annegentle or sdague i guess
18:34:52 <bknudson> (remove me)
18:35:02 <samueldmq> stevemar: I think so, I ask them if I need more clarity
18:35:05 <ayoung> the API spec is designed to be where we explain not just the values, but the intention. You can't automate that
18:35:05 <stevemar> and yeah, add your name to the wiki
18:35:06 <samueldmq> :)
18:35:07 <dstanek> samueldmq: there are ML threads about this topic too, if you haven't seen them
18:35:10 <ayoung> We'll end up with Javadocs
18:35:43 <bknudson> Ending up with docs like the java std library would be awesome.
18:35:49 * samueldmq nods
18:35:58 <ayoung> bknudson, that is not the same thing
18:36:24 <ayoung> bknudson, we'll end up with javadocs like most projects have that have one page per attribute with nothing explaining them.
18:36:28 <stevemar> ayoung: i think they are looking for a consistent representation of what "keystone" can do, and what APIs that openstack services support. consistent being key here. We're the only team that has the API in the specs repo
18:36:30 <dstanek> ayoung: i'm assuming you mean the amount of crap you can to put in code comments for tools?
18:37:01 <ayoung> dstanek, I mnean the amount of generated text you get from an API that is all boilerplate and no substance
18:37:20 <ayoung> bring dolphm in to this discussion, I hate arguing as his proxy
18:37:24 <henrynash> stevemar: ++ the current seperation of API spec is weird, and problematic
18:37:30 <ayoung> I mean, I agree with him, but he says it much better
18:37:33 <stevemar> ayoung: this looks nice to me: http://developer.openstack.org/api-ref-compute-v2.1.html
18:38:07 <bknudson> the result will look exactly like this: http://developer.openstack.org/api-ref-identity-v3.html
18:38:18 <bknudson> that's the point of the conversion tool is it looks the same as what we have.
18:38:37 <bknudson> except it's rst rather than wadls
18:39:14 <samueldmq> stevemar: ++
18:39:39 <samueldmq> api-guide explain the concepts, like what is role assignment, etc (scheduling for nova, eg)
18:39:50 <ayoung> So longas we keep our Current API docs too, and note the difference, it will probably be OK.
18:39:53 <samueldmq> while the api-ref gives a list of APIs and their details
18:40:20 <stevemar> samueldmq: thanks for volunteering
18:40:34 <bknudson> if we keep the current API spec then we'll have to maintain things in 2 places.
18:41:18 <stevemar> bknudson: ideally we keep one, i'd still like to see APIs proposed with specs
18:41:27 <samueldmq> stevemar: np, I like this kind of work :)
18:41:28 <stevemar> but maybe that is not a reality
18:41:30 <samueldmq> it's my pleasure
18:41:31 <bknudson> the reason nova is having a multi-day sprint is because their API docs were so out of sync with the implementation
18:41:56 <henrynash> stevemar: we have to strive for one and one only
18:42:18 <stevemar> henrynash: and the api-ref site seems to be winning that battle
18:42:29 <henrynash> stevemar: agreed
18:42:47 <ayoung> MEH.
18:43:16 <ayoung> henrynash, your next
18:43:18 <stevemar> #topic
18:43:21 <stevemar> fail
18:43:25 <stevemar> #topic Relaxing project name constraints
18:43:26 <ayoung> #topic Relaxing project name constraint
18:43:29 <stevemar> henrynash: ^
18:43:30 <henrynash> ok
18:43:43 <stevemar> #link https://review.openstack.org/#/c/310048/
18:43:55 <ayoung> henrynash, YAY!
18:43:56 <henrynash> so this is something we have talked about in the past
18:44:13 <bknudson> time to relax
18:44:17 <ayoung> henrynash, we are only going to do that if the "strict" thing is on?
18:44:20 <henrynash> now that we have hierarchies, our “project name must be unique across the whole hiearcy” seem weird
18:44:24 <henrynash> ayoung: yes
18:44:31 <ayoung> ++
18:45:09 <stevemar> i thought the whole "strict" thing was in regards to project ids?
18:45:26 <henrynash> basically I’d like people’s feed back on teh consequences of this….for instance, should we return a project path wherever we have a name today? or only when we really really need to
18:45:35 <henrynash> stevemar: no, name
18:45:36 <dstanek> henrynash: yeah, that seems to not be inline with the reseller usecase
18:45:41 <ayoung> Anyone not think that this is the obvious right thing to do?
18:45:46 <henrynash> stevemar: no, it’s names
18:45:48 <morgan> henrynash: i am still against this.
18:46:03 <dstanek> henrynash: so it would always be a project path for the name?
18:46:10 <gyee> it violates the v3 spec, which states projects within a domain must be unique
18:46:15 <morgan> gyee: exactly
18:46:21 <henrynash> gyee: yes, we are changing the spec
18:46:24 <morgan> henrynash: unless we move to microversions, i'm a -2 on this
18:46:25 <rodrigods> but they are
18:46:27 <rodrigods> unique
18:46:29 <gyee> keystone v4?
18:46:32 <morgan> it violates api stability
18:46:35 <morgan> or keystone v4
18:46:38 <anteaya> I'm feeling there might be problems with other projects
18:46:43 <gyee> that was a fundamental requirement for v3
18:47:12 <dstanek> i don't understand how users would know what to pass or how we would know if they are passing path or name
18:47:15 <amakarov> there are still projects stuck on v2.0
18:47:22 <henrynash> so my request is, read the spec, where I go through al lteh issues you raise, and give feedback
18:47:36 <gyee> henrynash, yes sir, will do
18:47:51 <ayoung> v3.14
18:48:04 <gyee> 3.14159
18:48:19 * morgan has put a comment on the spec
18:48:22 <morgan> and a -2.
18:48:22 <henrynash> dstaneK: I agree - one issue (in a multi cloud scenario) - is how do you knwo if a particuar cloud has this (optional) cap abilit enabled
18:48:23 <morgan> sorry.
18:48:39 <ayoung> morgan, how would microversions help?  Can you walk through that, cuz if it does, I am all for them
18:48:44 <morgan> however, i think this is a case where microversion inclusion is the correct path going forward
18:48:48 <henrynash> morgan: as long as you describe why (in exact terms), then I can respond
18:48:53 <morgan> henrynash: i did.
18:49:21 <morgan> ayoung: if we move towards microversions we can lock out duplicated names (i think)
18:49:40 <morgan> ayoung: so we only support specific domains / hierarchies under the new microversion?
18:49:56 <gyee> this is one area we cannot fuck up as keystone auth is also part of defcore
18:50:05 <ayoung> morgan, so that is what we were going for with the config option.  Does a microversion mean a version on a subset of the API?
18:50:07 <morgan> ayoung: i think*. but lets be fair, we can't break the contract that names are unique without exploring the right path forward.
18:50:21 <morgan> ayoung: i'd follow nova's template
18:50:29 <morgan> ayoung: for how the microversion works.
18:50:32 <morgan> tbh
18:50:39 <ayoung> morgan, can we get the cliff notes version?
18:50:48 <ayoung> I tried following the mailing list and it was a swarm
18:50:55 <ayoung> never got to what they landed on
18:50:56 <morgan> ayoung: entire api is microversioned
18:51:00 <morgan> afaik
18:51:13 <ayoung> so any minor change gets a minor version bump?
18:51:20 <lbragstad> yeah
18:51:22 <morgan> but it is negotiated explicitly in the client
18:51:26 <bknudson> microversioning is not semver
18:51:34 <morgan> so the client would say "i use ver 22 of the the API"
18:51:41 <morgan> and get ver 22 semantics
18:51:41 <bknudson> the number just keeps going up
18:51:50 <morgan> it is monotonically increasing
18:51:50 <bknudson> and they can break whatever they want in a new version
18:51:51 <ayoung> what if....
18:51:55 <ayoung> ok heres a thought
18:52:02 <morgan> bknudson: not "whatever" but. yes much more flexible
18:52:05 <thingee> and there has not been thoughts on when we stop supporting older versions.
18:52:10 <ayoung> suppose we say that you create with the short name, but then we tell you the long name
18:52:13 <topol> does that end up creating lots of technical debt.. supporting lots of versions??
18:52:41 <ayoung> so if you create with "BAR"  but put it under "BAR" you get projectname="FOO/BAR"
18:52:50 <gyee> s/technical debt/jobs for america/
18:52:55 <dtroyer> topol: yes.  the thought has been to periodically raise the oldest supported version but it has not happened in practice yet
18:52:57 <morgan> ayoung: possivle.
18:53:00 <morgan> possible*
18:53:18 <henrynash> morgan: so does ANY chaneg of the API have to be versioned using this method (e.g. we have a config option that , if set, means you can’t use reserved chars in a project name….is that “breaking” the api?)?
18:53:20 <morgan> cburgess: ^ cc (see dtroyer's comment) re convo we had about microversions
18:53:25 <ayoung> and then the new thing is "short_name" or something that is additive to the API instead of changing the meaning....
18:53:38 <bknudson> trump would say to just default on our technical debt.
18:53:42 <morgan> henrynash: yep. though the reservation of characters is likely an easier change microversion wise.
18:53:45 <stevemar> bknudson: lol
18:53:51 <ayoung> bknudson, we can always print more code
18:53:58 <cburgess> morgan dtroyer makes sense and I suspect will be inevitable
18:54:12 <morgan> henrynash: if it is breaking the stable contract it needs a way to address such as microversions
18:54:20 <morgan> this is a proposed break of the stable contract.
18:54:20 <topol> dtroyer, reminds me how everyday in Austin stevemar ordered greater amounts of BBQ poundage at Coopers
18:54:22 <ayoung> morgan, OK, so can we take your -2 as "this must depend on microversions?"
18:54:35 <lbragstad> bknudson i think he'd just try and declare bankruptcy for tech debt
18:54:39 <morgan> ayoung: yes. it needs to address not breaking the stable contract
18:54:45 <morgan> once we have a way forward, my -2 is lifted
18:54:52 <henrynash> morgan: ok. fair enough!
18:54:57 <morgan> ayoung: and i commented as such with the -2 :)
18:55:05 <stevemar> henrynash: you've got some spec'ing to do
18:55:05 <lbragstad> 5 minutes left
18:55:11 <morgan> the stable contract is the *only* reason i'm -2 on this fwiw.
18:55:39 <morgan> i think it is 100% reasonable.
18:55:40 <ayoung> the thing is, this is more liberal than what we have now.  So we would not break existing deployments, but that is not what you are saying, is it
18:55:40 * topol wondering how much code it takes to implement a microversion framework...
18:55:57 <henrynash> stevemar: (separate subject) I have one BP that I think doesn’t need a spec: https://blueprints.launchpad.net/keystone/+spec/domain-config-as-stable
18:56:07 <morgan> ayoung: it would change the behavior in a way that is not consistent with our current v3 api
18:56:14 <stevemar> cool, i'll add it to the pile
18:56:19 <morgan> ayoung: that is the concern. more liberal or less, it is still a contract brack
18:56:21 <morgan> break*
18:56:28 <henrynash> stevemar: not sure when we look at those
18:56:34 <stevemar> henrynash: definitely doesn't need a spec
18:56:43 <ayoung> morgan, so a user needs to be able to query to know which contract is in effect?
18:56:54 <dtroyer> topol: Nova has started extracting carefully-selected bits into a lib for doing the hard part, the negotiation…
18:56:55 <morgan> ayoung: yes. (or the client at least)
18:56:55 <bknudson> the user specifies.
18:57:08 <morgan> bknudson: ++
18:57:10 <morgan> dtroyer: nice.
18:57:15 <morgan> dtroyer: that would be good for us.
18:57:18 <ayoung> bknudson, what does tht mean?
18:57:23 <henrynash> ayoung: maybe more than one contarct is avalable, I would think the client gets to chose which one we can work with (maybe none)
18:57:34 <morgan> bknudson: if the client doe not specify a version, it gets the baseline version
18:57:35 <bknudson> ayoung: the client always says what version it is.
18:57:42 <morgan> s/ bknudson / ayoung
18:57:46 <topol> dtroyer Cool Thanks!
18:58:13 <morgan> bascially it is up to the client to say what it can support, or it gets the most basic interface
18:58:13 <ayoung> hmm...not sure that global unique and non-unique can co-exist in the same API
18:58:14 <stevemar> i think we're just about done here
18:58:21 <bknudson> I haven't seen how microversions work with the openstack cli.
18:58:35 <morgan> ayoung: we may need to work through some other details (reserved characters? or something else)
18:58:38 <stevemar> bknudson: shhh... don't mention that, it's a touchy subject
18:58:50 <henrynash> fine request: on the proejct names, please do review the other aspects of teh spec - even if we may need to microverion this….
18:58:52 <morgan> ayoung: but if we solve the api contract break, my -2 goes away.
18:58:58 <dtroyer> bknudson: we support setting the header, but not much more than that yet
18:59:15 <bknudson> or how they implemented it in their client API
18:59:16 <morgan> ayoung: and i am generally in favour of the change.
18:59:18 <ayoung> morgan, so if the name is always the full path, the names are always unique.
18:59:42 <ayoung> So I think we should focus on a way to to the path naming without an API break?
19:00:02 <stevemar> we're at time
19:00:05 <stevemar> #endmeeting