18:01:30 <morganfainberg> #startmeeting Keystone 18:01:31 <openstack> Meeting started Tue Dec 2 18:01:30 2014 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:34 <openstack> The meeting name has been set to 'keystone' 18:01:48 <morganfainberg> #topic Kilo-1, December 18th 18:01:54 <morganfainberg> #link https://launchpad.net/keystone/+milestone/kilo-1 18:02:18 <morganfainberg> please let me know if anything is missing. i'm going to start marking bugs/etc as blockers (see dolph's link in the -keystone channel) 18:02:29 <morganfainberg> #link https://gist.github.com/dolph/651c6a1748f69637abd0 18:02:44 <morganfainberg> also please let me know if anything is slipping to K2. 18:03:16 <rodrigods> just seeing HM there makes me happy :) 18:03:37 <morganfainberg> i need a +a on the merge patch, but it's otherwise ready to go to master rodrigods 18:03:49 <ayoung> morganfainberg, +a from whom? 18:03:52 <rodrigods> morganfainberg, great, rebasing it right now 18:03:55 <morganfainberg> ayoung, a core. 18:03:58 <ayoung> link? 18:04:09 <morganfainberg> ayoung, https://review.openstack.org/#/c/138186/ 18:04:27 <ayoung> done 18:04:32 <morganfainberg> i can (of course) do it, but prefer to not +A my own patch. even as simple as this one is. 18:04:55 <ayoung> I had looked at it before, and it had 2 other +2s.... 18:05:02 <morganfainberg> #topic Review Specs 18:05:05 <morganfainberg> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs,n,z 18:05:11 <morganfainberg> we have been good about this 18:05:14 <morganfainberg> keep it up! 18:05:35 <rodrigods> the policy enforcement library spec, will address stevemar comments as soon as I finish the HM stuff today 18:05:37 <morganfainberg> k2 is the spec approval deadline, if anyone is working on specs, make sure they're in by k2 (earlier than k2 is better) 18:05:48 <ayoung> ++ 18:05:54 <stevemar> eek! 18:06:07 <morganfainberg> rodrigods, ping me when you're ready on that i'll help with the launchpad etc side of things 18:06:17 <ayoung> K2 is when? Last week of January? 18:06:36 <morganfainberg> ayoung, Feb 5 18:06:45 <morganfainberg> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 18:06:45 <stevemar> oh before k2 ENDS, that's better 18:06:45 <stevemar> https://wiki.openstack.org/wiki/Kilo_Release_Schedule 18:06:46 <jamielennox> rodrigods: i've got some things i want to discuss regarding policy enforcement, i had a ML thread a few days ago which covers most of it 18:06:53 <rodrigods> morganfainberg, thank you 18:06:53 <rodrigods> ayoung, february 18:07:00 <morganfainberg> #info K2 is spec approval deadline without an explicit exception. 18:07:27 <rodrigods> jamielennox, I saw it, didn't comment because the oslo.context bits, which I'm not familiar yet 18:07:37 <morganfainberg> that is part of the reason we're having the mid-cycle 2 weeks prior to K2. 18:07:44 <jamielennox> rodrigods: yea, need to talk to dhellmann and figure that part out 18:07:44 <morganfainberg> so we can discuss any last minute things. 18:07:45 <rodrigods> jamielennox, maybe we should include the details in the policy enforcement library spec? 18:07:57 <morganfainberg> i should have more details on exact venue soon™ 18:08:07 <dolphm> =) 18:08:10 <morganfainberg> but dates and city are confirmed 18:08:20 <topol> morganfainberg Yay!!! 18:08:22 <jamielennox> rodrigods: it shouldn't matter to the spec i think, just need to figure out an interface for this auth object 18:08:27 <morganfainberg> (will not be changing short of texas falling into the ocean) 18:08:32 <rodrigods> jamielennox, hmm 18:08:33 <dstanek> i shall book a flight then 18:08:52 <dolphm> we have two venue choices downtown, just trying to figure out which is best 18:09:03 <morganfainberg> and last i heard it was only california that was going to fall into the ocean. 18:09:05 <morganfainberg> :P 18:09:06 <lbragstad> both Geekdom? 18:09:08 <dstanek> if it falls into the ocean i'll book a boat 18:09:11 <morganfainberg> dolphm, ++ :) 18:09:11 <dolphm> yes 18:09:14 <topol> alamo basement? 18:09:23 <dolphm> Different buildings though 18:09:36 <morganfainberg> dolphm, so downtown for sure? any hotel info (e.g. should i send them to you?) 18:09:44 <dstanek> dolphm: so Valencia is probably still a good bet for either location, right? 18:09:53 <morganfainberg> i can update the post recommending a hotel / send to ML. 18:09:57 <topol> they had a nice bar 18:09:58 <ayoung> Can we just camp out in a vacant part of Rackspaces shopping mall? 18:10:35 <morganfainberg> and add the RSVP form 18:10:39 <morganfainberg> actually 18:10:39 <ayoung> seriously, though, are we targetting the same hotel as last time? 18:10:41 <lbragstad> I have yet to find a *vacant* part... 18:10:42 <ayoung> Valencia? 18:10:43 <morganfainberg> #topic Midcycle 18:11:23 <dolphm> morganfainberg: no hotel info yet, sorry 18:11:31 <dolphm> but yes, downtown looks to be for sure 18:11:34 <morganfainberg> #action Dolphm to determine final venue, downtown San Antonio is the place. 18:11:43 <morganfainberg> #info Hotel info pending. 18:11:53 <dolphm> ayoung: if i can get a group code, which seems challenging this go round 18:11:55 <joesavak> #hotelinfo pending 18:12:23 <morganfainberg> dolphm, hopefully we can. 18:12:23 * ayoung calls dibs on joesavak 's couch 18:12:44 <stevemar> isn't that couch not in san-antonio? 18:12:49 <joesavak> ayoung - it's in austin 18:12:57 <morganfainberg> eh, a couple hour drive 18:12:57 * joesavak calls dibs on dolphm's couch 18:12:59 * ayoung also calls shotgun 18:13:01 <stevemar> i call dibs on lbragstad's couch 18:13:06 <topol> ayoung, lets take dolphm to Red Lobster. Its just as good as what we got in Boston 18:13:10 <lbragstad> my dogs love company. 18:13:22 <dolphm> lol 18:13:23 <ayoung> topol, go for it....I think I'm busy that nioght 18:13:42 <morganfainberg> topol, bait and switch... tried and true tecnique.. 18:13:49 * ayoung has vowed not to bother with lobster outside of the northeast 18:14:11 <morganfainberg> ok. moving on. 18:14:21 <ayoung> jamielennox, have you priced tickets? I'm guessing it is not really an option, but might as well look 18:14:35 <morganfainberg> i'll get the real RSVP link up as soon as we have hotel confirmed for a discount block or not. 18:14:59 <morganfainberg> #topic Next Week Meeting 18:15:14 <morganfainberg> I will be unavailable (meeting with folks in Austin, tx) 18:15:24 <morganfainberg> i need someone to chair this meeting *or* we can skip. 18:15:49 <jamielennox> ayoung: no, leaving the mid-cycle, would prefer to put the budget in getting to summit 18:15:51 <lbragstad> do we have anything on the agenda for next weeek? 18:15:51 <dolphm> #notme 18:16:02 <morganfainberg> similar, will need somene to cover the cross-project meeting as 2100utc 18:16:08 <ayoung> spec reviews! 18:16:12 <morganfainberg> lbragstad, no agenda yet. 18:16:20 <stevemar> sounds like lbragstad wants to do it 18:16:20 <henrynash> sadly I can’t make next either 18:16:27 <topol> we could reuse the hour for spec reviews (honor system) 18:16:27 <bknudson1> jamielennox: realize we get more done at the mid-cycle than the summit 18:16:45 * joesavak 2nds lbragstad voluntolding 18:16:52 <morganfainberg> bknudson1, that may be the case, but it's more important to have the cores @ the summit. 18:16:59 <morganfainberg> if we have to pick one. 18:17:02 * lbragstad rolls around under the bus. 18:17:02 <dstanek> joesavak: ++ 18:17:18 <ayoung> jamielennox, price the ticket. It might not be either/or 18:17:20 <topol> run faster next time lbragstad 18:17:27 <dstanek> lbragstad: it takes skill to drive the bus that runs you over 18:17:31 <morganfainberg> dstanek, lbragstad, bknudson1, one of you cover the crossproject meeting? 18:17:37 <jamielennox> bknudson1: yea, and i always regret missing it 18:17:37 <jamielennox> ayoung: ok, 18:17:39 <morganfainberg> i'm more concerned about having someone there. 18:17:46 <dstanek> morganfainberg: sure. 18:17:50 <morganfainberg> dstanek, thanks. 18:17:58 <morganfainberg> 2100utc in #openstack-meeting 18:17:58 <lbragstad> dstanek: so, that'd be stevemar? 18:18:27 <morganfainberg> #action dstanek covering cross-project meeting on dec 9 18:18:32 <dstanek> morganfainberg: is there a specific agent we are pushing? or just be there to make sure things don't go wrong? 18:18:35 <stevemar> haha 18:18:44 <morganfainberg> dstanek, just be there in-case keystone questioons come up 18:18:56 <morganfainberg> should be minimal if *anything* 18:18:59 <joesavak> then reply "ask morgan" 18:19:08 <gyee_> and take the blames if you have to 18:19:17 * morganfainberg looks to see if the bus can swerve for joesavak next. 18:19:22 <morganfainberg> ;) 18:19:25 <joesavak> :) 18:19:26 <topol> or "morgan said no problem" 18:19:36 <morganfainberg> topol, ............ 18:19:40 <joesavak> 2 buses for topol 18:19:51 <dstanek> gyee_: i'll just say 'Morgan disagrees' if they try to place blame 18:19:54 <morganfainberg> ok, thats it for today, so... 18:19:59 <morganfainberg> #topic Open Agenda 18:20:30 * ayoung has so many irons on the fire, does not know which to pick from 18:20:41 <ayoung> HMT ir priority 18:20:43 <henrynash> morganfainberg, rodigods: maybe one of you just wants to lay out teh plan for merging HM? 18:20:44 <morganfainberg> ayoung, theire all specs! 18:20:46 <ayoung> HMT is priority 18:21:01 <gyee_> is anyong actively working on the segregating the service admin spec? 18:21:06 <rodrigods> yeah, working in the rebase right now 18:21:13 <gyee_> if not, I'll write it up 18:21:18 <ayoung> do we want to enforce the rule that, for the root project in a domain, projectid == domainid? 18:21:19 <rodrigods> in the last patch already :) 18:21:19 <morganfainberg> henrynash, master merge going now. then it's between you and rodrigods to order split vs the next patches for HMT 18:21:44 <morganfainberg> henrynash, unless you need me to step in and make a call, which i can. 18:22:04 <morganfainberg> henrynash, but i figure you two know the respective pain of rebaseing both patches better. 18:22:08 <henrynash> morganfainberg: might that be why jenkins is failing everyone for keystone? 18:22:19 <lbragstad> I was wondering about that... 18:22:23 <morganfainberg> henrynash, hm? jenkins is failing? 18:22:25 <bknudson1> jenkins is failing? 18:22:28 <ayoung> So to test if a given project is a domain, we do if project.id == project.domain_id: 18:22:34 <morganfainberg> oh. there is a nasty bug 18:22:38 <lbragstad> my XML removal patch passed all tempest things... 18:22:40 <henrynash> morgainfainberg: https://review.openstack.org/#/c/130954/ 18:22:41 <jamielennox> so i have a review for keystoneclient that is somewhat breaking compatibility that i want to do anyway: https://review.openstack.org/#/c/138228/ 18:22:51 <morganfainberg> https://bugs.launchpad.net/hacking/+bug/1398472 18:22:53 <uvirtbot> Launchpad bug 1398472 in oslo.concurrency "H302 isn't handling oslo_concurrency namespace change" [Undecided,New] 18:23:13 <henrynash> ahh 18:23:16 <morganfainberg> that hit nova, ironic, and us for sure. 18:23:32 <bknudson1> should have expected gate failures with the release of all the olso libs 18:23:35 <henrynash> glad it wasn’t us, then! 18:23:52 <morganfainberg> henrynash, yeah fairly certain it wasn't us. 18:24:24 <morganfainberg> henrynash, http://logs.openstack.org/54/130954/28/check/gate-keystone-python27/211eedb/console.html#_2014-12-02_17_19_32_856 18:24:47 <lbragstad> morganfainberg: do we need a change for disabling h302? 18:25:02 <morganfainberg> lbragstad, i *think* it's a bigger issue. 18:25:37 <morganfainberg> lbragstad, oslotest *cant* install afaick 18:25:40 <morganfainberg> afaict* 18:25:57 <morganfainberg> so, nothing we can do, not even getting there. 18:26:09 <dolphm> jamielennox: how is it breaking? 18:26:26 <morganfainberg> oslo and infra are working on it henrynash, lbragstad 18:26:31 <lbragstad> https://review.openstack.org/#/c/138462/2 18:26:40 <henrynash> morganfainberg: great 18:26:48 <lbragstad> looks like nova tried getting around it with ignoring h302 18:26:58 <lbragstad> and pinning the o-c requirements, 18:27:01 <morganfainberg> lbragstad, different issue it looks like 18:27:04 <lbragstad> yeah 18:27:16 <morganfainberg> jamielennox, not sure how that is breaking things. 18:27:23 <morganfainberg> jamielennox, erm breaking compat. 18:28:00 <ayoung> morganfainberg, jamielennox 's change now does not allow things that would have snuck throuhg in the past 18:28:08 <bknudson1> if it's breaking backwards compatibility then seems like there should be a test broken or a docstring update... 18:28:10 <morganfainberg> ah 18:28:24 <morganfainberg> i don't think we can do that jamielennox 18:28:26 <dolphm> jamielennox: if it is breaking, the commit message should at least detail that 18:28:31 <ayoung> bknudson1, it was never something we explicitly allowed, just didn't forbid 18:28:47 <morganfainberg> we might *need* to just capture the kwarg and warn "you're doing it wrong, don't do this"? 18:29:09 <morganfainberg> or i agree with dolphm, at least reference it in the commit. 18:29:34 <bknudson1> but the code didn't honor service_type or interface before? 18:29:36 <ayoung> so passing management_url to a client create will now break. 18:29:54 <morganfainberg> i'm inclined to say don't break that. 18:30:02 <bknudson1> oh, it's passing kwargs on when they were ignored before? 18:30:36 <morganfainberg> oh. oh i see. 18:30:40 <morganfainberg> uhg. 18:30:47 <jamielennox> bknudson1, morganfainberg: right, so we used to just take **kwargs and ignore everything we didn't understand - i've no idea why we every thought that would be a good idea 18:31:24 <morganfainberg> jamielennox, related note - openstack-sdk vs incompatible client releases at the project meeting at 2100utc. 18:31:38 <morganfainberg> jamielennox, if you want to join [i know, time difference is hard] 18:31:48 <jamielennox> ayoung: right - but management_url is not a valid kwarg - it didn't used to do anything it just got ignroed 18:31:55 <jamielennox> which is part of the reason i think we should do it anyway 18:32:05 <ayoung> jamielennox, what happened before the adapter code went in? 18:32:16 * morganfainberg dislikes **kwargs for this very reason. 18:32:31 <jamielennox> ayoung: management_url would get ignored 18:32:34 <ayoung> jamielennox, the only arg I really need is auth 18:32:44 <bknudson1> what new args are supported now? 18:32:45 <ayoung> could we make that explicit, and ignore the rest for now? 18:32:55 <bknudson1> (trying to figure out why we need to make this change? 18:32:59 <ayoung> maybe some sort of warning 18:33:02 <jamielennox> ayoung: right, but i wrote this so that i could add parameters to adapter and have those automatically supported by all clients 18:33:02 <ayoung> bknudson1, OK, here is why 18:33:27 <jamielennox> i would like to have keystoneclient work the same way rather than have to add a new param to httpclient.__init__ every time i add one to adapter 18:33:33 <ayoung> in Horizon, we need to have the KC session be a global object (well, need is stoo string a word...it should be global) 18:33:33 <bknudson1> ok, it's auth= 18:33:52 <ayoung> the client is request scoped, and the auth plugin is scoped to the Horizon users session 18:34:00 * ayoung is aware that naing is a little funky 18:34:02 <jamielennox> bknudson1: auth= is the one that is a problem for now 18:34:03 <ayoung> naing 18:34:06 <ayoung> naming 18:34:15 * ayoung thinks his m key is getting dead 18:34:30 <ayoung> jamielennox, are there other parameters we need? 18:34:47 <bknudson1> ayoung: why were you passing an extra parameter before? 18:34:53 <jamielennox> ayoung: the list is growing: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/adapter.py#L29 18:35:00 <ayoung> bknudson1, trial and error, I think. 18:35:01 <morganfainberg> bknudson1, because he could and it didn't complain. 18:35:07 <jamielennox> i would like to allow specifying interface to start getting us off using admin 18:35:16 <ayoung> ++ 18:35:49 <jamielennox> endpoint_override and retries etc would be useful, not hugely required, but i want to standardize this 18:36:21 <jamielennox> i would ideally like to have a similar set of get_options() on the adapter so we can do a generic client.load_from_conf_options(CONF) 18:36:22 <gyee_> timing? 18:36:26 <bknudson1> the argument could be made that maybe nobody's taking advantage of the ignored paramters but then we have an example already where somebody was using it. 18:36:47 <jamielennox> gyee_: timing can/should be extracted from the requests.Response 18:36:56 <morganfainberg> jamielennox, have we had a release where we ignored the params? 18:37:02 <morganfainberg> a release of ksc that is 18:37:06 <bknudson1> there could be another argument use_kwargs=False 18:37:09 <jamielennox> morganfainberg: i'm pretty sure 18:37:16 <bknudson1> that they have to pass to use the new behavior 18:37:17 <morganfainberg> if we have, i'm going to say we can't break this. 18:37:40 <morganfainberg> you can either do what bknudson1 ^ just said, or will need to find another way to avoid breaking this. 18:38:57 <jamielennox> damn it was me: https://github.com/openstack/python-keystoneclient/commit/1263bd7c3a8ccded3cef7c799a2f8c744fb79aa2 18:39:18 <ayoung> jamielennox, I hate when I find I've done that 18:39:21 <morganfainberg> jamielennox, commented on the review with a -1. 18:39:36 <morganfainberg> "WHO WROTE THIS CR... oh it was me... " 18:40:14 <bknudson1> there's not too many others changing keystoneclient 18:40:24 <jamielennox> just want to scrap this client, managing compatibility everywhere is just getting too hard 18:40:44 <bknudson1> let's start on python-keystoneclient2 18:40:52 <gyee_> heh 18:41:34 <morganfainberg> bknudson1, we'll be discussing this topic in the cross-meeting proj...i mean cross-project meeting 18:41:49 <jamielennox> bknudson1: i've been trying not to but i think that might be the way to go 18:42:31 <gyee_> what happen to common sdk? 18:42:44 <jamielennox> gyee_: it's still around, and they're still working on it 18:42:45 <morganfainberg> gyee_, that is part of the topic 18:42:51 <morganfainberg> for the meeting 18:42:51 <gyee_> ah 18:42:58 <morganfainberg> swift is asking the same question(s) we are. 18:43:06 <jamielennox> i'd like to say we're but i haven't done much for a while now 18:43:17 <gyee_> morganfainberg, common sdk and client makes a lot of sense 18:43:38 <jamielennox> gyee_: they do - which is part of why i've held of ksc2 18:43:51 <bknudson1> when the common sdk was proposed the idea was to have a higher-level api 18:43:56 <lbragstad> FYI, https://bugs.launchpad.net/hacking/+bug/1398472 should be fixed with hacking 0.9.4 18:43:57 <uvirtbot> Launchpad bug 1398472 in oslo.concurrency "H302 isn't handling oslo_concurrency namespace change" [Undecided,New] 18:44:24 <mordred> all clients make me angry 18:44:24 <jamielennox> bknudson1: right, so it provides the higher level, but it will contain the lower level 18:44:50 <jamielennox> i just don't know if it's going to provide things like our CMS wrappers and such or whether there will always be a need for a ksc in parallel 18:45:24 <jamielennox> mordred: ++ 18:45:25 <bknudson1> I wouldn't expect an SDK to include CMS wrappers. 18:45:27 <morganfainberg> mordred, was wondering when you'd step in on the topic of clients ;) 18:46:01 * mordred just wants to use the cloud ... 18:46:17 <stevemar> just do these 18 things first 18:46:25 <morganfainberg> stevemar, this one wierd thing. 18:46:31 <gyee_> isn't barbican folks working on the crypto API which can replace the CMS wrappers? 18:46:31 <jamielennox> i tried to add sessions to the glance client, need to build up some will first 18:46:32 <morganfainberg> stevemar, cloud deployers hate him. 18:46:33 <ayoung> termie had a really sweet approach as I recall 18:46:40 <stevemar> and then you're good! 18:47:14 <jamielennox> ayoung: termie essentially proposed a rewrite to OSC if i recall, not so much a client pattern 18:47:16 <gyee_> I was under the impression that we can use the python crypto APIs soon 18:47:29 <ayoung> https://github.com/termie/ocl 18:47:39 <bknudson1> I think the issue that mordred points out is he really doesn't want to deal with the REST API, but wants to work at a higher level 18:47:52 <morganfainberg> bknudson1, and that is completely reasonabler 18:47:55 <topol> let me guess ocl is awesome and about 15% complete 18:48:21 <ayoung> 12% 18:48:27 <ayoung> topol, it was a long time ago 18:48:43 <ayoung> Commits on Feb 18, 2014 18:49:04 <morganfainberg> and a lot of the code termie did around hong-kong summit time. 18:49:04 <bknudson1> so for admins and devs the low-level apis are necessary but then there's users that just want to boot an instance... openstack.boot_my_instance() 18:49:39 <bknudson1> and maybe that's supposed to be heat. 18:49:46 <mordred> https://github.com/emonty/shade 18:49:49 <ayoung> I was thinking solum, actually 18:50:05 <gyee_> bknudson1, but we still have to do the dirty work of setting up the session upfront 18:50:19 <jamielennox> bknudson1: right - so the problem with sdk and i assume the topic of the meeting is what levels of support will they give, and so far the answer has been everything 18:50:23 <ayoung> Start by finding anything in Horizon that is busnesslogic-y and pull it out to its own service 18:50:28 * mordred does not need heat or solum 18:50:47 * mordred just wants to be able to use the cloud and not know things about how it was deployed 18:51:05 <topol> mordred, come on... they are Buy one get one free :-) 18:51:10 <mordred> topol: :) 18:51:18 <morganfainberg> mordred, i'd argue that is what *heat* should have been. but that ship has long since sailed. 18:51:21 <bknudson1> I'm sick of hipster deployers! 18:51:33 <jamielennox> mordred may have a problem with openstack rather than just the clients 18:51:49 <ayoung> mordred, everything sucks if you work with it long enough 18:51:51 <mordred> jamielennox: I may very well have a problem with openstack 18:51:56 <ayoung> then you find a replacement and it is all shiny 18:52:07 <ayoung> then you work with it and find it sucks, just in different ways 18:52:39 <ayoung> OK, I think we' 18:52:41 <ayoung> re done 18:52:42 <morganfainberg> ayoung, *something something* go library that doesn't handle regions *something something* 18:53:03 <morganfainberg> ok we can continue this in openstack-keystone, jamielennox come to the cross-project meeting if you can. 18:53:21 <morganfainberg> i floated the idea we'd do a incompatible ksc, but lets see where SDK is officially 18:53:48 <morganfainberg> and the incompat ksc would be to play massive cleanup so it would be easier to layer things like what mordred wants w/o the old compatibility cruft 18:53:50 <bknudson1> what's in the incompatible ksc? 18:53:56 <gyee_> I was hoping *common* will get us maturity, better UX, and consistency 18:54:20 <jamielennox> morganfainberg: ok, yea - i doubt i'll make it to that meeting - if i don't someone mention that keystoneclient is officially a POS and we're torn between just starting again with our fancy new common layer or waiting for sdk 18:54:21 <morganfainberg> bknudson1, drop cli, drop anything we don't need, and fix the interfaces we messedup/are carrying massive tech debt to make sure we don't break grizzly clouds 18:54:36 <morganfainberg> bknudson1, etc 18:54:45 <jamielennox> bknudson1: i wouldn't expect to change the general library layout 18:54:59 <morganfainberg> bknudson1, basically, draw a line in the sand, this is incompatible going forward we shall call it tim. 18:55:09 <jamielennox> client.resource.action etc is fine, can argue the points 18:55:30 <jamielennox> but in general most of the CRUD stuff would be at least similar - just hopefully sane 18:56:00 <morganfainberg> it lets us take what we have and break the stuff we normally couldn't break. 18:56:06 <jamielennox> like not taking all arbitrary **kwargs and assuming that they're query params 18:56:06 <morganfainberg> thats the point of it. 18:56:09 <gyee_> jamielennox, but CRUD stuff is not the problem 18:56:09 <bknudson1> is openstacksdk going in the right direction? 18:56:16 <jamielennox> gyee_: right 18:56:24 <morganfainberg> bknudson1, that is part of what we're looking to find out in the meeting today 18:56:33 <morganfainberg> bknudson1, because i'm just as happy to say "use SDK" 18:56:42 <bknudson1> I don't think anything's stopping us today from developing a higher-level API on top of existing keystoneclient APIs 18:56:45 <morganfainberg> it's a question of where do we focus. 18:57:00 <mordred> morganfainberg: I'd be perfectly happy with the existence of a ksc2 as long as it supports the rest apis of the clouds I use 18:57:04 <bknudson1> but if we need something that works cross-project we need a new api 18:57:05 <morganfainberg> bknudson1, some of it is really painful due to how the clients are architected. 18:57:08 <mordred> just for the record 18:57:11 <morganfainberg> mordred, ++ 18:57:15 <jamielennox> gyee_: but it would be a good time to do additional things like - "hey create is not supported on that resource so lets not expose the function in client" 18:57:26 <morganfainberg> bknudson1, and a lot of ick is in keystoneclient 18:57:46 <gyee_> UX is the problem 18:57:50 <morganfainberg> by no fault of anyone just in the name of compatibility. same reason windows has lots of bloat. 18:57:54 <gyee_> inconsistent params 18:58:06 <morganfainberg> gyee_, and that is hard to fix w/o breaking people. 18:58:35 <jamielennox> so a big question i have is naming the base layer 18:58:50 <gyee_> morganfainberg, that's why we have the deprecation lifecycle :) 18:58:51 <jamielennox> because one of the first things required will be openstack_base_client.Session() 18:58:54 <bknudson1> we seem to have enough problems getting rid of the v2 api much less getting rid of the old api 18:59:18 <jamielennox> bknudson1: let's face it though - it will be me that has to do the ksc -> ksc2 transition for everyone 18:59:22 <morganfainberg> ok we're out of time. 18:59:29 <morganfainberg> please move to openstack-keystone 18:59:34 <morganfainberg> #endmeeting