17:59:40 #startmeeting keystone 17:59:41 Meeting started Tue Nov 24 17:59:40 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:44 The meeting name has been set to 'keystone' 17:59:49 stevemar o/ 17:59:53 ping ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC 17:59:54 o/ 18:00:00 olá o/ 18:00:07 hey! 18:00:09 o/ 18:00:12 hi 18:00:19 o/ 18:00:24 ’tis the season to be merry.... 18:00:30 oh, no, that’s later 18:00:34 o/ 18:00:43 henrynash: this season makes me grumpy 18:01:03 oi :) 18:01:05 dstanek: you be grumpy, I’ll be sneezy 18:01:06 #topic Mid-cycle survey 18:01:11 o/ 18:01:19 \o 18:01:29 check the mailing list http://lists.openstack.org/pipermail/openstack-dev/2015-November/080299.html 18:01:35 theres a survey please fill it ou!t! 18:02:02 any questions about mid cycle? 18:02:09 sorry to tell you this, but Winterfell has been destroyed 18:02:20 bknudson: shhh spoilers! 18:02:23 spoiler alert! 18:02:24 i should have written in Cleveland for location 18:02:59 so no questions :) 18:03:03 has filled. 18:03:10 stevemar: filed 18:03:17 ty davechen and henrynash 18:03:29 gonna skip the next topic 18:03:34 #topic Backend driver versioning 18:03:36 henrynash: its all you 18:03:40 ok 18:03:59 so i happen to have to be the person to write the first new driver version 18:04:10 https://review.openstack.org/#/c/242853/ 18:04:39 but dtsanek and I have been debating exaclty how this should work…and more importantly what the goals 18:04:40 are 18:04:52 see his thoughts here: https://gist.github.com/dstanek/756337141e5e0066ebce 18:05:31 question 1: Is the main goal of driver versioning to ensure we can update to a release and someones customer driver still works? 18:05:54 some of this we knowingly deferred because of time constraint to get versioning into the L release and we didn't know all the issues that would come up 18:05:55 that's the goal 18:06:12 why was there a time constraint to get versioning into L? 18:06:30 we'd rather get some code in rather than get the right code in? 18:07:20 bknudson: I don’t the code was necessarily wrong, just that I don’t think anyone fully thought out eactly HOW we would create a new version! 18:07:23 bknudson: no, it's not about right code. these are things that need to be decided when creating the first updated version 18:08:00 I’ll lay out the two extremes 18:08:02 bknudson: we talked about some of the things i listed in my gist, but decided we could defer since they don't change the overall stragegy 18:08:05 or strategy 18:08:15 extreme support says: 18:08:35 1) We keep the current driver and the n-1 driver in tree, all the code etc. 18:09:00 we're going to need the n-1 driver for testing 18:09:14 2) We support different SQL models between the drivers, if teh new one has changed 18:09:35 SQL model assumes the driver is SQL... not sure what that has to do with it 18:09:49 3) we (somehow) allow db_sync to be directed to upgrade to the right model based on driver version choice 18:10:11 bknudson: the current review copies the old SQL driver (including model) so that someone can use it if they wanted 18:10:12 how did SQL get mixed in with this? 18:11:03 bknudson: so I am assuming (maybe incorrectly) that custom drivers are not necessarily just differnet backend technologies, but could be a modified version of our own SQL driver, say 18:11:11 bknudson: essentially all of our V8 assignment drivers are being supported for one more release; i would rather not do this and just support the V8 interface 18:11:24 the database schema is for the keystone sql driver. If someone wants a custom driver that uses their own database schema then they need to write their own migrations and models 18:11:47 y, it's just the interface that we say is supported 18:11:57 but what if we change the shema and the new version wants to use the new schema? 18:12:02 that implies the old drivers will still work. 18:12:15 (in the SQL case, the old drivers with our old schema) 18:12:16 lbragstad: i address that in the gist 18:12:26 adapt the old driver 18:12:34 * stevemar is back 18:12:35 dstanek ah, gotcha 18:12:46 the versioned drivers was really about the interface itself that keystone communicates to. 18:13:07 if the backend datastore has to change, you need to adapt t it. but the driver interface keystone expects would remain consistent 18:13:16 bknudson, notmorgan: Ok, so that’s a useful clarification….and I think this get’s much simpler in thatcase 18:13:29 if somoene is subclassing the SQL driver and we change the schema... thye kindof are on their own there - there be dragons 18:13:58 henrynash, its to keep people from me doing things like breaking Dreamhost's custom in house Identity driver 18:14:06 again 18:14:11 but in reality, i expect someone to write their own (mongo?) data store for this, and therefore wouldn't hit the "the schema changed" issue 18:14:27 or the like 18:15:05 sounds like most agree with the concepts from my gist then.... if that's the case i'll put the content into our documentation to clarify this 18:15:22 notmorgan: and I agree with that….and if we are all agreed that we are NOT trying to ensure someons sub-classed n-1 SQL driver will magically work, then I think we have a clearer way forward 18:15:32 dtsanek: agreed 18:15:33 notmorgan, henrynash so, to make explicit; we will start a new version of a driver at the start of a cycle (or when required) and that version will stay open for changes for the durecation of that release, to be closed to modification upon RC1? 18:15:41 so the manager is going to have to check if the driver is V8 and if so insert the adapter 18:15:56 henrynash: aboslutely on point - never try and be magical with the datastore. if they subclass they take on the risks of subclassing 18:16:19 bknudson: yes 18:16:28 bknudson: i think that's the best approach. otherwise you'd sprinkle in versioned code all over the manager 18:16:38 notmorgan: we should be clear about that in comments and documentation 18:16:38 o/ 18:16:43 shaleh: yes 18:16:44 when V8 isn't supported then delete the V8 adapter 18:16:51 dstanek: ++ 18:17:12 shaleh: yes, post meeting i'll work on that 18:17:13 ok, I think we have agreement on direction…dstanek and I can take it from here 18:17:43 #action dstanek to update the documentation 18:17:48 so all we need to have is a v(X-1) -> vX adapter (where X is the current version) 18:18:09 but we also need to keep a copy of the old drivers (as you're doing) so tht we can test the adapter, right ? 18:18:12 henrynash: ^ 18:18:33 samueldmq: yes, that is probably true….. 18:18:37 henrynash and dstanek thanks for championing this effort 18:18:46 henrynash: nice 18:18:48 stevemar: ++ 18:18:57 samueldmq: keeping the copy is a case by case, i think. we need enough to guanarantee the adapter works to fulfill the contract 18:19:27 next topic time 18:19:31 i'd rather not over constrain because that may stop good ideas from appearing 18:19:37 notmorgan, henrynash so, to make explicit; we will start a new version of a driver at the start of a cycle (or when required) and that version will stay open for changes for the durecation of that release, to be closed to modification upon RC1? 18:19:47 I'd like a yay/nay on tyhat 18:19:48 that 18:19:50 dstanek: I agree... if we are just removing some methods (this case) perhaps we don't need a copy, but I'd take that as the general rule for simplicity 18:19:59 ayoung: yes (although RC1 or M3 might be debatable) 18:20:05 agreed 18:20:07 ayoung: yes 18:20:14 thanks 18:20:14 ayoung: i think that is agreeable 18:20:50 #topic Call for keystone-spec reviews 18:20:53 HMT time? 18:20:59 Ah... 18:20:59 ayoung: this will be quick 18:21:08 hyper multi threading? 18:21:19 please review specs! if you do, i will buy you beer and puppies 18:21:29 dstanek: hypercube magical time? 18:21:34 sold! 18:21:36 Mitaka-1 ends around Dec 1-3 18:21:37 stevemar i'll hold you to that! 18:21:43 * notmorgan throws peanuts at stevemar 18:21:45 stevemar: action: stevemar to buy beer and puppies 18:22:07 notmorgan: i think we usually have a spec freeze after m1? 18:22:07 lbragstad, I think I addressed your comments in the online schema migration spec 18:22:09 stevemar: is that 1 beer per review (or 2)? 18:22:11 I'll take a chocolate lab and a IPA, please 18:22:27 stevemar: i always drove for that freeze 18:22:28 dstanek: depending if you voted abs(1) or abs(2) 18:22:30 xek_ awesome, I'll be sure to take another look today 18:22:33 *amounts of beer and puppies are up for debate later 18:22:35 stevemar: but you're the PTL you get to make policy here :) 18:22:35 notmorgan: cool 18:22:41 so we'll keep it the same :) 18:22:45 stevemar: there are lots of old specs 18:22:46 m1 is spec freeze 18:22:52 dstanek: there are 18:22:59 M1 Will work for me, but then, I've pushed my specs through already, so that would be selfish of me 18:23:05 i've tried to highlight ones here: https://gist.github.com/stevemart/46d664e486e2edce4972 18:23:12 * notmorgan is not submitting specs...sooo 18:23:13 stevemar when is m1 again? 18:23:18 * notmorgan has no horse in this race 18:23:18 dec 3 18:23:19 topol: dec 1-3 18:23:20 should we abandon without prejudice? 18:23:33 dstanek: i like abandoning with predjudice 18:23:41 dstanek: if you feel the need, go ahead 18:23:51 well now I know how I am spemding my thanksgiving... reviewing! 18:23:54 dstanek, all specs should be proposed against backlog. We can always approve backlogged specs, just they don't get commitmnet for Mitaka 18:23:56 i would like it if we concentrated on ones we spoke about at the summit 18:23:57 stevemar: great. i'll go ahead to walk you gist and get reviewing 18:24:03 topol: you know you'd do it anyway (and you like it) 18:24:22 notmorgan :-) 18:24:29 prioritize specs that are targeting mitaka and not backlog 18:24:51 BTW. Can I get a vote on https://review.openstack.org/#/c/244694/ and, if the team agrees to it, I willremove the -2 18:24:53 ayoung: yeah, we just have to decide if it's something that we'd want to support 18:25:04 stevemar: that's a freeze for mitaka/, not for backlog, right? 18:25:16 breton: yep 18:25:23 great 18:25:28 topol: i have family stuff. so yeah, reviewing will keep me sane 18:25:45 thank you for your reviews in advance :) 18:26:07 ayoung dstanek I had a bunch of questions on that one 18:26:10 is the spec from backlog approved , still can get the code in? 18:26:11 buckeyes lost, yellow jackets stink. football season is over anyway 18:26:36 okay, HMT time, i'll give you guys a heads up when it's wrap up time, there is a lot on the list 18:26:42 ok 18:26:48 short bit on HMT: 18:26:53 #topic Hierarchical Naming 18:26:56 We make it possible to make URLS out of the names 18:27:01 davechen: depends on the impact 18:27:12 gotcha. 18:27:15 to do that, a domain (and possibley prject) name is URL safe 18:27:16 ayoung: ++ 18:27:29 davechen: functional testing, np. huge function, mehh, we'll have to discuss :) 18:27:35 See proposal: https://review.openstack.org/#/c/248083/ 18:27:36 no / no @ no characters that mess up a URL scheme 18:27:45 we make it a config option to go strict 18:28:01 if you go strict, then all non-complying domains get disabled 18:28:04 its an opt in 18:28:05 ayoung: why not support &entity; style escaping? 18:28:19 but you need to opt in in order to get HTM naming 18:28:29 henrynash: ayoung: what's the advantage of making names URL-safe ? 18:28:34 URLs use %xx 18:28:39 is that we can easily pick a separator for representing the hierarhcy ? 18:28:49 shaleh, we can make that a potential porting technique, but the short is we don' 18:28:57 bknudson: right, thanks 18:28:58 samueldmq: so we can, eventually, say: auth on domain/projectA/projectB 18:29:03 or something liek that 18:29:16 t want to chage OS_DOMAIN_NAME, OS_PROJECT_DOMAIN_NAME env vras and the like, so the integration with everything else still works 18:29:19 henrynash: so yes, we can easily pick / as the separator for representing the hierarchy 18:29:22 henrynash: so a separator would be hardcoded, say '/' 18:29:25 so if I have a domain named customers 18:29:31 henrynash: that was my only remaining question on that 18:29:39 I can make a domain named customers/pepsi and customers/coke 18:29:49 in general I like this proposal. But, there are sure to be people out there that it impacts. Which is why some form of escaping for existing coupled with checks on new would be a good idea. 18:29:50 and use that full name in the env vars etc 18:29:56 having a / as a separator feels like it would make routes hard to write 18:30:03 marekd: the current proposal does not specifiy what separator we use, just that we enbale that support in the future 18:30:28 henrynash: i am talking long term - we would eventually choose something, probably '/' 18:30:38 marekd: sure 18:30:41 I'd rather choose the separator as a config option 18:30:43 shaleh, since it would be a top level name...we might be able to work out some escaping, but the user would have to only use the escaped version 18:30:50 i like using the ASCII Bell character as the delimiter... 18:30:51 >.> 18:30:53 ayoung: agreed 18:30:54 raildo: thats fine, but not part of this spec 18:31:01 so if they had red/hat it would become red%whateverhat 18:31:22 a dot is acceptable? 18:31:24 ayoung: we could provide library assistance for that easily enough 18:31:24 henrynash: yeap, I know but I'm just saying :P 18:31:28 marekd, I think it is 18:31:30 the only thing this spec does is provide a path to get domains and projects to NOT use anu url reserved charcacters 18:31:44 you can do http://hostname/this.is.my.url 18:31:48 henrynash: +1 from me 18:32:00 raildo would making the separator a config option make interoperability more problematic? 18:32:01 and a relatvie url with this.is.my.url/test.html 18:32:13 ayoung: ++ i like dot as it more reflects dns 18:32:17 topol, its not the separateo that is up for discussion 18:32:26 ayoung: ++ 18:32:26 the domain nesting will be URL based 18:32:37 I would suggest, in the interests of time, we defere debate on teh separator itself…it is not part of the spec up for review here 18:32:42 ayoung agreed but a question to ponder over turkey 18:32:50 agreed 18:32:55 henrynash: ++ 18:33:08 henrynash: ++ 18:33:12 topol: we can discuss later about it :) 18:33:19 so why was this not included in the initial HMT stuff? 18:33:21 henrynash: ayoung ok, so i think it was not super clear from the spec that enabling this naming convention (names url safe) automatically disable non compliant domains/projects 18:33:22 henrynash, so, it sounds like you and I are in sync? Let me know if htere are any other goblins hiding that you've spirited out, ok? 18:33:22 as voice for the end-user, I like this spec we just need to make it easy on ops and users to comply 18:33:38 marekd, if not, we need to put it in bold and underline it 18:33:40 why are we just bringing it up now? 18:34:03 stevemar, we tried back then 18:34:05 henrynash: so are you wanting to encode names or force the name to be urlsafe? 18:34:08 ayoung: that's my observation 18:34:14 marekd: it states that you can’t issue any tokens scoped by name to url-unsafe named projects/domains if you opt in 18:34:23 but I think we were thinking about it backwards...the realization was that it woudl be opt in, not that all current domains would work 18:34:25 stevemar: he have discussed about it a lot of times here... and right now, we have a patch to handle with clash names, 18:34:30 henrynash: maybe i missed it then. 18:34:32 thanks 18:34:34 dtsanek: we make them only use url-safe names 18:34:57 so the point of this is so i can specify a nested project? 18:35:03 hierarchy 18:35:10 marekd, I think we also need to make it explicit that domain nesting only works with url-safe names enabled 18:35:17 ayoung: sure 18:35:17 stevemar, a nested domain 18:35:22 ayoung +++ 18:35:22 stevemar: yes (or maybe even a nested domain, if we ever do that) 18:35:22 stevemar: because we hadn't thought about it ? maybe the same case as we hand't tought about the inherited assignments and hierarchical projects properly 18:35:31 so basically something like: [a-zA-Z0-9\-_] and a few other chars? 18:35:32 stevemar, it might be extensible to nesting projcts, too, but that is a longer reach 18:35:32 stevemar: maybe just a lack of eyes on that at the time :/ 18:35:38 dstanek, I think so 18:35:48 we can start cautious, and then open it up 18:35:58 easier than being to permissive, as we've found 18:36:12 ayoung +++ 18:36:13 iirc there are a lot of urlsafe chars 18:36:18 i'm just concerned about all these changes to our base API 18:36:20 dstanek: ++ 18:36:20 ayoung: totally agree 18:36:34 stevemar, no API changes here by default 18:36:34 dtsanek: yes, we exclude those specifed as reserved chars in the URL spec 18:36:44 stevemar: are there api changes or just new constraints for the data? 18:36:44 its opt in 18:36:59 hopefully just new constraints 18:37:12 ayoung: OK, not new API changes, but additional logic in the controller that handles those APIs 18:37:28 stevemar: not with the spec, no 18:37:31 sounds like we have a plan. We can work the rest out in the review process. please prioritize. 18:37:50 I'm going to ask for a spec review exception for this right now. 18:38:01 FYI rfc3986 says: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 18:38:05 stevemar: if we chose to extent auth to accept a hierarchy name, then yes, but only in trh processing of teh name field 18:38:07 I think we can parallelize the implementation with the spec, but don't want to rush it 18:38:18 dstanek: yep 18:38:19 dstanek: nice 18:38:28 dstanek, I'm ok with starting with just those characters. 18:38:46 that brings us back to '/' as a separator. Is that an issue with routes? 18:39:04 shaleh: probably 18:39:11 '.' is an allowed character so we cannot use that 18:39:24 shaleh, yes, but we can make it work. 18:39:35 we could use , 18:39:38 ayoung how? 18:39:51 dstanek: eeewww, visually hard to make out 18:40:06 shaleh, I agree eeeww 18:40:10 topol, its python code. Its only going to be one API. I don't know *how* but I know we *can* 18:40:11 shaleh: then ..,.? 18:40:23 '|' is always popular 18:40:26 but we can make the mapper code deal with a/b/c/d 18:40:40 shaleh: we'd have to encode that 18:40:53 defer the conversation about the delimiter 18:40:57 we've got a full list 18:41:01 fair 18:41:02 again, let’s not debate the separator….we get to chose any url reserverd cahr 18:41:07 * notmorgan votes ಠ_ಠ as the delimiter 18:41:08 we should debate this with the spec that proposes the delimiter! 18:41:08 agreed 18:41:20 (that was commentary on the convo needs to move on btw) 18:41:20 what do you guys mean delimeter? 18:41:33 #topic filtering service providers with endpoint filter 18:41:33 (continue after meeting in #Keystone) 18:41:36 we don't have nested domains really so no need for delimiter 18:41:37 marekd: ^ 18:42:02 is there something that needed to be hashed out here instead of the spec? 18:42:02 bknudson: ++ no nested domains. 18:42:33 ok 18:42:33 is marekd online? 18:42:33 bknudson: there are plentt of reasons to do this, ignoring the domain issue 18:42:38 i am 18:42:48 https://review.openstack.org/#/c/188534/8/specs/backlog/service-providers-filters.rst so for this spec 18:42:56 marekd: the podium is yours 18:43:22 with HMT don't we get nested domains? 18:43:54 some reviewers inclined endpoint filtering might be not "ready to use" as service_providers are not in the service catalog. Just wanted to hear your opinions - maybe we should just add another api and make it work as we would like to from the beginning? 18:44:04 oh, wait no.. nm me 18:44:43 hmm, they aren't in the service catalog are they 18:44:49 they arent 18:44:53 didn't we add them to the top level? 18:45:00 notmorgan: we did 18:45:00 * notmorgan might be misremembering 18:45:26 they are in the token body, at the same level as the service catalog, i think 18:45:27 marekd: I like the idea of a filter for them. I am just not sold that endpoint filtering is the way to go. 18:45:59 shaleh: cool, so this is the perfect timing for a discussion :) 18:46:19 marekd: agreed :-) 18:46:39 unscoped tokens don't include the service providers? 18:46:42 i personally thin an admin should be able to tie a service provider with a project, domain (for domain scoped token) but also "all projects in a domain" 18:46:59 seems like a new service provider filtering concept 18:47:06 bknudson: notremembering now, but today we simply fetch all service providers and return them in the token response. 18:47:19 so this might also be athe case for unscoped token 18:47:32 so for unscoped tokens there's nothing to filter on. 18:47:34 marekd, only list SPs for Unscoped? 18:47:41 maybe the projects that the user has roles on 18:47:54 ayoung: you don't want to list all sps to everyone 18:48:09 you don't want your pepsi clients expose that coke is your client too 18:48:14 correct. So unscoped seems like the wrong abstraction 18:48:15 ++ 18:48:21 you dont want them think they may burst there... 18:48:29 its public vs private Idps, just for K2K 18:48:35 ayoung: ++ 18:48:40 ayoung: seems like it 18:48:51 ayoung: more or less....(less) 18:49:00 so...they should be associated with proejcts 18:49:04 yes 18:49:09 which is what endpoint filtering is doing 18:49:18 but also domains and "all projects in a domain" 18:49:32 so...lets expand that API to handle SPs seems like the most sane approach? 18:49:37 but how are you associating a SP's endpoint with an IdP's project? 18:49:40 did endpoint filtering ever get expanded to domains? 18:49:45 marekd: i'm okay with abusing endpoint filtering for service providers 18:50:00 lets not expand anything to domains that we don't have to 18:50:08 stevemar: so extending it, right? 18:50:14 marekd: yeah 18:50:18 it might happen automatically when we change domains to projects 18:50:23 stevemar: cool 18:50:46 ah, pity samuel is not here 18:50:47 ~ 10 minutes left 18:50:47 marekd: are the API changes and spec changes in the same patch? 18:50:53 stevemar: not yet 18:50:53 thanks lbragstad 18:51:04 bknudson, ++ 18:51:05 stevemar: i can add 18:51:12 ok, dont want to use more tim.e 18:51:23 marekd: start writing them out, i'd be curious to see what happens as you go 18:51:27 stevemar: OK 18:51:33 i think we might be mis-remembering something 18:51:34 anywho 18:51:42 like? 18:51:48 marekd: not sure! 18:51:53 #topic Dropping python 2.6 support 18:51:56 bknudson 18:51:58 marekd: i'd love to see the documentation changes earlier than the code if possible... 18:52:04 yes! drop it! 18:52:06 in case you missed the mailing list discussion 18:52:08 make it go away 18:52:10 >.> 18:52:11 die die die py26 18:52:16 infra stopped testing with py26 18:52:27 this seems like an easy one 18:52:30 and oslo libs already stopped advertising support for it 18:52:46 so there's some work to do in the repos to stop advertising support for 2.6 18:52:51 1) get rid of the job, 2) clean tox.ini 3) clean up any py26 specific code we have (we probably have a lot) 18:52:58 if anybody wants to sign up to do it ... 18:53:02 DIE PYTHON2.6 DIE 18:53:04 otherwise I'll add it to my list 18:53:07 is there anything left in keystone? 18:53:14 stevemar: open a tracking bug for cleanup of this stuff i think 18:53:18 any takers? give bknudson a break to eat some turkey 18:53:20 and then anyone can do it 18:53:23 notmorgan: that would be great 18:53:28 bknudson: i'll do some 18:53:29 notmorgan ++ 18:53:29 iirc, py26 has been removed from dependency list. 18:53:29 bknudson: I can help out 18:53:35 i can give a hand too 18:53:36 davechen: nope, keystone is py26-free 18:53:38 and it can just have bits done at a time. i'll open the bug shortly 18:53:46 navid_ around? 18:53:53 yea 18:53:56 ok, I'll assume people are going to work on it. Add me to the reviews 18:54:03 navid_ would that be something you're interested in, too? 18:54:04 just remember to use Partial-Bug: blah 18:54:09 bknudson: consider yourself added 18:54:18 stevemar: do we have a bug yet? 18:54:20 tjcocozz might be interested too :P 18:54:33 shaleh: not yet, notmorgan is opening one as we speak... err type 18:54:36 @lbragtad: sure, we can discuss afterwards 18:54:38 there's plenty of examples in oslo repos 18:54:49 next! 18:54:53 #topic Reno for other repos 18:54:56 i don't want this 18:55:06 this is overkill for libraries 18:55:21 is oslo doing this? dhellmann dims_ ? 18:55:30 yes, oslo is doing this as far as I know 18:55:35 ughhhhhhh 18:55:39 stevemar : we were talking about it. haven't decided yet 18:55:43 but i dont wannnaaaaa 18:55:43 If you kill a man in Reno, they don't send yo to Folsom St. Penn...yougo to jail in Nevada 18:55:46 e.g., https://review.openstack.org/#/c/249329/ 18:56:00 stevemar: https://bugs.launchpad.net/keystone/+bug/1519449 18:56:00 Launchpad bug 1519449 in OpenStack Identity (keystone) "Remove Python 2.6 Support" [Low,In progress] - Assigned to Keystone Drivers (keystone-drivers) 18:56:00 stevemar we only want to use reno for keystone server? 18:56:03 oh, the discussion is ongoing 18:56:07 bknudson : see the -W 18:56:09 y 18:56:15 thanks notmorgan 18:56:33 link to "why reno?" please. 18:56:45 bknudson: let's wait and see what comes out from the oslo discussion 18:56:54 i'd really prefer to not have to do reno for libraries 18:56:58 lbragstad: reno doesn't make sense (i think) for the libs. 18:56:59 reno is to generate release notes, so that users will know what changed 18:57:05 but we'll go with the flow 18:57:09 e.g., what new features have been added 18:57:12 so um who was pushing reno? 18:57:24 topol: release mgnt ream 18:57:26 team* 18:57:27 notmorgan: use that bug for all of the libs? 18:57:37 topol : release team is trying to evaluate 18:57:45 dstanek: yeah will add the libs now 18:57:47 topol: it's great for the server stuff, instead of a wiki 18:57:50 anyone else actually really using it 18:57:57 topol: it just started 18:58:04 notmorgan: cool. thx 18:58:07 topol Nova has 18:58:13 topol: we get pretty release notes like: http://docs.openstack.org/releasenotes/keystone/unreleased.html 18:58:25 bknudson: we can chat about libraries in -keystone 18:58:34 bknudson: sorry we didn't get to that last topic 18:58:36 ok, we'll see where the rest of openstack goes 18:58:42 please lock the python-keystoneclient repo, but leave it a round since old versions of the code will point to it 18:58:47 dstanek: did I miss any? 18:58:53 same with SAML 18:59:01 don;t delete the repos. 18:59:13 ayoung: we won't, they'll go in the attic 18:59:20 dstanek: ok added pycadf too 18:59:24 so long as the links still work, I'm OK 18:59:26 notmorgan: do pycadf, ks-auth policy have 2.6? 18:59:27 with it 18:59:42 ayoung: links may not work... 18:59:44 stevemar: the release note is a little confusion, you put a bug link there but say it's a feature. 19:00:00 davechen: new options are available 19:00:03 and properly, we will has lot of features in the releasenote after the end of the cyle. 19:00:07 #endmeeting