18:00:34 #startmeeting keystone 18:00:35 Meeting started Tue Jun 14 18:00:34 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:39 The meeting name has been set to 'keystone' 18:00:41 o/ 18:00:50 o/ 18:00:57 \o 18:01:04 let's jump right into it 18:01:07 rmizuno_: you here? 18:01:14 link the agenda? 18:01:27 notmorgan: thanks, is my rust showing :) 18:01:29 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:01:40 \m/ d(-v-)b \m/ 18:01:46 o/ 18:02:06 stevemar: yes 18:02:12 rmizuno_: doesn't seem to be here, so i'll skip to the next topic, if he... oh there you are 18:02:22 #topic Add resource name to the notification event 18:02:27 rmizuno_: the floor is yours 18:02:33 just do it! 18:02:48 gyee: but names are mutable and domain scoped o_O 18:02:58 we only do IDs now, and that is hard to match, I take it? 18:03:05 (hi) 18:03:05 ayoung: yep 18:03:08 #link: https://review.openstack.org/#/c/320299/ 18:03:18 audit events are going to get big 18:03:20 this patch was intended to add a name to the audit notification when the project deleted. 18:03:22 stevemar, notification and audits is a snapshot in time 18:03:25 nothing more 18:03:29 ayoung: ++ 18:03:34 but, it seems odd to do it just for deleting project. 18:03:39 * lbragstad we had a similar request here - https://bugs.launchpad.net/keystone/+bug/1552795 18:03:39 Launchpad bug 1552795 in OpenStack Identity (keystone) "enhance notification for user events with user name" [Wishlist,In progress] - Assigned to Lance Bragstad (lbragstad) 18:03:46 rmizuno_, is this a case of the cure being worse than the disease? 18:03:46 so, I want to gain approval about adding the resource name to all audit notification. 18:03:52 #link https://bugs.launchpad.net/keystone/+bug/1552795 similar bug 18:03:53 and there were some good points made in that report 18:04:00 rmizuno_: so, i understand the need for doing this for projects 18:04:04 we have to understand what notifications and events are for 18:04:17 to facilitate monitoring, auditing, and forensics 18:04:33 rmizuno_: but i'd like the code to be done in a way that it's extensible, so users, roles, etc... can also add names to the event 18:04:36 ID's certainly fulfill that requirement 18:04:58 dolphm: ++ if not being super friendly, but are guaranteed immutable and unique within a deployment 18:05:09 so are *safe* for such actions 18:05:12 rmizuno_: also, we need to include domain name 18:05:16 gyee: you're missing your implied requirement to tie things back to your source system 18:05:16 the use case in the bug report, and the one we've discussed before, is primarily around the ** user experience ** of receiving an audit notification 18:05:23 but particularly for a delete action you can't resolve an ID into a name later 18:05:28 not the functionality of audit notifications 18:05:39 dolphm: right, this is totally a UX thing 18:05:42 dstanek, its a snapshot of the resource at that time, whatever it was/is 18:05:49 What if we had a utility to populate it ex-post-facto instead? 18:05:58 if you're using the name as the canonical source, tis your own fault :P 18:06:01 gyee: not saying you're wrong, just that you need to clarify the requirements 18:06:08 lkeep the audit events small, but have a "expand audit log ids" CLI 18:06:14 unless you're keeping essentially a duplicate of the keystone database there's no way you could get the name on a delete event. 18:06:27 ayoung: then we have to keep deleted entities around to make that work 18:06:42 bknudson which is something that can be done today 18:06:47 bknudson: fetch the resource from the backend before deleting? i think we do that now today? 18:06:49 dolphm: we may want to do that for many reasons [change the course from today] 18:06:50 bknudson: which is not a bad or strange idea at all if you care about your data that deeply 18:06:53 dolphm, seems like that would be a shrotcoming of the current system, wouldn'tit 18:07:04 so...better to have the names in there at least for deletes 18:07:11 I would hate to have my monitoring system to do a resource looking in order to display meaningful/reading stuff 18:07:15 bknudson i highlighted that in a summary of this discussion from the summit - http://lbragstad.com/improving-auditing-in-keystone/ 18:07:16 and for anything that is deleted, we would have no way of mapping... 18:07:27 even the ID is useless post delete right? Sure it was unique but what was it..... 18:07:32 not to mention having to configure a credential in my monitoring in order to lookup stuff 18:07:44 shaleh: that was mfisch's point too 18:07:44 i'm more inclined to make delete not be a "remove the row from the DB" 18:07:49 fwiw 18:07:54 * ayoung too 18:07:57 soft delets 18:07:59 deletes 18:08:05 gyee: the current audit records *are* meaningful - don't confuse this for a lack of functionality 18:08:08 ayoung: lets not call it that please... 18:08:11 a side effect is dealing with uniqueness in code 18:08:17 notmorgan: ++ for soft deletes 18:08:18 ayoung: just change what the delete means. 18:08:22 if I've kept a copy of the data (ID -> name) from before the delete I could use the ID to look up the name 18:08:35 (or whatever other name for this) 18:08:39 dolphm, just display the resource ID in the screen? 18:08:40 verbose cadf vs soft deletes vs shadow tables: http://lbragstad.com/improving-auditing-in-keystone/ 18:08:53 gyee: ? 18:08:54 please no shadow tables 18:09:07 i'll take verbose cadf easily before that 18:09:07 notmorgan: that'd be an operator solution, not upstream 18:09:09 notmorgan: ++ 18:09:13 notmorgan: operators can do that today 18:09:20 notmorgan, it was the term he used on the blog post 18:09:25 dolphm: true.. but nova did that in their tree 18:09:32 i don't want to see that replicated ;) 18:09:34 dolphm: from an implementation point of view, adding the names is the easiest of those 3 18:09:40 notmorgan: or maybe it's something we can document upstream as our recommended solution if you want those behaviors 18:09:43 notmorgan: what did they do? 18:09:59 dstanek: they have all sorts of internal shadow tables for book keeping on deletes 18:10:00 who would have a problem with adding name to the audit payload? 18:10:14 dstanek: accross services etc. 18:10:14 bknudson: presumably only keystone devs :P 18:10:21 notmorgan: didn't know that, that sounds awful. are they using mongo? 18:10:21 dolphm, when monitor system receiving an event which containing only resource ID, it has to make a call to Keystone to lookup the resource (if it still there) in order to display something that is *readable* 18:10:35 well what if an operator doesn't want a particular attribute in the payload 18:10:36 verbose notifications would be something configured in the config file right? 18:10:37 easiest solution: verbose cadf, best solution don't delete the rows, worst of both worlds shadow tables 18:10:39 and we put it in there 18:10:42 somehting like configuring the log level 18:10:45 notificaiton levle ? 18:10:45 samueldmq: no. lets not do that 18:10:54 dolphm: doubt it, because they could use just a single 'audit' collection 18:10:55 you know what...I'm not really engaged in this. Any of the options would suffice by me 18:10:56 samueldmq: please lets not add knobs to what is in notifications. 18:10:57 notmorgan: ++ 18:10:59 gyee: again, the use case your describing is user experience, not system auditing 18:11:00 * stevemar thinks we should make cadf the default notification format 18:11:10 I like soft deletes. It is kind of the norm really. 18:11:20 easier to ensure uniqueness too. 18:11:44 it's been ten minutes, doesn't seem like there's consensus here 18:11:44 if we just always put ids and names in the audit records would that satisfy 90% of the needs for more data? 18:11:48 user experience matters 18:11:52 dstanek: i think so 18:11:54 notmorgan: ++ 18:11:55 what is a notification ? is it supposed to only contain operation/entity_id ? 18:11:58 dstanek: I think so 18:12:00 in fact i recommend adding name to cadf AND not deleteing rows 18:12:09 for different reasons 18:12:12 notmorgan: agreed on not deleting. 18:12:16 but it would be the most complete solution 18:12:32 notmorgan: ++ 18:12:36 so lets do that 18:12:40 *why not both* 18:12:42 name first, not delete rows second 18:12:48 yep 18:12:51 ++ 18:12:56 rmizuno_: consider it approved 18:12:59 so adding names for ALL entities right? 18:13:00 we'll just run lbragstad's performance tests with the change and see what the effect is. 18:13:02 not just projects 18:13:03 why not full objects? because that's the next request 18:13:12 for the second part, we need a more comprehensive resource lifecycle management framework 18:13:12 #slipperyslope 18:13:15 rmizuno_: please try to make the code so other resources can use it 18:13:19 dolphm: ++ and their memory refs 18:13:19 dolphm: because we wont delete the objects 18:13:28 dolphm: to avoid that 18:13:31 stevemar i would be in favor of having a single notification format... having configurable notification stuff is confusing 18:13:31 dolphm: we won't include the description too :P 18:13:36 bknudson: i don't think there is any messaging support in the benchmark 18:13:36 dolphm: provide real lifecycle management on the resorces 18:13:38 stevemar: ok 18:13:51 thanks! all! 18:13:55 if we stop deleting rows we'll have to start enforcing rules in python that the db currently handles 18:13:56 lbragstad: i agree, as it stands now the 'audit' format is not default 18:14:07 right 18:14:08 lbragstad: if we can come up with a minimal, sufficient format I am +1 to that 18:14:13 if we're going to not delete rows, why not start with that 18:14:28 instead of adding names -> stop dleeting rows ? 18:14:28 samueldmq: adding names is much easier to do 18:14:36 let's do it right from the start :) 18:14:56 it is not wrong adding names, it just simpler for now 18:15:03 dstanek: ++ :( 18:15:07 stevemar: and after when we don't delete roles anymore, we won't be able to remove names from the events anymore 18:15:10 dstanek: not really, the db can still handle it, it is just changing how we handle unique constraints 18:15:22 dstanek: i can show you the migrations for it. it isn't too terrible 18:15:22 notmorgan: how would you do that? 18:15:49 dstanek: unique(deleted(notNull, Bool), delete_time(notNull, default=0) 18:16:07 we still have a lot on the agenda, can we discuss this in -keystone or in the patch? 18:16:07 dstanek: add in name etc constraints 18:16:16 stevemar: ++ 18:16:24 it basically means you unique on "not-deleted, and delete time 0, and " 18:16:32 and ids still remain unique 18:16:37 dstanek: i'll go over it more with you post meeting 18:16:39 (s) 18:16:43 it's not that hard to do. 18:16:56 #topic Drop support for Driver Versioning 18:17:04 rderose: ^ 18:17:05 stevemar: just rubber stamp this. 18:17:07 So the spec proposes dropping support for driver versioning. 18:17:14 There is a maintenance/development burden, however small you think it is. 18:17:21 I don't like our approach and question whether operators are actually benefiting from it. 18:17:26 i saw the ML post, but no one replied to it :( 18:17:27 stevemar: no one seems to care [though i dislike not having a clear contract, i'm willing to go with the general community consensus] 18:17:29 And to me it's not unreasonable to say, if you want to upgrade Openstack, you'll need to upgrade and test your custom drivers. That's it. 18:17:38 stevemar: i'd rather have some decisions than try to rush through a rediculously long agenda 18:17:38 and i'm the reason for the original proposal. 18:17:50 notmorgan: we can have a clear contract without supporting old versions of it 18:18:06 oh I love the terms "technical debt" 18:18:21 dstanek: either not really a contract [or unchanging?] or need versioning 18:18:27 i imagine we would have to provide better documentation when interfaces change? 18:18:28 we did "delete means disable" for tokens for a long time 18:18:28 what's wrong the approach? 18:18:32 dolphm: fair enough, we can circle back to it. i'll drop my item 18:18:34 so my question is why do we think the answer is different today than we did 3 releases ago? 18:18:48 maybe we can fix the approach 18:18:56 henrynash_: because fewer deployments run custom drivers now. iirc 18:19:05 henrynash_: i didn't actually like it then either 18:19:16 i haven't heard of folks doing it in the last year 18:19:23 dstanek: I think we all felt it was a necessary evil 18:19:27 it was much more prevalent when i proposed this 18:19:34 lets kill driver versioning and if people are doing customer drivers break them willy and nilly. 18:19:36 we'll likely wind up running a custom driver here. 18:19:54 rderose, is this support is dropped immediately after spec merge or we still have to support versions and adapters in between for 2 releases? 18:19:57 bknudson: would keeping the versioned drivers make things easier for you? 18:20:01 henrynash_: the maintenance cost of the current approach is astronomical compared to the supposed benefit 18:20:03 we should listen to deployers and take our decision to keep or not supporting it 18:20:15 amakarov: it would be 2 releases i think 18:20:19 samueldmq: deployers have not expressed any support on the mailing list either way 18:20:21 samueldmq: i hear no deployers asking for it at this point 18:20:27 previously there were a number 18:20:28 stevemar: I don't think the versioned drivers actually would help us much. 18:20:38 dreamhost, hp, etc 18:20:44 the only way to find out who is using it is to remove it. For any value of *it* 18:20:45 dolphm: notmorgan: so I fully support dropping support for custom drivers 18:20:46 we'll have to change our driver eventually so will likely just do it when we upgrade. 18:20:53 maintanance costs are high 18:20:54 samueldmq: no. 18:20:55 and write our own translation code. 18:20:56 bknudson: for complicated drivers, "faking out" methods is difficult 18:21:00 samueldmq: verioned drivers. 18:21:09 stevemar, so delegation driver adapters I'm working should still introduce new assignement and trust driver versions instead of just changing them? 18:21:10 samueldmq: someone can still write a custom driver. 18:21:11 notmorgan: so why did hp & dreamhost change? 18:21:20 stevemar: hp doesn't run a public cloud now. 18:21:24 dreamhost changed because I broken them 18:21:28 stevemar: dreamhost moved to pure upstream. 18:21:32 notmorgan: ok, so we keep supporting withouth the headache of versioning them 18:21:32 stevemar: afaik 18:21:34 when we split ID into id and assignment. 18:21:36 stevemar, I can't get us to contribute the mongodb driver, so I won't cry if we drop it 18:21:36 notmorgan: yes that's what I MEANT 18:21:37 poort thingy 18:21:38 samueldmq: basically 18:21:39 the thing i like about the custom drivers is the backwards support from version to version. If we think we can do upgrade notes etc on drviers and deprecation periods etc then they're not needed - but historically we didn't 18:21:46 notmorgan: ++ I support that 18:22:01 better to push for code going in upstream 18:22:07 iSuck 18:22:17 we could also just 2-cycle support the backend driver contract - no versions 18:22:24 jamielennox: good points 18:22:36 let's create better docs about driver contract changes; and to be honet they're pretty good right now since we do release notes 18:22:53 but as the original champion of this - i'm fine with it being dropped. i hear very few people [zero] asking for this now. 18:22:56 we don't really have a driver contract anyways. 18:22:59 samueldmq: we can't avoid driver contract changes... 18:23:12 we aren't ironic, we aren't cinder with 3rd party drivers 18:23:13 ayoung, the problem I see, is we're saying: "You can write your own drivers with this interface which is subject to change anytime we please" 18:23:21 even the backends we supply now work differently in many cases 18:23:22 i'm OK with not creating any new drivers and removing the current versioned drivers when they have been deprecated 18:23:24 dolphm: exactly, so let's just document the changes better (with release notes). and drop support for versioning 18:23:32 amakarov: well not once release happens for a given cycle 18:23:32 amakarov: basically notify in newton and remove in O 18:23:46 amakarov: but if you're chasing master, do it at your own risk 18:23:49 samueldmq: we lack the notes saying to upgrade you need to implement these functions and drop these others, with the versioning it's easy to see what you need to implement rather than scattered deprecation notices 18:23:54 samueldmq: oh, sure ++ 18:23:55 samueldmq, the code is the document :-) 18:24:01 we wont change [barring security issues etc] the backend interfaces on a given release. 18:24:19 gyee: the better way, always :D 18:24:23 gyee: don't even joke about that :P 18:24:30 stable releases are stable, and that's never changed 18:24:34 jamielennox: that info is available in the release notes, at least the ones I've seen from henrynash_ iirc 18:24:35 at this point the code is the document 18:24:36 dolphm: ++ 18:24:38 anyway. 18:24:41 since we don't document the interface. 18:24:45 i think we're all in agreement (except maybe henrynash_) ? 18:24:47 but i've advocated before we should create a keystone/lib dir and treat it like a real library and put in there anything that is supposed to be consumed from others 18:24:47 knikolla: we can do that with release notes pretty easily 18:24:49 genral consensus - drop it? 18:24:53 vote ? 18:24:55 and document better? 18:25:07 notmorgan: drop & doc! 18:25:19 stevemar: I’m just leary of removing something we thought was important with zero input from deployers 18:25:21 dstanek: ++ 18:25:24 do what jamielennox is proposing 18:25:26 I don't always agree with dstanek, but not this time 18:25:29 samueldmq: i think henrynash_ is the only one on the fence 18:25:29 stevemar: notmorgan: should we vote? shoud be quick 18:25:33 amakarov, I've never said that. I always saw driver as internal code 18:25:42 and who will do this? rderose? :D 18:25:51 henrynash_: we asked for input, we heard crickets 18:25:56 dolphm: ++ 18:25:58 raildo: dstanek: volunteered 18:26:00 I’ll certainly support the consenus 18:26:02 lets hold off on removing versioned drivers until after the next summit, and get it before the operators 18:26:07 henrynash_: let's senf an email notifying the decision 18:26:11 ayoung, and we expose 'driver' parameter to config for people to override it 18:26:11 rderose: dstanek awesome :) 18:26:11 its probably just busy work, but we have committed to it 18:26:15 they will say something if they disagree 18:26:18 and everyone who has complained to me previously have stopped doing custom drivers as i know 18:26:20 at least this time :) 18:26:21 the question is whether we just drop all support of honor the existing contracts for a release 18:26:30 dolphm: which meant they weren;t listeneing, didn’t get the question or don’t care…but we don;t know which 18:26:34 amakarov, I just saw that as a way to switch between existing ones in tree 18:26:36 dstanek: honor for at least a release 18:26:42 #info gyee doesn't always agree with dstanek, but not this time 18:26:48 hahah 18:26:51 as ayoung says, we do not really know what is out there 18:27:00 ayoung, anyway, whoever customizes driver get a maintainance problem, and it's his problem :) 18:27:04 #startvote drop version driver support? Yes, No 18:27:05 Begin voting on: drop version driver support? Valid vote options are Yes, No. 18:27:07 Vote using '#vote OPTION'. Only your last vote counts. 18:27:07 announce the versions go away in O 18:27:11 #vote Yest 18:27:12 samueldmq: Yest is not a valid option. Valid options are Yes, No. 18:27:13 #vote Yes 18:27:15 #vote Yes 18:27:16 Yes 18:27:16 oops 18:27:18 #vote idontcare 18:27:19 notmorgan: idontcare is not a valid option. Valid options are Yes, No. 18:27:21 #vote yes 18:27:21 #vote yes 18:27:22 wait...when? 18:27:22 #vote yes 18:27:25 #vote Yes 18:27:26 #vote later 18:27:27 shaleh: later is not a valid option. Valid options are Yes, No. 18:27:28 #vote no 18:27:30 I want to do so eventually 18:27:34 #vote yes 18:27:36 #vote yes 18:27:36 is a yes vot for dropping immediately? 18:27:39 #vote yes 18:27:40 #vote yes 18:27:40 #vote more_yes_than_yes 18:27:40 dstanek: more_yes_than_yes is not a valid option. Valid options are Yes, No. 18:27:43 #viteinfo 18:27:46 dstanek: heh 18:27:47 #vote yes 18:27:47 #voteinfo 18:27:52 dolphm: VITEINFO! 18:27:53 ayoung: yes means we just don't create new ones, and let the exisitng ones deprecate 18:27:55 #vote yes 18:27:59 #vote yes 18:28:00 #vote yes 18:28:00 #vote yes 18:28:00 but i want to say there's really no rush to this 18:28:06 #showvote 18:28:07 Yes (15): rodrigods, nisha_, lbragstad, ayoung, rderose, bknudson, browne, dstanek, samueldmq, jamielennox, knikolla, amakarov, dolphm, raildo, stevemar 18:28:08 No (1): henrynash_ 18:28:10 #endvote 18:28:10 Voted on "drop version driver support?" Results are 18:28:11 Yes (15): rodrigods, nisha_, lbragstad, ayoung, rderose, bknudson, browne, dstanek, samueldmq, jamielennox, knikolla, amakarov, dolphm, raildo, stevemar 18:28:12 No (1): henrynash_ 18:28:20 (someone’s gotta stand out from the crowd) 18:28:27 :) 18:28:27 henrynash_: ++ 18:28:28 he's a wild duck. 18:28:28 if people end up not liking this then we can always start creating new versions 18:28:35 rderose: interpret what you may from the results :) 18:28:42 nice, I think we can discuss about how we do it in -keystone 18:28:43 dstanek: lol 18:28:46 ok, done…next topic! 18:28:55 stevemar: ++ what, you mean henry hates me now 18:28:58 I just feel like wearing Monty's hat and saying operators might be bitten if we act too quickly 18:29:06 henrynash_: actually... i'm going to circle back to the previous one 18:29:08 henry: beer is on me at mid 18:29:18 #topic Add resource name to the notification event 18:29:20 shaleh: you should invoke mordred when putting on his hat 18:29:23 rderose, do pay attention to who's walking behind you on the next summit 18:29:28 redose: as the person who ended writing nealy all teh bl**dy wrappers, no I’m happy (in a perverse way!) 18:29:29 let's get a concrete action item out of this 18:29:32 rderose: follow up on your mailing list post with the outcome of this meeting 18:29:42 dolphm: good call 18:29:47 dolphm: will do 18:30:04 so back to the whole names in audit events thing 18:30:05 shaleh: (though i think he's in meetings all day) 18:30:13 notmorgan: yeah... 18:30:14 dolphm: ++ 18:30:21 gyee: ++ 18:30:37 i'm ok with adding the resource name and domain name 18:30:38 henrynash: ++ 18:30:40 stevemar: a) add names now b) move towards soft deletes 18:30:47 shaleh: ++ 18:30:51 shaleh: ++ 18:30:53 ++ 18:30:54 dolphm, you seem concerned 18:30:59 maybe we should vote again ? :-) 18:31:01 shaleh: but can we never call them "soft deletes" again ;) 18:31:12 shaleh: just call them "deletes" ;) 18:31:16 stevemar: i'm in favor of A, with the caveat that names are not unique across domains, and we're not including domain references 18:31:17 I think we should go to b) from now, that shouldn't be a hurry to add the name 18:31:33 stevemar: so i'm inclined to suggest we should just dump the full object into the cadf payload 18:31:41 samueldmq, b) is quite a bit of work 18:31:41 dolphm so keeping the notification payload reasonably sized, right? 18:31:58 lbragstad: not necessarily lol 18:31:59 gyee: can't be done in this release or next ? 18:32:08 i'm ok with adding names, with all the regular caveats that names can change and you should be storing ids 18:32:11 gyee: it really isn't that much work. - also it buys us the "restore a deleted resource" option w/o needing magic "inject data into the db" commands 18:32:18 gyee: in worst case it will get in next cycle (1 release after the name can be added) 18:32:22 for free. 18:32:26 jamielennox: if we log BOTH it is better than just ids 18:32:28 samueldmq, not this release I don't think, but miracle do happen 18:32:36 notmorgan: it's always the API that bugs me about that, how do you request a deleted project? 18:32:46 we will still with name + id right? so this will be a unique combination across domains 18:32:50 dolphm: by "not including domain references" you mean the entire domain ref, we still need the domain name 18:32:50 jamielennox: same way as with nova ?deleted=true 18:32:54 shaleh: yes, logging both is fine 18:32:56 notmorgan: ++ 18:33:13 the project was deleted, not the domain, so we only need the domain ID 18:33:14 normorgan, that's not lifecycle managment, just a delete hack 18:33:22 /v3/projects/?RESSURRECT 18:33:29 gyee: no it allows us to do lifecycle management 18:33:36 gyee: right now... we don't really have that option 18:33:37 IFF IDS <-> mapping live forever we can just log IDs 18:33:38 jamielennox: not only that what if a project already exists with the deleted name... 18:33:41 short of a custom driver. 18:33:41 samueldmq: ++ 18:33:44 until then we need both 18:33:50 stevemar: i do just mean the flat ref 18:33:56 dolphm: i'm actually ok with just shoving all relevant data in cadf. 18:34:00 we have a lot more to discuss and we are half done 18:34:05 dolphm: if we don't blow out a maximum size 18:34:08 stevemar: if the domain hasn't changed, you can cache your GET /domains/{domain_id} call 18:34:11 dolphm: the flat ref will have the domain_id in there, that's good enough for me 18:34:17 Perf, use requests, name constraints 18:34:23 Swift ACLs 18:34:38 dstanek: notmorgan has explained his uniqueness theory before, it's a bit twisty but it would work 18:34:38 ayoung: swift ACLs should just be a "go read the ML thread and comment" 18:34:46 should we vote ? or is it just me wanting to do the delete thing now ? 18:34:49 samueldmq: no 18:34:59 no soft delete now 18:34:59 soft delete is step 2 18:35:02 just do the name thing. 18:35:06 i think we're OK now, dolph -- you good? 18:35:08 our resource objects arn't that big 18:35:10 step 3 is profit? 18:35:14 ayoung: always 18:35:25 flat ref in the notification? 18:35:26 stevemar: are we saying no to soft deletes in the application layer, then? 18:35:26 the change on how deletes are handled (don't call it "soft deletes") should be a proposed spec for O release ( shaleh you should write this) 18:35:40 dolphm: ^ 18:35:46 dolphm: today. i want a spec for O on this 18:35:48 not in newton 18:35:50 not worth it 18:35:53 right 18:35:54 too short of time 18:36:02 notmorgan: you can fight this all you like and implement it how you like - but the concept is what people refer to as soft deletes 18:36:09 jamielennox: shhhhhhh 18:36:22 i'm okay with saying no to soft deletes later then :P 18:36:23 notmorgan: my concern is that we add name/domain-name now and that won't be removed we support those deletes 18:36:26 next cycle 18:36:29 dolphm: lol 18:36:44 notmorgan: s/we/when 18:36:46 dolphm: i think we should do it for the main resources that "own" things, but that is a case to be made in the spec. 18:36:46 dolphm: alright, next topic? is this horse dead enough? 18:36:55 (i'm not entirely opposed to soft deletes, i'm just used to letting the db handle them) 18:36:59 dolphm: not *all* resources. 18:37:01 Horse has been turned int dogfood and glue 18:37:12 dolphm: and also i want the DB to handle most all of it still. ftr. 18:37:13 or *something* else besides the app 18:37:23 #topic Performance testing is available 18:37:28 lbragstad: you've got 3 minutes :P 18:37:29 i'll work with shaleh to make the spec clear on that. 18:37:31 Perf testing of what? 18:37:32 i'm kidding 18:37:35 well this is going to be short 18:37:39 it's there, you can use it 18:37:45 but im interested in feedback 18:37:50 lbragstad: this is a great start 18:37:50 https://github.com/lbragstad/keystone-performance 18:37:52 we could use updates to the developer docs to say how to use this 18:37:56 lbragstad: does it make sense to move into gerrit? 18:37:58 my only question 18:38:03 but awesome work 18:38:08 notmorgan good question, maybe at some point 18:38:22 lbragstad, nice handwriting! 18:38:29 but right now I for sure what to improve things and make the whole system a bit better before moving it into gerrit 18:38:46 lbragstad: thanks to be working on it! awesome work :) 18:38:48 lbragstad: awesome 18:38:51 so - feel free to use it, but it is only running on a single node 18:38:59 so don't add 'check performance' to every patch in review 18:39:06 lbragstad: so it's the same machine every time? 18:39:09 yes 18:39:10 * notmorgan makes a bot for that 18:39:14 using containers as the app node 18:39:17 lbragstad: did you get a proper 3rd party ci account? 18:39:20 yes 18:39:24 ok cool 18:39:29 it's call the 'OSIC Performance Bot' 18:39:31 how's that different from rally ? 18:39:38 because I can't name things for crap 18:39:58 it's running on dedicated hardware 18:40:01 samueldmq: a lot of history, lets not cover that here 18:40:02 samueldmq: much more focused on the hot path we care about 18:40:18 * samueldmq nods 18:40:26 if you have specific questions, please ask 18:40:42 but I'd like to try and get this improved and exposed to a bunch of feedback this release 18:40:47 lbragstad: so how do i invoke the perf tests on a given patch? 18:40:56 read the docs stevemar 18:41:02 leave a comment with 'check performance' 18:41:06 cool 18:41:06 in the message 18:41:19 nice 18:41:20 shaleh: i did, i was just trying to force lbragstad to write it out in the meeting for everyone's convenience 18:41:28 stevemar: :-) 18:41:31 ;) 18:41:35 lbragstad: awesome stuff 18:41:35 stevemar: shaleh :-) 18:41:38 hey siri…check... 18:41:40 write a bitcoin miner and recheck performance. 18:41:44 lbragstad, so benchmark spit out a html/pdf report? 18:41:45 i've also tried to add a bunch of docs about the infra. 18:42:08 so, let's use it ! 18:42:10 so - open issues if you find anything is missing 18:42:15 thanks lbragstad 18:42:19 or want to see enhancements, 18:42:21 this is great 18:42:21 no problem. 18:42:27 awesome work! 18:42:29 PRs welcome 18:42:31 :_ 18:42:32 next topic jamielennox 18:42:33 I've been looking at performance problems for a couple weeks now. 18:42:34 :) 18:42:43 #topic Use a request object in keystone 18:42:51 ok, i'll keep this quick 18:42:54 #link https://review.openstack.org/#/c/318658/ 18:42:57 what is the difference between a request and a context 18:42:58 what's the performance impact of using a request object in keystone? 18:43:11 bknudson: leave a comment on the patch and see :O 18:43:11 bknudson, premature optimization... 18:43:28 stevemar: ++ 18:43:33 so we've passed around this weird dict of context forever now and it results in all this checking whether things are in the dict or not and making guesses 18:43:35 * notmorgan checks performance on all the patches! 18:43:45 particularly given we end up passing the environment around everywhere in that dict anyway 18:44:00 jamielennox: i like using the real request objects 18:44:00 we need to integrate better with oslo.context and the objects passed down out of auth_token middleware 18:44:00 its better organization, I'll admit. Do we need to structure things more than just "request has a context dict" over time? 18:44:03 doesn't every openstack app pass around a dict of context? 18:44:08 and if so, what doe the end state look like? 18:44:21 so instead of just adding more crap to the dict i want to use real objects - with properties and stuff for attributes we care about 18:44:24 bknudson: somewhat, but a lot of it is now centralized in oslo_context (thread local things) 18:44:34 jamielennox: as long as request objects don't bleed lower than the controllers, then i'm on board 18:44:54 https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequest.html 18:44:55 notmorgan: couldn't we just use oslo.context then ? 18:44:57 we've got a oslo_context.RequestContext (was added for request ID) 18:45:08 bknudson: and we use it for the request_local caching too 18:45:09 so this patch is kind of big because it has to do a lot of router/controller level stuff in one go, but things beyond that should be normal review size again 18:45:27 the general pattern in Servlet programming was that you only read from the request, and write new data tothe response 18:45:31 bknudson: so we could just use oslo_context 18:45:37 dstanek: i see no reason for them to go futher than context does now 18:45:37 samueldmq, it will add even more spagetti code 18:45:48 and state was saved ewither in the session (which we have none) and the database 18:45:55 jamielennox: +2 from me then 18:46:13 so...why only a request object, and not a response? 18:46:13 i'm OK with it, i always found the way we pass the context around a bit weird 18:46:19 amakarov: so other openstack projects adoption oslo.context are making spaghetti code ? 18:46:28 samueldmq: yes 18:46:31 samueldmq, I think so 18:46:34 yeah....jamie this is long overdue 18:46:40 anyway, i want to make it so that everyone knew about this and there are a number of conflicting reviews so i would like to get this merged if we all agree 18:46:43 ayoung: next step? 18:47:02 jamielennox: ++ 18:47:08 henrynash_: you'll have the rest of the time for your topic 18:47:19 ayoung: because ATM i need more access to the inputs and haven't had to worry about the writing 18:47:24 jamielennox: sounds good 18:47:35 stevemar: thx 18:47:37 jamielennox: sounds like everyone is okay with it 18:47:42 ayoung: but i'm silently keen to change up all the routers as well one day 18:47:43 its a start 18:47:53 jamielennox: flask? 18:48:04 I want a proper token/auth-data pipeline 18:48:06 dolphm: ++ 18:48:06 next topic coming up 18:48:12 dolphm: yes flask! 18:48:14 brace yourselves 18:48:16 #topic Project name constraints & project hierarchical naming 18:48:19 dolphm: i looked and it's just a massive change that requires rewriting all the protected stuff 18:48:21 ok 18:48:21 brace yourselves is right 18:48:31 dolphm: this at least gets us to request objects which is a step in the direction 18:48:33 * stevemar sits back and grabs popcorn 18:48:38 jamielennox: ++ 18:48:42 stevemar: lol 18:48:45 so we;ve been hashing this one around a while 18:48:45 stevemar: scoot over 18:48:57 jamielennox: take a look at my flask patch - it wasn't terrible to do 18:48:59 * notmorgan has nothing else to add that isn't on the ML/talked with henrynash_ directly 18:49:09 (more accurately morgan has been knockig holes in various suggestions!) 18:49:17 * gyee is comfortable numb 18:49:21 https://media.giphy.com/media/qR6UR8K1Ia2BO/giphy.gif 18:49:23 latest incarnation is https://review.openstack.org/#/c/318605/ 18:49:51 which goes for the “make project name the path” approach 18:49:52 are we gonna -2 this or not? Is there anything left to say? 18:50:03 dstanek, for me flask is better than the pylons legacy we call routers now :) 18:50:14 i'll admit i haven't read the latest ML posts 18:50:29 as described, I think this does not allow us to maintain compatibility with v3.6 clients and before 18:50:51 henrynash_, we can't config value our way out of this hole? 18:51:06 ayoung: not really 18:51:07 amakarov: i'm going to bring back that patch 18:51:11 henrynash_: did someone poke a hole in clint's suggestion? name and basename? 18:51:25 stevemar: doesn 18:51:31 it seemed the least breaky to me 18:51:40 what's stopping V4? 18:51:41 solve the unique name constraing in 3.6 18:52:08 stevemar: isn't that eventually backwards incompatible? 18:52:16 stevemar: unless you never expect post 3.7 projects to 3.6 18:52:22 stevemar: so I articulated the compatibilit requiremenets in a reponse on the mailing list, I don’t see how we maintain 3.6 cleints 18:52:23 expose* 18:52:25 dolphm: yes. 18:52:35 well, then, hole poked. 18:52:41 with that approacj 18:52:45 dolphm: very much so 18:52:49 dolphm: it was the same hole i poked in removing 3.6 at all 18:52:49 gyee, we haven't dragged OpenStack from v3 to v3 yet, and now you want to announce v4? People will linch us! 18:53:00 amakarov: also true 18:53:00 s/v3/v2/ 18:53:01 no v4 required 18:53:15 amakarov: ++ 18:53:19 so two questions for y’all to ponder: 18:53:40 henrynash_: "full name" also might be a good attr instead of "path" ? 18:53:44 henrynash_: side thought. 18:53:45 that's all because we hadn't the full roadmap when we first implemneted hierarchical projects :( 18:53:49 henrynash_: but that is bike-shedding 18:53:57 :( 18:54:05 1) Since this is the only cure we could come up with (that maintains compatility), is the cure still worse than the disease? 18:54:06 samueldmq: even if we had, we'd have broken a TON of people 18:54:14 samueldmq: and it would still be a no-go 18:54:37 I can't keep track of the objections and the counter solutions 18:54:38 i strongly believe that the reseller case is better with domains 18:54:56 2) (much more minor) severel questions on consistency in the current proposal (e.g. should you be abel to use name including a path on create project) 18:54:56 and de-uniquing the names in a given domain doesn't provide a lot on that front 18:55:00 notmorgan: maybe it wouldn't break that much if we made hierarchical project experimental and come with this in the next cycle 18:55:09 notmorgan: but nevermind, let's solve what we have today 18:55:09 samueldmq: it breaks auth 18:55:13 samueldmq: that is the issue. 18:55:22 we could go with ldap style naming "domain=pepsi,project_name=top,project_name=middle" 18:55:27 (let's not break auth) 18:55:38 notmorgan: because root projects now have a parent (is_domain ?) 18:55:38 henrynash_, closure table can be used to identify projects without unique naming and storing full path in the name 18:55:39 ayoung: thats basically what i've proposed, just with / instead 18:55:40 sorry, we need to make that longer 18:55:44 we could go with ldap style naming "domain_name=pepsi,project_name=top,project_name=middle" 18:55:50 samueldmq: i'll go over that outside of here 18:56:04 so "domain_name=pepsi/project_name=top/project_name=middle" 18:56:13 ayoung, UX people will look for ya 18:56:15 ayoung: no, never 18:56:25 yeesh 18:56:25 OK, back to the question 18:56:27 ayoung: that is effectively my proposal fwow, but was domain/px/py/pz 18:56:30 ayoung, let's writhe our own LDAP! 18:56:31 jamielennox, scared at how quick people take me seriously 18:56:35 ayoung: that is too convenient. Make it more cumbersom please 18:56:38 what if my name was domain_name=pepsi/project_name=top ? 18:56:41 ayoung: since domains are always the root. 18:56:42 write 18:56:43 shaleh, XML? 18:56:44 ayoung: this was erring on the side of caution 18:56:51 heh 18:56:52 ayoung: good start 18:57:05 Assuming you agree that we CAN solve this, without breaking compatibility (as per the current poposal https://review.openstack.org/#/c/318605/), is this worth doing 18:57:26 so OS_PROJECT_NAME="domain/pepsi/top/middle" would work for scoping a token 18:57:37 henrynash_, oh yes it is 18:57:44 henrynash_, we don't need it: https://review.openstack.org/#/c/285521/ 18:57:54 ayoung: yes (although with a leading /) 18:58:02 yes we can, lets make it great again, a future we believe in 18:58:05 OS_PROJECT_NAME="/domain/pepsi/top/middle" would work for scoping a token 18:58:09 henrynash_, do you want materialized path with names? 18:58:12 ayoungL yes 18:58:23 amakaraov: implmentation detail 18:58:25 ayoung: that would be the idea. it would match "name" or "path" 18:58:30 henrynash_, and what hoops do we need to jump throughto get there 18:58:32 ayoung: in the case of old projects. 18:58:47 ayoung: since some projects might be "ProjectName" only 18:58:49 this is getting nasty 18:59:05 voice opinions on the ML or https://review.openstack.org/#/c/318605/ (or both) 18:59:13 notmorgan, /domain becomes a reserved project name? 18:59:18 stevemar: i don't think we need this, but i offered an alternative when i poked holes in it 18:59:18 so, i don't know how to say this better - but it's just not nice 18:59:27 not allowed as either project or domain, or as the start of either? 18:59:37 ayoung: no /// 18:59:38 notmorgan: that's my next question, do we need this? 18:59:44 colleagues, closure table will allow to address project by path, index hierarchies, and leave project name be 18:59:50 but we're at time... 18:59:53 stevemar: i don't think we need it. but there is a ux concern 18:59:55 to -keystone 19:00:06 some orgs want /domain/acc/dev 19:00:09 notmorgan, so first link is alwyas domain? 19:00:09 thanks to everyone for joining 19:00:10 and /domain/ops/dev 19:00:15 #endmeeting