18:02:21 #startmeeting keystone 18:02:22 Meeting started Tue Jun 24 18:02:21 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:26 The meeting name has been set to 'keystone' 18:02:30 o/ 18:02:35 nothing new on the hackathon front, so: 18:02:39 #topic Keystone Middleware Repo Created! 18:02:39 \o 18:02:42 morganfainberg_L: o/ 18:02:45 Middleware Repo is in! 18:02:54 now the real work begins 18:02:57 all new middleware code changes should go against keystonemiddleware 18:03:00 yay another thing to track in gerrit 18:03:08 so at some point it gets released 18:03:11 morganfainberg_L: do we have patches to move everything over? 18:03:16 any reason it can't be released today? 18:03:30 we need to deprecate keystoneclient.middleware.* 18:03:32 bknudson: i want to make sure we're not missing anything before we release 18:03:37 bknudson: but other than that no 18:03:46 personally I'd rather changes were covered by tempest before merging anything new 18:03:49 add to devstack 18:03:55 dolphm: everything should be moved over, history was preserved 18:04:05 ayoung: yes, i am going to be proposing that fix today 18:04:09 ++ 18:04:14 I think devstack will install it once it's in requirements.txt 18:04:15 bknudson: tempest and stable bitrot jobs are included 18:04:28 morganfainberg_L: i was including that ^ in the notion of "move everything over" 18:04:34 bknudson: no, it needs to be sources frmo the repo, like django_openstack_auth 18:04:41 dolphm: ++ 18:04:48 the initial release will be 1.0.0 18:04:49 swapping imports in other projects as well 18:04:56 we're calling this "stable" :) 18:04:57 morganfainberg_L: ++ 18:05:14 LP project has been created, pypi target as well 18:05:22 dolphm holds the keys to release (same as ksc) 18:05:27 once it's released we'd change other projects to use it? 18:05:37 morganfainberg_L: let me know when to push buttons 18:05:40 bknudson: we can do an alpha release and do some initial work on that 18:05:52 y, i'd expect an alpha release 18:06:05 #action Everyone: add openstack/keystonemiddleware to your watched projects in gerrit 18:06:13 bknudson: basically, everyone do a once over, make sure it looks right, i'm working on the devstack front 18:06:33 if there are no issues we can release an alpha (and get it in global reqs) soon 18:06:59 #action We need tests for ec2_token middleware 18:07:03 http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/ 18:07:07 hehe 18:07:10 there weren't any afaict 18:07:24 so i didn't port any 18:07:24 * ayoung takes a note that we are going to need a new RPM 18:07:51 i verified before the repo was created docs build worked, pep8, and py27 worked 18:08:23 morganfainberg_L: proposed a change to openstack/governance https://review.openstack.org/#/c/102305/ 18:08:25 once we release we can deprecate all the other middlewares. I'll be retargeting bugs in LP for ksc against middleware this week. 18:08:33 dolphm: ++ :) 18:09:23 uh.. thats it from me :) 18:10:09 so we can stop watching keystoneclient? 18:10:14 morganfainberg_L: danke! 18:10:15 topol, you can 18:10:18 topol: hell no 18:10:27 heh 18:10:28 keystoneclient still has the python API 18:10:45 topol, nope, just the middleware is being separated, still has all the library and API stuff 18:10:49 dolphm: i'll send a nice email to -dev mailing list today as well. 18:10:56 we'll have to alert packagers as well 18:10:57 morganfainberg, ++ 18:11:11 dolphm: sould i x-post to main openstack list? 18:11:18 so on the keystone info page someone will update so newbies can find all the repos and what is in what? 18:11:21 morganfainberg_L: i'd send a different note in that direction, honestly 18:11:30 dolphm: ok 18:11:38 dolphm: maybe we should wait to send there until we release 18:11:39 morganfainberg_L: want to etherpad both? i could contribute a bit 18:11:43 dolphm: ++ will do 18:11:44 morganfainberg_L: ++ 18:11:44 does keystonemiddleware have its own launchpad? (and where do bugs get reported?) 18:11:45 cause we have blossomed a little :-) 18:11:50 bknudson: yes it does 18:12:07 #action topol to update keystone info page 18:12:12 #action dolphm to move bugs to https://launchpad.net/keystonemiddleware 18:12:13 https://launchpad.net/keystonemiddleware 18:12:33 dolphm: let me know if you want help moving bugs around 18:12:33 ayoung, cool. folks give me authority to do that? 18:12:41 no bugs in keystonemiddleware now 18:12:45 nice 18:12:49 yep its empty 18:12:52 I checked 18:13:02 topol: you can grant yourself that authority i believe... 18:13:06 k 18:13:25 anyone have a link to the keystone bug team thing? i can't remember what it's called 18:13:27 I'll handle 18:13:28 #action ayoung to set all keystoneclient middleware bugs to "also affects keystonemiddleware" 18:13:33 keystonedrivers? 18:13:41 #link https://launchpad.net/~keystone-drivers 18:13:42 topol, https://wiki.openstack.org/wiki/Keystone might want to add the keystone-specs too :D 18:13:45 morganfainberg_L: no, there's a public group 18:13:49 dolphm: oooh 18:13:52 stevemar ++++ 18:13:53 dolphm: uh 18:14:24 i have no idea where to find it... 18:14:29 ooh 18:14:29 Current middleware bugs https://bugs.launchpad.net/python-keystoneclient/?field.searchtext=middleware&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=& 18:14:29 field.has_no_package= 18:14:36 anyone can join this group https://launchpad.net/~keystone-bugs 18:14:38 let me try that again 18:14:45 https://bugs.launchpad.net/python-keystoneclient/?field.searchtext=middleware&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= 18:14:50 the keystonedrivers group (core) should have access to update the middleware lp page as needed (Same as ksc) 18:15:01 dolphm: please 2x check i don't need to "fix" anything in the lp page for middleware 18:15:10 i think i got it all so you/other cores can fix as needed 18:15:38 morganfainberg_L: it all looks right to me 18:15:39 i also created 1.0.0 milestone pre-emptively 18:16:08 is it going to be a problem that it is keystonemiddleware and not python-keystonemiddleware? 18:16:14 ayoung: no 18:16:17 at least, that is what launchpad calls it 18:16:21 morganfainberg_L: you actually made a 1.0.0 series... which should be a 1.x.x series 18:16:30 dolphm: ah lets fix that then 18:16:33 morganfainberg_L, than can we renamte python-keystoneclient to keystoneclient? 18:16:34 morganfainberg_L: done 18:16:42 Not asking to 18:16:48 morganfainberg_L: you can then create a 1.0.0 milestone within that series 18:16:48 asking if it would be possible, or 18:16:58 dolphm: hm, looks like i can't remove a series? 18:17:05 oh you fixed:P 18:17:06 if something requires the python- prefix? 18:17:07 haha 18:17:07 morganfainberg_L: maybe because i just renamed it 18:17:11 I though it was a package thing 18:17:26 ayoung: nah, otherwise keystone would need it as well 18:17:55 morganfainberg_L, I guess we'll find out 18:17:56 * gyee planning on checking in java middleware in that repo as it longer prefix with python- 18:18:04 ayoung: someone might write a .NET client and call it .NET-keystoneclient 18:18:20 keystone client will eventually be depracted via openstack client correct? 18:18:23 unix folks would never see it 18:18:27 topol: the CLI 18:18:32 topol: not the library part 18:18:40 topol, that's the rumor 18:18:41 i know someone has implemented c++ middleware for keystone 18:18:45 well, maybe the openstacksdk will make it useless 18:18:51 2 bugs now 18:19:02 but the library is now going into middleware or am I confused as usal/ 18:19:05 in theory, we could have non-python middleware in that repo eventually. 18:19:08 and rackspace has a java version http://openrepose.org/ 18:19:17 then we also have the cms code in python-keystoneclient 18:19:48 bknudson: i think we need a python-keystonelib package for cms... 18:19:49 we are not targetting python 2.6 for middleware, correct? 18:20:05 ayoung: middleware is the same as ksc 18:20:14 ayoung: we haven't dropped 2.6, therefore we can't drop it here 18:20:19 morganfainberg_L, OK 18:20:30 there was a summit session on 2.6 - does anyone know the outcome? 18:20:41 dolphm: suse was the one up in the air still 18:21:06 dolphm: on dropping 2.6? i heard that we can't because of a linux distro 18:21:08 dolphm: everyone else was ok with dropping 2.6, long term 2.6 support will last until we EOL the last of the releases that had 2.6 support 18:21:10 i don't see a summit etherpad on the topic 18:21:12 I think that RH has pulled the requirement 18:21:28 we have "collections" now which lets us run python >2.6 for openstack 18:21:29 so where is suse at on support? 18:21:42 dolphm: my guess is K will be where we drop 2.6 18:22:06 dolphm: https://etherpad.openstack.org/p/juno-cross-project-future-of-python 18:22:10 dropping 2.6 support would be a huge advantage for the gate 18:22:24 dolphm: gate will still need to support 2.6 for EOL purposes 18:22:49 dstanek: thanks! 18:22:57 yes, they said that they'll have a very long time before they get rid of the gate support 18:22:58 morganfainberg_L: only on stable/ though, right? 18:23:16 right 18:23:33 middleware likely will need to remain 2.6 compat until we drop the last 2.6 capable release to EOL 18:23:40 (likely Juno will still be 2.6 compat) 18:23:43 well, then nothing to get excited about for now 18:23:54 #topic open discussion 18:24:20 morganfainberg_L, but that would be the old packages 18:24:24 not keystonemiddleware 18:24:31 just python-keystoneclient 18:24:45 ayoung: if juno is 2.6 compatible, middlware will need to keep it since we'll be adopting the new packaging this cycle 18:24:58 morganfainberg_L, we are going to need to keep the existing packageset for older releases 18:25:18 ayoung: yep. clients will be in the same boat 18:25:19 OK, so we'll get 2.6 as a req that way 18:25:25 dolphm: publish your secret reviewday support when you have a chance - i'd love to start trying it out 18:25:45 dstanek: lol ++ 18:26:27 any specs we think are ready to go in? 18:26:45 if we don't get any specs in then this is going to be a pretty small release 18:26:53 i'd like to appeal to folks to review https://review.openstack.org/#/c/100023/ -> 'federating multiple keystone', it's getting kind of ugly and complicated 18:27:01 dolphm: https://etherpad.openstack.org/p/dev_keystonemiddleware_anouncement 18:27:27 morganfainberg, your etherpad is rather empty 18:27:32 stevemar: shush 18:27:35 stevemar, I'd like to ask a question about that 18:27:36 :P 18:27:45 kwss ! go ahead 18:28:13 Will keystone to keystone federation use the same mapping / attribute trust mechanisms as saml2 etc.? 18:28:23 stevemar: yes, i want to go over that again today - started looking yesterday after jsavak pushed 18:28:26 good question 18:28:51 kwss: very good question 18:29:13 I don't see why not 18:29:17 stevemar: ugly and complicated sounds like you have work to do before appealing to reviewers :P 18:29:18 kwss: i think it should 18:29:24 me too 18:29:36 i don't see the difference between k2k and federation 18:29:52 dstanek, exactly 18:29:59 dolphm, actually, i wanted you to weigh in on it, its growing too big, there are too many use cases being proposed 18:30:40 stevemar: that's the danger with federation it seems - need to narrow the use case that we pursue to ONE, and ensure that we're making room to support the rest later 18:32:01 ayoung: wow, thanks for moving bugs over 18:33:04 I think that all protocols should use the same common mechanisms 18:33:05 kwss & others: https://review.openstack.org/#/c/100279/ -- this spec looks like a good to me! 18:33:07 ayoung: i think session tokens are important if we can shore that spec up. 18:33:08 morganfainberg_L, wilco 18:33:09 bknudson: that one looks close. 18:33:09 stevemar: all of the use cases i have seen are very similar 18:33:10 bknudson: at the very least like a decent idea with a lot of thought put into it 18:33:10 kwss, so both keystone instances should be running something like mod_shib to talk to each other? 18:33:10 morganfainberg_L: I think it exposes that we've got a security issue in idps 18:33:10 bknudson: we do. 18:33:10 morganfainberg_L: more like an issue of trusting too much 18:33:10 bknudson: ++ 18:33:11 bknudson, only when using regex ? 18:33:11 stevemar: y, the regex 18:33:11 bknudson: if we can narrow that down to be more restrictive it would def. be good 18:33:34 stevemar, the actual communication between the two servers is a separate issue, I meant the same mechanisms are handling mapping / authorization 18:33:52 dolphm, yeah...pretty easy once I got rolling 18:34:03 some of those will end up falling squarely on one side or the other 18:34:27 ayoung: ++ i'm copying statuses over on the ones you're marking as affecting keystonemiddleware 18:34:37 kwss, if we can re-use them, then sure 18:34:44 dolphm, it does mean that all reafactorings from auth_token middleware to keystoneclient will start with adding code to the client, and then a second review to remove from the middleware 18:34:47 dolphm, ++ 18:35:22 ayoung: I think there's no more changes to keystoneclient middleware except for security fixes 18:35:31 bknudson: ++ 18:36:23 bknudson: we can't just do an import from keystonemiddleware ? 18:36:27 kwss, you mean the mapping engine, and leveraging groups and roles? 18:36:33 bknudson, right. I'm talking about the keystonemiddleware version. Now that the middleware is split from the client, and since we still have more refactoring to do, we will have to split reviews over both repos 18:36:38 dolphm: no, circular dependency! 18:36:49 ayoung: yes. 18:36:54 stevemar, what I'd like to see is a flow which is separated into protocol dependent i.e keystone to keystone communication and protocol independent (mapping etc.) operations 18:37:12 ayoung: and changes to client need a release before they can really be consumed by the middleware 18:37:27 kwss, i'd love to see that too! but I can't seem to get passed the darn use cases right now 18:37:38 too many use cases :-( 18:37:49 bknudson: that's why i'd like to have keystonelib 18:37:59 stevemar, yea and hopefully trusted attribute filter too 18:37:59 kwss, topol too many voices (in my head and in the review) 18:38:14 dolphm: i'd be happy to do the same work to split the stuff out if we can identify what we want split 18:38:17 stevemar +++ what do you recommend 18:38:20 dolphm: it's not hard (just timeconsuming) 18:38:28 stevemar, what can I do to help? 18:38:47 morganfainberg_L: off the top of my head, i'm only aware of keystoneclient.common.cms 18:38:53 dolphm: session? 18:39:19 kwss, in line comments in the review, and if you have time, can we chat after? 18:39:23 stevemar: i'm sorta interested in the higher level usecase - be able to federate keystones just like anything else 18:39:23 morganfainberg_L: hmmmmmmm 18:39:28 morganfainberg_L, ooh. that is going to be painful. middleware will only test against a released version of the client 18:39:35 ayoung: yep 18:39:45 stevemar, sure to both, I'll point David at the review too 18:39:46 stevemar: we seem to be making this too complicated 18:39:52 ayoung: though i can work aroudn that in devstack with a little magic 18:40:16 ayoung: i'll be putting those reviews up today. 18:40:28 dstanek, that was my comment about ugly and complex 18:40:57 though craig has a good point about the terminology, we're not being consistent right now 18:41:13 dolphm: if sesson and cms were not in ksc (and then auth plugins?) then we could avoid a lot of circular deps 18:41:26 could we cut federation down to 2 primary use cases? 18:41:27 stevemar: what is the timeline to get this approved? it seems like a good discusson for the hackathon 18:41:35 and stay focused? 18:41:36 dolphm: though i'd really want to talk to jamielennox before we try to split that stuff out 18:41:37 topol: that would be nice :) 18:41:46 morganfainberg_L: ++ 18:42:07 morganfainberg_L: if the use case for cms is agreeable, i can create a spec for just that, and we can go case by case? 18:42:09 dolphm: but it would likely make other clients consuming session and auth plugins waaaay easier 18:42:22 topol, i think that is a good idea 18:42:23 my opinion was that we should remove the keystonemiddleware dependency from keystoneclient and do the imports 18:42:29 it's essentially optional 18:42:31 i'm a fan of the bursting one 18:42:45 bknudson: ? long term or immediately? 18:42:48 dstanek, i was really hoping to have this approved or near approved for the hackathon 18:42:50 topol: agreed, but i think all of the uses cases should be captured and then we can generalize that in the spec say exactly which ones will be focused on 18:43:02 bknudson: so if middleware is available import? 18:43:04 dstanek, ++ 18:43:07 dolphm: I think we'd need to give it some small amount of time 18:43:09 we always have another release, another hackathon in SAT, unless dolphm runs out of good restaurants to take us too 18:43:13 bknudson: sure 18:43:30 bknudson: and remove the middleware in ksc completely? 18:43:36 morganfainberg_L: no need to check if it's available... paste isn't going to start with it. 18:43:37 topol: we need to start having them at a beach 18:43:50 bknudson: ok i'm confused. 18:44:09 bknudson: explain it like i'm 5 :P (ugh, i feel fogged today) 18:44:12 dstanek, shame. we come to SAT to get things done, not see you in your speedo :-) 18:44:19 morganfainberg_L: no, ksc still does the imports 18:44:30 topol, nice visual 18:44:31 morganfainberg_L: the middleware is only used if you put it in your paste pipeline 18:44:35 right 18:44:42 it's not used if you're just making use of the client 18:44:57 so keystoneclient.middleware imports keystonemiddleware? 18:44:57 so regular apps aren't going to fail if they don't have the middleware around 18:45:18 but there isn't a dep to install keystonemiddleware explicitly 18:45:19 ? 18:45:26 dstanek: hawaii? 18:45:43 morganfainberg_L: right. no middleware in ksc requirements 18:45:47 I think that might be going too far 18:45:52 I can get myself approved for hawaii but probably not everyone else :-( 18:46:00 we need to package up keystonemiddleware anyway 18:46:07 it's the easiest way to include both the US and australia 18:46:11 dolphm: sounds great! 18:46:13 i mean, it's only logical 18:46:23 and doing that implies a bunch of changes beyond the paste change 18:46:27 I +1 that logic 18:46:27 bknudson: that would break some EOL releases with new keystoneclient releases though 18:46:38 bknudson: that was my only real concern. and grizzly is widely used 18:46:39 * topol face palm trying to get hawaii approvals... 18:46:45 yeah 18:46:48 i see how it is, henrynash and I aren't even included 18:46:49 too much to break 18:46:49 topol: don't worry i'll have my speedo in SAT - i'll wear it for casual Friday 18:47:10 bknudson: it's why the spec opted for sec-maintenance for the middleware in ksc 18:47:11 morganfainberg_L: y, it wouldn't affect us since we don't package that way 18:47:19 dstanek, I'll have to skip lunch to be safe then :-) 18:47:28 but people do use newer clients with older services 18:47:45 * dolphm hackathon update: for everyon's own safety, do not show up on friday 18:47:57 dolphm: ? 18:48:00 fri the week before? 18:48:01 joke 18:48:11 oh oh 18:48:12 is there a gun show? 18:48:12 damn it 18:48:13 lol 18:48:16 Ok, any thoughts on this: is there anyway to to endpoint binding of tokens without endpoints knowing their own ids? 18:48:19 lol 18:48:25 morganfainberg_L: dstanek's gun show featuring speedos 18:48:27 * morganfainberg_L facepalms 18:48:33 i uh... 18:48:33 I assume we're allowed to open carry there? 18:48:34 no 18:48:43 suns out guns out? 18:48:44 bknudson: conceal only in texas 18:49:09 ayoung, sure, each endpoint have their own unique cert/private key 18:49:22 gyee, nope 18:49:23 just encrypt the toke for that endpoint only 18:49:30 that doesn't work for multi 18:49:38 so token is for 3 endpoints only 18:49:45 that only works for one specific endpoint 18:49:55 you issue the token for that endpoint only 18:50:17 so encrypting it with the endpoint's public key 18:50:18 gyee, that is a lot of infrastrucutre 18:50:38 ayoung, but arn't we pushing PKI already? 18:50:47 and it seems like a misuse of crypto. THere is nothing wrong with othser services seeing the token contents 18:51:13 bknudson: largely speaking, you can use 0.9.0 keystoneclient (and middleware) as far back as you want as long as you configure it correctly 18:51:21 why, if that token is only good for that particular endpoint 18:51:22 lbragstad... its in the constitution son 18:51:29 gyee, and, really, that is just replace "endpoint id" with "endpoint keypair" 18:52:02 it also lets endpoints share keys, which seems totally reasonable 18:52:12 morganfainberg_L: y, and you need to start installing all the new deps for 0.9.0... good luck! 18:52:24 dolphm, sure, PKI is made for that stuff 18:52:27 dolphm, shared keys does not seem reasonable to me 18:52:38 you'd have to share a private key 18:52:48 bknudson: hm. how far have the deps changed (conflicted) since say... grizzly release (assuming no one uses folsom) 18:52:49 which is generally frowned upon 18:52:53 multiple instances of an endpoint? 18:53:04 ayoung: if i deploy two services on the same node, i'm might not care that they share private keys, etc 18:53:20 ayoung: or like glance api and glance registry, for example 18:53:25 sure multiple instances of an endpoint have to share the same keys 18:53:35 my thought, though, is that if we need to give each endpoint an identity of some sort, then maybe we use that identity for fetching policy after all 18:53:56 I really don't want to build that infrastructure unless it is well justified 18:54:00 I don't think it is yet 18:54:06 endpoints should have an identity anyway 18:54:17 gyee, why not the service users 18:54:20 that seems to make more sense 18:54:29 but we can't bind a token to a service user 18:54:35 they can use the service identity sure 18:54:53 actually, we totally could 18:54:57 but an identity can have multiple keys 18:54:59 morganfainberg_L: our issue is that we need to go through legal to get new packages approved 18:55:15 token { "service_user":"keystone"} means only the keystone service user should treat the token as valid 18:55:43 endpoint-scope and service-scope, killing two birds with one stone 18:55:47 why can't all users just have keys? 18:55:47 but we'd need that information when we issued the token. And there is no link in keystone between the service users and the endpoiints yet 18:55:53 apologize to the animal lovers 18:56:00 we don't need PKI for this 18:56:01 and then all everything barbican everywhere 18:56:09 we just need to identify who can use the token 18:56:10 bknudson: aren't you going to have to do that anyway even with what you're proposing? 18:56:35 dude, we are using PKI tokens already! 18:56:38 make it count 18:56:46 morganfainberg_L: well, we handle new releases, but old releases use old client. we're not affected 18:56:47 gyee, we have one service that requires tokens, not everywhere 18:57:04 lets not build things just to build them 18:57:05 ayoung, I mean the framework is already there 18:57:10 people get lynched that way 18:57:10 just make use of it 18:57:14 no, it really is not 18:57:25 I mean, I like PKI as an option 18:57:34 just not a hard requirement, for the endpoint to validate to keystone 18:57:45 I think PKI is a great option for this stuff 18:57:54 gyee, option, yes 18:57:56 requirement, not 18:57:58 still don't see how that really affects things here. i'm thinking from the standpoint of a couple companies i know that use latest *client* + grizzly services and breaking their deployment with the next ksc relese would be ugly 18:58:04 and, it is beside the point 18:58:10 the issue is not PKI or no PKI 18:58:24 I though you ask how to make the stuff work 18:58:26 morganfainberg_L: they can't install keystonemiddleware? 18:58:34 the issue is "do we use the endpoint id for policy fetch" and "do we use the endpoint id for token binding" 18:58:42 if not, then what do we do 18:58:58 they can, but i am not seeing a compelling argument to break them? 18:59:04 * dolphm 1 min 18:59:13 and I think the policy fetch is leaning toward "use the service users context" 18:59:19 bknudson: i might be missing the point of ripping it out in a hurry 18:59:22 thats all 18:59:45 talk morein -keystoen after meeting 18:59:58 ayoung, service account should be fine, services owns the endpoints anyway 19:00:15 morganfainberg_L: we can take as long as we think is prudent 19:00:24 #endmeeting