Monday, 2018-08-06

« Sunday, 2018-08-05 Index Tuesday, 2018-08-07 »
*** chason has joined #openstack-keystone01:21
wxy-xiyuankmalloc: yeah, it's a bug for json home in unified limit02:38
wxy-xiyuanthanks for catching it. leaved comment in your patch. You may fix it together. :)02:39
openstackgerritMerged openstack/keystone master: Code optimization of create application credential  https://review.openstack.org/58847103:48
*** d34dh0r53 has quit IRC04:00
*** cloudnull has quit IRC04:00
*** eglute_s has quit IRC04:00
*** eglute has joined #openstack-keystone04:04
*** d34dh0r53 has joined #openstack-keystone04:04
*** d34dh0r53 has quit IRC04:05
*** eglute has quit IRC04:05
*** eglute has joined #openstack-keystone04:06
*** d34dh0r53 has joined #openstack-keystone04:06
*** cloudnull has joined #openstack-keystone04:11
*** shyambiradar has joined #openstack-keystone05:03
*** viks_ has joined #openstack-keystone05:10
*** hoonetorg has quit IRC05:28
*** shyambiradar has quit IRC05:33
*** hoonetorg has joined #openstack-keystone05:42
*** shyambiradar has joined #openstack-keystone05:47
*** nicolasbock has joined #openstack-keystone06:05
*** pcaruana has joined #openstack-keystone06:07
openstackgerritVishakha Agarwal proposed openstack/keystone master: Add openstack_user_groups to assertion  https://review.openstack.org/58821106:34
*** martinus__ has joined #openstack-keystone06:46
openstackgerritVishakha Agarwal proposed openstack/keystone master: Add openstack_user_groups to assertion  https://review.openstack.org/58821106:50
*** rcernin has quit IRC06:52
openstackgerritwangxiyuan proposed openstack/keystone master: [wip] Remove redundant get_project call  https://review.openstack.org/58902707:07
*** jhesketh_ has joined #openstack-keystone07:10
*** jhesketh has quit IRC07:11
*** Emine has joined #openstack-keystone07:41
*** dtantsur|afk is now known as dtantsur07:59
*** Emine has quit IRC08:08
*** jaosorior has joined #openstack-keystone08:21
*** shyambiradar has quit IRC08:24
*** Emine has joined #openstack-keystone08:32
*** josecastroleon has joined #openstack-keystone08:36
*** shyambiradar has joined #openstack-keystone08:38
openstackgerritVishakha Agarwal proposed openstack/keystone master: Add openstack_user_groups to assertion  https://review.openstack.org/58821109:06
openstackgerritwangxiyuan proposed openstack/keystone master: [wip] Remove redundant get_project call  https://review.openstack.org/58902709:19
*** Emine has quit IRC09:36
*** Emine has joined #openstack-keystone09:52
*** Emine has quit IRC09:52
*** Emine has joined #openstack-keystone09:53
*** vishakha has joined #openstack-keystone09:57
vishakhawxy-xiyuan: https://review.openstack.org/#/c/588211/ waiting for your response on this09:58
*** martinus__ has quit IRC10:17
wxy-xiyuanvishakha: find a nit. Otherwise look good. Thanks for the quick update.10:21
*** shyambiradar has quit IRC10:28
openstackgerritVishakha Agarwal proposed openstack/keystone master: Add openstack_user_groups to assertion  https://review.openstack.org/58821110:29
vishakhawxy-xiyuan: updated the patch with your comments10:34
vishakhalbragstad[m]: Hi,  Regarding this bug10:37
vishakhahttps://bugs.launchpad.net/keystone/+bug/1473292. Can I propose a blueprint for "Implementing trust_flush via keystone-manage". Is this seems valid ? Thanks10:37
openstackLaunchpad bug 1473292 in OpenStack Identity (keystone) "Cannot delete or show a trust with an expired date" [Wishlist,Triaged] - Assigned to Vishakha Agarwal (vishakha.agarwal)10:37
*** shyambiradar has joined #openstack-keystone10:46
*** dave-mccowan has joined #openstack-keystone10:47
*** dave-mccowan has quit IRC11:03
*** shyambiradar has quit IRC11:05
*** shyambiradar has joined #openstack-keystone11:13
*** shyambiradar has quit IRC11:30
openstackgerritzhengliuyang proposed openstack/keystone master: More accurate explanation in api-ref:application credentials  https://review.openstack.org/58913512:07
*** shyambiradar has joined #openstack-keystone12:15
*** raildo has joined #openstack-keystone12:20
openstackgerritwangxiyuan proposed openstack/keystone master: Remove redundant get_project call  https://review.openstack.org/58902712:20
*** raildo_ has joined #openstack-keystone12:24
*** raildo has quit IRC12:26
*** josecastroleon has quit IRC12:33
*** dtantsur is now known as dtantsur|brb12:36
*** josecastroleon has joined #openstack-keystone12:48
*** dave-mccowan has joined #openstack-keystone12:53
*** mchlumsky has joined #openstack-keystone12:56
*** shyambiradar has quit IRC12:59
*** dave-mccowan has quit IRC13:03
*** mchlumsky has quit IRC13:04
*** mchlumsky has joined #openstack-keystone13:06
*** edmondsw has joined #openstack-keystone13:13
*** jroll has quit IRC13:19
*** jroll has joined #openstack-keystone13:19
*** lbragstad has joined #openstack-keystone13:43
*** ChanServ sets mode: +o lbragstad13:43
knikollao/13:56
*** josecastroleon has quit IRC13:57
*** raildo_ is now known as raildo13:59
lbragstado/14:01
*** _ix has quit IRC14:03
*** spotz has joined #openstack-keystone14:08
cmurphyhey y'all o/14:08
lbragstadhow was your vacation, cmurphy?14:12
cmurphyit was lovely ^.^14:12
cmurphywas trekking through norway14:13
lbragstad...14:13
* lbragstad is expecting a link to google photos14:13
cmurphyi'm still processing them :P14:13
lbragstadi'll be patient then14:13
cmurphy:)14:13
lbragstadi bet that was awesome14:14
lbragstadmy wife and i would like to get there in the next year or two... it's been on our list _forever_14:14
lbragstadboth our families migrated from norway, so we have all the more reason to go, too14:15
lbragstadi might have to ask you for a list of top 5 must-dos :)14:15
cmurphyoh neat14:15
cmurphydefinitely recommend :)14:15
lbragstadthis is probably gonna be a tough one to answer, but was it better than iceland?14:16
cmurphyhard to compare, i went in different seasons14:16
lbragstadahh14:16
cmurphysummer in norway is pretty fantastic but no chance of seeing northern lights14:17
lbragstadyou went to iceland in the spring, yeah?14:18
cmurphyyeah early spring, was a bit on the cloudy/rainy/cold side and some of the mountain roads were still closed, wouldn't have had as many hiking opportunities14:19
lbragstadthat makes sense14:19
*** Tahvok_ has joined #openstack-keystone14:23
*** Tahvok has quit IRC14:26
*** toddnni has quit IRC14:26
*** rledisez has quit IRC14:26
*** baffle has quit IRC14:26
*** redrobot has quit IRC14:26
*** szaher has quit IRC14:26
*** dtantsur|brb has quit IRC14:26
*** Tahvok_ is now known as Tahvok14:26
*** toddnni has joined #openstack-keystone14:27
*** dtantsur has joined #openstack-keystone14:28
*** redrobot has joined #openstack-keystone14:28
*** rledisez has joined #openstack-keystone14:29
gagehugoo/14:31
kmallocO/14:39
lbragstadkmalloc: qq14:40
kmallocwxy-xiyuan: yeah I mostly have the patch fixed, just working on the last bits.14:40
kmalloclbragstad: qa14:40
kmalloc;)14:40
kmallocOr, I have an answer, let's see if it matches your question.14:40
lbragstadwould you be opposed to a session at the PTG dedicated to a retrospective on your migration to flask?14:40
lbragstadthere is a ML thread on maintaining paste.deploy14:41
lbragstadbut it sounds like the long-term solution is to just move to something else14:41
*** _ix has joined #openstack-keystone14:42
lbragstadi figured the things we worked through might be useful for other projects14:42
*** wxy-xiyuan has quit IRC14:44
*** wxy-xiyuan has joined #openstack-keystone14:44
*** eglute has quit IRC14:45
kmallocNot at all14:46
kmallocI also owe a full write up for some other folks.14:46
kmallocOutside of keystone.14:46
kmallocPretty much, or convert to pure webob (like we did)14:48
kmallocBut flask, imo is way better14:49
kmallocWe could have dropped paste with out webob stuff. But it is a pretty serious diy approach still.14:49
*** eglute has joined #openstack-keystone14:49
kmallocFlask offers a lot of framework benefits, but it has to be done the flask way.14:49
kmallocPtg is in Denver again?14:51
lbragstadyeah14:51
*** gyee has joined #openstack-keystone14:52
lbragstadhttp://lists.openstack.org/pipermail/openstack-dev/2018-August/132910.html14:54
*** fiddletwix has joined #openstack-keystone14:55
*** dave-mccowan has joined #openstack-keystone14:56
*** Neptu_ is now known as Neptu14:59
*** pcaruana has quit IRC15:12
*** shyambiradar has joined #openstack-keystone15:16
*** raildo_ has joined #openstack-keystone15:17
*** raildo has quit IRC15:18
*** hoonetorg has quit IRC15:22
*** rledisez has quit IRC15:22
kmalloc++15:23
* kmalloc is a little sad.15:25
kmalloci'm going to have to remove RHEL and install fedora or ubuntu on the corp provided laptop to make it work.15:25
*** rledisez has joined #openstack-keystone15:25
kmallocso, can't do it the "way customers do it"15:25
*** shyam89 has joined #openstack-keystone15:31
openstackgerritMorgan Fainberg proposed openstack/keystone master: Convert limits and registered limits to flask dispatching  https://review.openstack.org/58808015:33
kmallocwxy-xiyuan, lbragstad: ^15:35
lbragstadsweet15:35
lbragstadi have a post-it on my monitor to review that today15:35
*** shyambiradar has quit IRC15:35
kmallocand now on to app-creds.15:35
kmalloci think i'm going to do policy last, if i can, so i can just delete @protected in one fell swoop and not need the weird @protected->policy_api_provider->driver->oslo_policy15:36
lbragstadyeah.. that's fine15:36
kmalloccurrent order: app_cred, groups, catalog [service/region/etc], endpoint-policy, domain, project, assignment [role/etc], user, auth, policy15:38
kmallocoh and os-federation is going to be somewhere in auth too.15:38
* kmalloc hates how slow this is going.15:38
kmallocits a LOT of api to cover.15:38
kmallocoh nvm, app-cred lives almost all in /users it looks like15:40
gagehugoyeah it's quite a bit15:40
*** jaosorior has quit IRC15:48
*** jaosorior has joined #openstack-keystone15:49
*** shyambiradar has joined #openstack-keystone15:51
*** Emine has quit IRC15:53
*** shyam89 has quit IRC15:55
*** dklyle has joined #openstack-keystone15:57
*** rledisez has quit IRC16:25
*** rledisez has joined #openstack-keystone16:26
*** shyambiradar has quit IRC16:26
*** shyambiradar has joined #openstack-keystone16:27
*** devx has joined #openstack-keystone16:30
*** SamYaple has joined #openstack-keystone16:39
* lbragstad goes to lunch16:47
*** evrardjp has quit IRC16:51
*** raildo has joined #openstack-keystone17:34
*** raildo_ has quit IRC17:35
*** shyambiradar has quit IRC17:36
*** evrardjp has joined #openstack-keystone17:41
openstackgerritLance Bragstad proposed openstack/keystone master: Add a release note for bug 1785164  https://review.openstack.org/58924117:44
openstackbug 1785164 in OpenStack Identity (keystone) "Identity API v3: POST method for "Create Limits" is abnormal for a domain-id" [Undecided,In progress] https://launchpad.net/bugs/1785164 - Assigned to wangxiyuan (wangxiyuan)17:44
kmallocwoo, almost have os-ep-filter migrated [so far the most complex one]17:45
kmalloci think next i need to fix the local "wrap collection/member" bits.17:45
*** dtantsur is now known as dtantsur|afk17:53
*** nicolasbock has quit IRC18:23
*** nicolasbock has joined #openstack-keystone18:24
kmallocknikolla: you on vacation?18:48
knikollakmalloc: no, today i'm back to work19:08
*** hoonetorg has joined #openstack-keystone19:16
kmallocknikolla: cool. need to start working on mixmatch stuff with you.19:20
kmallocknikolla: trying to crank out keystone flask stuff done too19:21
knikollakmalloc: cool!19:22
openstackgerritMorgan Fainberg proposed openstack/keystone master: Convert limits and registered limits to flask dispatching  https://review.openstack.org/58808019:38
_ixI had a quick question... I'm rounding out a Pike deployment in hopes of migrating to queens this week, but in this environment we've only had a single project/tenant. That has me wondering if the endpoints are in fact misconfigured, and I have deeper questions about keystone catalogs and interfaces.19:46
_ixAre the public, internal, and admin interfaces still meaningful?19:46
_ixDo I need to embed %(project_id)s in any of my endpoints? And if so, which ones?19:48
lbragstad_ix: that should have been a v2.0-ism that was specific to keystone's v2.0 API, or older APIs within openstack19:48
lbragstadmost services should be using request contexts to pull project information19:49
_ixlbragstad: Which aspect is from the v2.0 side of things? Does that also apply to the internal/admin/public interfaces?19:49
lbragstadsome of this pre-dates my involvement with openstack, but afaik embedding project IDs into endpoint URL was a separate thing from the interface types19:50
knikollait depends on the service. cinder requires project_id in the endpoint AFAIK19:51
knikollaglance, nova, neutron, etc, don't.19:51
lbragstadputting the project ID in the url of the endpoint is for relaying project information to the service19:51
_ixAlso, we've unified keystone across two regions now (thanks for your help last week!), but regionone is running on Frankenstein's OpenStack deployment of juno/kilo/liberty/mitaka.19:51
lbragstadknikolla: i wonder if there is a bug open for that within cinder, i wouldn't mind getting that fixed19:52
_ixknikolla: Any conjecture on the swift endpoints? Do they require project id embedded?19:52
_ixlbragstad: To my point above about ancient versions of openstack, especially nova, I don't think Juno-era nova has any idea what keystone v3 is, and we at first tried to unify the two regions under Queens-era Keystone. Was v2.0 killed by any measure in Queens?19:54
knikolla_ix: swift, i don't think so19:54
lbragstadyeah - v2.0 was removed in queens19:54
lbragstadwe had a v3 only gate job running tempest with the rest of the services for a few releases before making that change19:55
lbragstadand removing v2.019:55
lbragstadso nova should be compatible with keystone prior to Queens (Pike or Ocata)19:55
_ixlbragstad: Oh, dear. I thought we had read that it wasn't scheduled for removal until R S or T releases, but that's good information.19:55
knikollalbragstad: was the v2.0 auth part removed in queens also?19:56
_ixIs there anything that the other services would expect keystone to do that our six-node Pike cluster may not be able to handle? That is, can we move to Queens/Rocky and keep Keystone Pike?19:57
lbragstadknikolla: the auth bits were removed in queens19:58
lbragstadknikolla: the only thing we removed in rocky was the ec2 stuff https://review.openstack.org/#/c/572846/19:59
knikollaright19:59
lbragstadspecifically for v2.0 which shouldn't matter too much since we have a v3 api for it19:59
lbragstadbut the standard v2.0 auth paths were removed in queens19:59
knikollai can't think of anything off the top of my head that would prevent a pike keystone to work with up to rocky deployments.20:04
lbragstadme either20:04
knikollasituation will probably be different in stein with system scope and unified limits20:05
lbragstad++ once services start incorporating that working into their APIs20:06
_ixThanks very much! To the interface question... is there still a need for all three public, internal, and admin?20:06
lbragstadthey will need a Queens version of keystone at least20:06
knikollalbragstad: when were service tokens + allow_expired implemented?20:06
knikollai think it was pike20:06
lbragstadocata - http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/allow-expired.html20:07
lbragstad_ix: the interfaces you define depend on your deployment20:07
lbragstadadmin doesn't really make much sense anymore without v2.0 though20:07
lbragstadpublic and internal might though - depending on how you have vips setup i suppose20:08
_ixSo, keystone is listening on 5000 and 35357. Are there any substantive differences between accessing keystone v3 on those ports?20:08
lbragstadaccessing v3 on either of those ports should result in nearly identical responses20:08
lbragstadaccessing v2.0 on either of those ports will have a bunch different outcome20:09
lbragstadall administrator like functionality was encapsulated into a specific endpoint, e.g. 3535720:09
lbragstadwith v2.0 that is ^20:09
_ixOK. So, will subsequent keystone releases only listen on 5000 or 35357?20:10
lbragstadwhen we wrote v3, we incorporated RBAC into the application itself, so there shouldn't be a need to host two separate applications for two separate sets of users20:10
openstackgerritMorgan Fainberg proposed openstack/keystone master: Migrate OS-EP-FILTER to flask native dispatching  https://review.openstack.org/58927420:10
lbragstad_ix: that's totally up to the deployer20:10
_ixAh.20:10
lbragstadyou can tell keystone to listen on port 80, or 44320:10
lbragstadit's all configurable20:11
kmalloc_ix: it is recommended to use port 443.20:11
kmallocbut we don't require that.20:11
lbragstad+120:11
kmalloc443, and TLS*20:11
lbragstadthe important difference is that keystone doesn't require two different applications to be hosted on different ports to expose all functionality to end users20:11
kmalloc++20:11
lbragstadit simplifies deployment20:12
kmalloclbragstad: ^ OS-EP-FILTER paths to flask.20:12
kmalloclbragstad: i think i figured out a way (with no real change) to migrate /users, etc in stages.20:12
lbragstad_ix: some of what is here should help explain things https://docs.openstack.org/keystone/latest/contributor/http-api.html20:12
_ixkmalloc: I think we terminate ssl at haproxy, and just do port 80.20:12
kmalloc_ix: sure. that's fair.20:12
_ixCool. Thanks for the support, folks.20:14
lbragstadyep - let us know if you have any more questions20:15
lbragstadhopefully it helped20:15
_ixIt's taken nearly a year to prioritize and get to this point. We're so close!20:15
lbragstadhome stretch!20:15
_ixPike's almost a year old, so that makes sense.20:15
kmalloclbragstad: this migration to flask is sloooooow20:16
kmalloc=/20:16
lbragstadwhile removing v2.0 is both a pain for operators and deployers, it should really open up possibilities for us in S and T20:16
lbragstadkmalloc: would it help if i jumped in and ported an API or two?20:17
_ixHuh. That'd be neat if we had a distinction between operators and deployments where I'm at.20:17
_ixs/deployments/deployers20:17
lbragstad_ix: sorry - s/deployers/developers/20:17
_ixOh, yeah. I suppose so.20:17
_ixThanks for all of your contributions to keystone. It's one of the easier services to get up and moving. One day, I hope to contribute myself.20:18
lbragstad_ix: happy to have you chip in anytime, if you have specific questions about how you can contribute just ping me (or anyone else here for that matter)20:19
lbragstadwe're a pretty easy-going group ;)20:19
_ixOh, I'd love to. But, I think there are probably other openstack services that are clamoring for developer support. Looks like this project is in good shape!20:20
lbragstadwe have a pretty heavy focus on cross-project initiatives as of late, so i can definitely see that the more i get involved with other services20:22
_ixI haven't looked to closely, but you're probably more adept at looking through the bug tracker than me... I ran into this issue that I thought was a keystone problem, but as it turns out, the openstack-nova-metadata-api service isn't geting it's keystone_url from the nova.conf group I had expected. I think it's coming from either [placement]/keystone_url or [neutron]/keystone_url... I wasn't very20:27
_ixscientific about it, and I changed both. Everything else seems to be able to hit the base <keystone_url> and figure it out, but the nova-metadata-api service kept bombing out trying to find <keystone_url>/auth/tokens instead of <keystone_url>/v3/auth/tokens. Bummer.20:27
_ixs/geting it's/getting its20:27
lbragstadi'm not entirely familiar with the openstack-nova-metadata-api20:28
lbragstaddoes it have it's own config file?20:29
_ixIt does not. It's informted by nova.conf.20:29
lbragstadhmm - and other nova services don't have the same issue?20:29
_ixDidn't seem so. Seemed like the other services were able to get the service discovery queues from keystone and move along.20:30
_ixUnfortunately, I've got to detach to take my son to urgent care, but we'll be in touch! Thanks again!20:30
lbragstadyou could verify the auth_uri in [keystone_authtokne]20:30
lbragstadno problem!20:31
kmalloclbragstad: i'd be happy if you want to jump in20:31
lbragstaddo you have one in particular you'd like me to take?20:31
* lbragstad hopes for an easier one20:31
kmalloclbragstad: chances are, will cause conflicts, but... if you want to port policies [note endpoint-policy has some stuff in there that need to be ported too]20:32
kmalloclbragstad: policies is prob. the easiest one left20:33
kmallocOS-FEDERATION is going to be a beast, catalog is easy, but needs work to fix .wrap_member/collection20:33
lbragstadok20:34
lbragstadlemme finish up some stuff and i'll start digging into that one20:34
lbragstadpolicy that is20:34
kmalloclbragstad: give me a few for the next one, base your work on OS-SIMPLE-CERT one i am about to post20:36
kmallocshould help limit conflicts so we can do parallel api porting20:36
openstackgerritMorgan Fainberg proposed openstack/keystone master: Convert OS-SIMPLE-CERT to flask dispatching  https://review.openstack.org/58928220:40
kmalloclbragstad: if you want a hard one instead... /groups is medium difficulty, as is /domains. /projects, /roles, /users, and auth are very hard20:42
lbragstadok - let me try and get my feet wet with policies20:42
kmalloci'm going to try and fix the wrap_member and wrap_collection bits.20:43
openstackgerritMerged openstack/keystone master: Do not allow create limits for domain  https://review.openstack.org/58846020:46
cmurphylbragstad: https://photos.app.goo.gl/KFowxRC47HHcPZxQ820:48
lbragstadwow...20:50
lbragstaddespite the pictures being awesome, i bet it's incredible in person20:50
cmurphyyeah the pictures don't really capture it20:53
lbragstadstanding next to some of those fjords would give me weak knees20:54
lbragstadthat's a long. way. down20:54
cmurphyya for real20:55
lbragstadwhat cities did you go to?20:55
lbragstadit goes from crazy historic to super modern it looks like20:56
cmurphythe cities in the pictures are Bergen, Flåm and Oslo20:56
lbragstadsweet20:57
*** raildo has quit IRC21:02
openstackgerritMorgan Fainberg proposed openstack/keystone master: Convert OS-SIMPLE-CERT to flask dispatching  https://review.openstack.org/58928221:15
*** edmondsw has quit IRC21:15
openstackgerritMorgan Fainberg proposed openstack/keystone master: Allow wrap_member and wrap_collection to specify target  https://review.openstack.org/58928821:19
*** harlowja has joined #openstack-keystone21:21
gagehugolbragstad: https://review.openstack.org/#/c/529945/ is close imo21:43
gagehugoalso https://review.openstack.org/#/c/526476/21:44
lbragstadvery nice21:46
lbragstadi can take a peak at those21:46
*** rcernin has joined #openstack-keystone22:15
*** nicolasbock has quit IRC22:25
*** mvkr has joined #openstack-keystone22:45
kmallocugh. this is really awful.22:56
kmallocfixing the path in wrap collection22:56
kmalloccan i say the whole links thing is so pointless22:56
kmalloci wish we could just make links disappear22:57
kmallocit's useless22:57
kmalloclbragstad: =/22:57
kmalloci can solve this just going to be a lot more work.22:57
gagehugo"i wish we could just make links disappear"23:13
gagehugo++23:13
« Sunday, 2018-08-05 Index Tuesday, 2018-08-07 »

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!