Wednesday, 2019-03-27

*** dolphm has quit IRC00:16
*** dustinc has quit IRC00:25
*** jamesmcarthur has joined #openstack-keystone00:49
*** markvoelker has joined #openstack-keystone00:51
*** ileixe has joined #openstack-keystone00:54
*** ileixe has quit IRC00:54
*** ileixe has joined #openstack-keystone00:55
*** awalende has joined #openstack-keystone01:02
*** markvoelker has quit IRC01:03
*** awalende has quit IRC01:07
*** markvoelker has joined #openstack-keystone01:18
*** erus has quit IRC01:23
*** erus has joined #openstack-keystone01:23
*** rcernin has quit IRC01:49
*** rcernin has joined #openstack-keystone01:53
*** whoami-rajat has joined #openstack-keystone02:08
*** erus has quit IRC02:08
openstackgerritMerged openstack/keystone master: Add keystone's technical vision reflection  https://review.openstack.org/64137402:08
*** erus has joined #openstack-keystone02:09
*** mgagne has quit IRC02:15
*** mgagne has joined #openstack-keystone02:15
*** charz has quit IRC02:16
*** jamesmcarthur has quit IRC02:52
*** jamesmcarthur has joined #openstack-keystone03:36
*** jamesmcarthur has quit IRC03:44
*** jamesmcarthur has joined #openstack-keystone03:45
*** jamesmcarthur has quit IRC03:47
*** jamesmcarthur has joined #openstack-keystone03:47
*** jamesmcarthur has quit IRC03:52
*** jamesmcarthur has joined #openstack-keystone04:00
*** jamesmcarthur has quit IRC04:01
*** vishakha has joined #openstack-keystone04:09
*** ileixe has quit IRC04:11
openstackgerritVishakha Agarwal proposed openstack/keystone master: WIP: implement domain reader support for grants  https://review.openstack.org/64596804:44
*** shyam89 has joined #openstack-keystone04:58
*** shyam89 has quit IRC05:03
*** ileixe has joined #openstack-keystone05:08
openstackgerritVishakha Agarwal proposed openstack/keystone master: WIP : Make domain admin policies consistent for grants  https://review.openstack.org/64799905:10
*** shyam89 has joined #openstack-keystone05:15
*** lbragstad has joined #openstack-keystone05:25
*** ChanServ sets mode: +o lbragstad05:25
*** lbragstad has quit IRC05:41
*** markvoelker has quit IRC06:00
*** jaosorior has quit IRC06:26
*** jaosorior has joined #openstack-keystone06:28
*** markvoelker has joined #openstack-keystone06:31
*** jistr is now known as jistr|doc06:33
vishakhalbragstad: For grants API will the project ( admin or member or reader) will be able to list the grants or the behaviour weill be same as role assignments?06:37
*** erus has quit IRC06:43
*** erus has joined #openstack-keystone06:43
*** shyam89 has quit IRC07:00
*** shyam89 has joined #openstack-keystone07:04
*** shyam89 has quit IRC07:31
*** shyam89 has joined #openstack-keystone07:48
tonybcmurphy: Are you around?07:55
cmurphytonyb: need 5 minutes sorry07:56
tonybcmurphy: It's cool I'll wait07:56
cmurphytonyb: here now, sorry about that - my laptop decided right at the beginning of the meeting that that was a good time to explode spectacularly08:04
cmurphyso now i'm at the office08:04
tonybcmurphy: litterally explode?08:05
cmurphyno figuratively08:05
tonyb'cause that'd be very cool08:05
tonybpffft08:05
cmurphyit would be quite messy08:05
tonybTrue08:05
tonybSo rocky08:05
tonybWe're kinda a little stuck08:05
cmurphyright08:05
tonybcan we confirm / test that py2 with 2.1.0 is okay? or do we knwo that's broken also08:06
cmurphyldappool 2.1.0? or you mean 2.0.0 https://review.openstack.org/#/c/613648/4/lower-constraints.txt08:07
tonybcmurphy: 2.0.0 would be better but CentOS has 2.1.0 so that'd do08:08
cmurphyi think python2 works fine with 2.0.0 or 2.1.008:09
evrardjpo/08:10
cmurphywhat's your suggestion? to revert because python2 is okay? it's broken for non-rhel on python3 so that wouldn't make me happy08:10
tonyband the reason for the bump is because py3 needed extra 'handling'08:10
tonybcmurphy: If we can be certain that py2+ldappool(2.0.0 -> 2.3.1) is ok then I'll approve it and ask y'all not to do that thing again08:11
tonyb... at least without discussin alternatives with the stable team first08:12
cmurphyokay, we did have smcginnis approve that change so i thought it was okay08:12
cmurphypy2 should be unaffected by this change08:13
cmurphywill be more aware next time08:13
*** awalende has joined #openstack-keystone08:16
*** tkajinam has quit IRC08:16
*** shyam89 has quit IRC08:16
tonybOkay so if you're good to stand by 'py2 is okay with <2.3.1' I'll approve the release tomorrow08:18
cmurphylet me do a quick unit test run with the constraint lowered just to be extra sure08:19
tonybcmurphy: cool08:19
* tonyb needs to get the kids to bed08:19
tonybcmurphy: let me know how you go08:19
cmurphyo708:20
tonyb:)08:20
evrardjpI will vote based on your results cmurphy08:27
*** pcaruana has joined #openstack-keystone08:57
*** shyam89 has joined #openstack-keystone09:12
*** jistr|doc is now known as jistr09:15
*** shyam89 has quit IRC10:08
*** shyam89 has joined #openstack-keystone10:21
ildikovcmurphy: hi10:23
*** mvkr has joined #openstack-keystone10:51
*** rcernin has quit IRC10:51
*** shyam89 has quit IRC10:53
cmurphyhi ildikov10:57
cmurphywhat's up?10:57
*** erus has quit IRC11:18
*** erus has joined #openstack-keystone11:18
*** shyam89 has joined #openstack-keystone11:28
*** zlangi has joined #openstack-keystone11:48
*** erus has quit IRC11:48
zlangihello everyone, is ther anyone who got some experience with keystone integration with AD? I can't get the groups working. in the corp AD, the cn for the users is the full name of the users, I got to use sAMAccountName for the username. that would be ok, but! the group membership is returned by cname as well. basically when I query the group membership, that comes back like this: CN=Doe John,OU=MyGroups,OU=Somewhere,OU=com11:48
zlangiis there anyone here had similar problem? if yes, how did you solve it?11:49
*** erus has joined #openstack-keystone11:49
*** markvoelker has quit IRC12:21
*** mchlumsky has joined #openstack-keystone12:22
*** jamesmcarthur has joined #openstack-keystone12:23
*** jamesmcarthur has quit IRC12:32
*** erus has quit IRC12:32
*** erus has joined #openstack-keystone12:33
*** shyam89 has quit IRC12:34
*** mvkr has quit IRC12:37
*** pcaruana has quit IRC12:39
*** erus has quit IRC12:39
*** erus has joined #openstack-keystone12:40
*** pcaruana has joined #openstack-keystone12:42
*** pcaruana has quit IRC12:42
*** pcaruana has joined #openstack-keystone12:43
*** shyam89 has joined #openstack-keystone12:46
*** lbragstad has joined #openstack-keystone12:46
*** ChanServ sets mode: +o lbragstad12:46
*** jamesmcarthur has joined #openstack-keystone12:51
*** jamesmcarthur has quit IRC12:52
*** jamesmcarthur has joined #openstack-keystone12:52
ildikovcmurphy: I wanted to ask you about the hacking days we're organizing with the edge group12:55
ildikovcmurphy: one of the potential tasks to do is setting up an environment with Keystone so that we can do testing and with csatari we're somewhat available the week before the Summit to give it the first try12:56
ildikovcmurphy: so I wanted to check if you're around that much to dial in if we get brutally stuck to ask a few questions12:56
cmurphyildikov: what are the dates again?12:56
*** itlinux has quit IRC12:57
ildikovcmurphy: tracking it in this poll: https://doodle.com/poll/m7ar8m8zp3izw7t512:57
ildikovcmurphy: so potentially something between April 17 and 2412:58
cmurphyildikov: what would the time zone be?12:59
ildikovcmurphy: the idea is to run it all day so people can join when they're available13:01
cmurphyildikov: okay i'd be happy to dial in13:02
ildikovcmurphy: I know one or two students in Sweden who would be interested in joining and csatari and I, we're in Hungary so it's all Central European Time, that's why I thought to reach out to you about the environment building idea as we would prolly test the plugin that just got merged and do something for federation testing13:02
cmurphyildikov: so i will actually be in west coast time that week13:03
ildikovcmurphy: ah, I see13:03
ildikovcmurphy: seemed a bit too good to be true :)13:04
*** ileixe has quit IRC13:04
ildikovcmurphy: if you're around in the morning then we could do a little sync up in case we got somewhere or the opposite and we would need help?13:04
cmurphyildikov: sure13:07
cmurphyildikov: do you have an agenda or brainstorming etherpad or something?13:07
cmurphymaybe i could make some notes and pointers13:07
ildikovcmurphy: just an overall brainstorming etherpad: https://etherpad.openstack.org/p/osf-edge-hacking-days13:07
ildikovthere are Keystone related items there, so please drop in any info you think would be useful13:08
ildikovthank you!!13:08
cmurphyno problem, I'll try to add some context and notes in there13:08
ildikovsounds great, thanks again!13:08
*** jhesketh has quit IRC13:10
*** mvkr has joined #openstack-keystone13:12
*** erus has quit IRC13:12
csataricmurphy: there are legends, that you know how to easily reproduce one of the x.509 bugs. Can you add to the etherpad which bug is it and probably some description how to reproduce it?13:13
*** erus has joined #openstack-keystone13:13
cmurphycsatari: sure13:13
csataricmurphy: thanks13:15
*** shyam89 has quit IRC13:27
*** shyam89 has joined #openstack-keystone13:27
*** jamesmcarthur has quit IRC13:28
knikollao/13:31
*** shyam89 has quit IRC13:31
lbragstad\o13:31
vishakhao/13:33
cmurphy~o~13:33
vishakha lbragstad: For grants API will the project ( admin or member or reader) will be able to list the grants or the behaviour weill be same as role assignments?13:33
*** shyam89 has joined #openstack-keystone13:33
lbragstadvishakha i don't think so13:34
lbragstadactually...13:34
lbragstadi think it's going to be complicated :)13:35
lbragstadsystem users should be able to perform any of the grants APIs across any projects or domains13:36
lbragstador the deployment system itself13:36
lbragstaddomain users should be able to access grants for any projects within the domain they're operating on13:36
lbragstad^ those are the two easier cases13:37
lbragstadbut since keystone supports hierarchical multitenancy - you could also support the ability for project users to have access to grants for all sub-projects in the tree underneath them13:37
*** erus has quit IRC13:37
*** erus has joined #openstack-keystone13:38
lbragstadbut - that is going to be complicated13:39
lbragstadbecause in order to use the grant API effectively, you need to know the ID of the user in the grant13:39
lbragstadand users are resources that are owned by domains, which we don't expose to project users at all13:40
lbragstad(e.g., a project user can't call GET /v3/users?domain.id=domainA to get a list of all users within domainA and add them to a project they're admin on)13:41
*** jamesmcarthur has joined #openstack-keystone13:44
efriedHi keystoners. Is this correct? https://review.openstack.org/#/c/647972/13:46
lbragstadyeah - i think so13:48
lbragstadDefault is the domain ID and `default` is the ID =/13:48
lbragstader... Default is the domain *name*13:48
lbragstaddefault is the ID13:49
efriedThanks lbragstad. Where are these opts defined?13:50
lbragstadonly the default domain ID is configurable13:51
lbragstadhttps://docs.openstack.org/keystone/latest/configuration/config-options.html#identity.default_domain_id13:51
lbragstadit's default is... default13:51
lbragstadi don't know if you can tell, but we're awesome at naming things...13:51
efriedThis is going to reveal how ignorant I am, but...13:54
efriedhow/where does a project (like nova) register the keystone_authtoken opt group?13:55
eruso/13:55
efriedThat's the thing it uses to be a "service", right?13:56
efriedSo other pieces can connect to it via e.g. ksa or sdk13:57
lbragstadcorrect13:57
lbragstadthose options are maintained in keystoneauth13:57
lbragstadso you expose/register them like you would any other library you're consuming (think oslo.policy or oslo.messaging)13:58
efriedso somewhere in my project's conf/ directory I'm looking for a file that imports something from keystoneauth1 and does a register_keystone_authtoken_opts or similar?13:58
lbragstadi believe so13:58
* lbragstad grabs a copy of nova13:58
efriedthe stuff in keystoneauth1.loading is for the *client* side afaict.13:59
lbragstadhttps://pasted.tech/pastes/ff598f826816b024f4b2cc257c7b8ff14e55e8f6.raw14:00
*** erus has quit IRC14:00
lbragstadnova/conf/utils.py?14:00
efriedyeah, aren't all of those for when nova wants to be the client? I.e. when nova asks the cinder API for things, or the neutron API, etc.14:01
*** erus has joined #openstack-keystone14:01
efriedI know for sure the stuff in conf/utils is that14:01
efriedcause I wrote it14:01
*** admin0 has left #openstack-keystone14:01
* efried <== reasonable amount of experience with the client side14:01
* efried <== zero experience with the server/service side14:02
*** jamesmcarthur_ has joined #openstack-keystone14:02
lbragstadah14:02
lbragstadsorry - i thought that is what you were asking about?14:03
efriedsorry if I'm blithering, I'm fuzzy this morning.14:03
lbragstadi guess i'm not sure what you mean by "That's the thing it uses to be a service"14:04
efriedThere's two sides to keystone: the service (API) and the client that connects to it.14:04
efriedsorry, I shouldn't have said "to keystone" probably14:04
efriedThe latter, the client side, is what ksa is for. I'm familiar with that. I can construct an Adapter which allows me, the client, to talk to a service that's listening on the other end at a nicely formed endpoint.14:05
lbragstadsure14:05
*** jamesmcarthur has quit IRC14:05
efriedSo what I'm asking is, how does the other end get to be there and listen for that Adapter to come knocking?14:05
efriedI thought it was by setting itself up with... something keystoney, which includes exposing conf options in the keystone_authtoken group14:05
efried...so if my service has username/password foo/bar in keystone_athtoken, then my *client* would construct an Adapter by passing in username/password foo/bar as authentication creds14:06
efriedam I just waay off?14:06
efriedI'm sure there's a lovely doc that explains this. I would call it "How to set up my service to use Keystone". But I suck at naming things.14:07
lbragstadno - the last part sounds accurate because you build a ksa object that you can re-use across clients, right?14:07
efriedre-use across clients... not sure about that bit. I just know I create a ksa adapter by loading the conf options whose defs I registered via those ksa/loading modules14:08
*** erus has quit IRC14:08
efriedso yeah, I guess multiple clients using the same conf file could all access the same service the same way.14:09
*** erus has joined #openstack-keystone14:09
lbragstador you could build multiple clients from the same ksa adapter?14:10
efriedyou're talking client like an instance, I thought you meant a client like a process.14:10
*** adriant has quit IRC14:10
efried(python instance of a class, not instance in the nova sense)14:11
efriedanyway, so I know how my client code registers those client-side conf options - they come out of ksa/loading14:11
*** adriant has joined #openstack-keystone14:11
*** shyam89 has quit IRC14:12
efriedWhat I'm trying to get at is, how does the service come up knowing that those values are the right ones and it should allow the traffic?14:12
efriedAnd I thought the admin set this ^ up by filling in the [keystone_authtoken] section of the *service's* conf file.14:12
lbragstadyeah - sorry, i was referring to python objects14:12
lbragstadiiuc, it's completely up to operators to set that up correctly14:13
lbragstadthe service assumes that the auth token values are correct and available (e.g., an identity API is on the other end of the wire)14:13
efriedRight, it's up to the operator to set up the service with the correct values - in the [keystone_authtoken] section of the service's conf, right?14:15
lbragstadand the connection information (username and password) are correct and correspond to a user account created in keystone14:15
lbragstadyes14:15
efriedcool - so: how/where does the service (the code itself) register that conf group and those options?14:16
efriedlooks like it may come from keystonemiddleware....14:23
lbragstadyeah14:23
lbragstadsorry - i was just looking at https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n6614:24
efriedyeah - those are the client side options14:24
lbragstadhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/_opts.py#n20214:24
lbragstadhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/_base.py#n1314:26
efriedSo my service implicitly registers the opts by somehow importing auth_token/_opts.py, which must happen through some other (public) import chain14:26
*** itlinux has joined #openstack-keystone14:27
lbragstadwell - nova runs keystonemiddleware in front of the service14:27
lbragstadhttp://git.openstack.org/cgit/openstack/nova/tree/etc/nova/api-paste.ini#n8314:27
efriedvia some paste-ini magic... yeha14:28
efriedand that, somewhere under the covers, imports keystonemiddleware.auth_token, which imports _opts, which registers the conf options.14:28
efriedgadzooks14:28
lbragstadcorrect - http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/api-paste.ini#n32 is defined in the pipeline14:28
* efried doesn't know what a pipeline is14:29
efriedbut that's okay.14:29
efriedat some point here there will probably be several groups wanting to set up their fringe projects to use keystone14:29
lbragstadspecifically - http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n95514:30
efriedso they'll need to know how to do this magic.14:30
lbragstada paste pipeline is way to say what the order of request processing should be14:30
lbragstadso, looking at http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/api-paste.ini#n3214:31
efriedThe only thing I know about paste is that I used to have to like uninstall and reinstall it in different ways (apt/pip) at various versions to get my devstack working.14:31
lbragstada request object hits cors first, then http_proxy_to_wsgi14:31
lbragstadetc...14:31
lbragstadso when you setup a pipeline you have the ability to specify the order of software that gets run14:32
lbragstadthe contract uses generic request objects and an interface between middleware so you can string them together14:32
lbragstadthe same pattern happens on the way out for response objects14:32
efriedOkay.14:33
lbragstadfor example; each piece in the pipeline has a process_request() method14:33
lbragstadso, this is what's actually getting run each time someone calls the nova API http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n59814:33
lbragstadwhich is what's responsible for validating the users token and setting headers that nova pulls off (in the next piece of middleware) to build request context objects using oslo.context14:34
lbragstadall that happens before the request actually hits the nova API14:35
lbragstadbecause that's defined last in the pipeline (osapi_compute_app_v21)14:35
efriedSo reminding myself what I was looking for when I started down this path...14:36
efriedI then expected to find project_domain_name and user_domain_name defined in keystonemiddleware.auth_token._opts14:36
efriedbut they aren't there14:37
*** erus has quit IRC14:40
*** erus has joined #openstack-keystone14:40
efriedor anywhere in those three projects (keystone, keystoneauth, keystonemiddleware)14:41
lbragstadlooking14:45
efriedI'm going to go with +2 because it matches the example in the ksm documentation14:45
lbragstadthey're loaded dynamically14:49
lbragstadmiddleware invokes http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n261 right?14:49
lbragstadand we get into ksa here - http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n25714:49
lbragstadwhich calls this - https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n3014:50
lbragstadhttps://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n3714:51
vishakhalbragstad: ohh ok. Let me come back to you for any doubts on project for grant api14:51
*** erus has quit IRC14:53
*** erus has joined #openstack-keystone14:54
lbragstadefried keystoneauth can't have dependencies on oslo, which is why you're not seeing the options defined and registered like you normally work14:58
lbragstadwould*14:58
lbragstadi didn't remember that earlier - i was looking for definitions with oslo.config, too14:59
efriedbut where are user_domain_name and project_domain_name defined?14:59
efriedit's okay, you don't have to kill yourself explaining this to me, at this point it's just stubborn intellectual curiosity, but I can let it go.15:00
lbragstadhttps://review.openstack.org/#/c/647972/1/doc/source/install/compute-install-obs.rst@7915:00
lbragstad^ right there15:00
lbragstadyou see auth_type = plugin?15:00
lbragstader - auth_type = password?15:01
efriedyes15:01
efriedYeah, I found where auth_type came from15:01
* efried wonders if project_domain_name and user_domain_name are actually obsolete/unused and nobody noticed15:02
*** erus has quit IRC15:02
efriedcause I only see them loaded from conf in tests15:02
*** erus has joined #openstack-keystone15:02
lbragstadwell - it'll load the password auth plugin15:03
lbragstadand it resolves the attributes of that plugin as configuration options https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/identity/v3/password.py15:04
efriedokay. I still don't see how that guy is loading anything from the conf. But seriously, we can stop beating this horse.15:08
lbragstadhopefully it at least cleared some things up15:10
lbragstadsorry it took me a while to grok this15:10
*** awalende has quit IRC15:11
*** erus has quit IRC15:11
*** erus has joined #openstack-keystone15:12
*** awalende has joined #openstack-keystone15:12
bnemeclbragstad: Hmm, is that why the config validator doesn't find things like keystone_authtoken/password?15:12
lbragstadbnemec probably15:13
lbragstadksa has isn't own Opt object15:14
lbragstadits own*15:14
bnemecOkay, and there's probably no way for those opts to show up in the sample config data?15:14
* bnemec has been trying to clean up false failures in the config validator15:15
bnemecSo this is relevant to my interests. :-)15:15
*** awalende has quit IRC15:16
lbragstadi'm not sure what you mean by show up in the sample config data?15:19
lbragstadin this specific case, ksm loads the opts for ksa by calling https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n3015:21
lbragstadwhich eventually(?) resolves auth_type to a plugin instance and populates the rest of the configuration opts based on the attributes of the plugin15:22
lbragstadwhich is where we get user_domain_name and project_domain_name15:23
lbragstadhttps://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/identity/v3/base.py#n4715:24
*** erus has quit IRC15:24
*** adriant has quit IRC15:25
*** erus has joined #openstack-keystone15:25
*** adriant has joined #openstack-keystone15:26
efriedbnemec: ah, good point, keystonemiddleware.auth_token._opts is registering opts, and the genconfig conf.py for $project is calling out keystonemiddleware.auth_token so we include the opts in the documentation, and these mysterious options are showing up there. I just (still) can't figure out where they're registered.15:29
lbragstad^ that code is eluding me, too15:29
lbragstadi see the doc string that describes the behavior15:30
lbragstadand i assume it works, because how else would it?15:30
lbragstadbut... where is the thing that grabs an instance of the plugin and iterates its attributes to register them as options?15:31
lbragstadcc kmalloc ^15:31
*** erus has quit IRC15:32
*** erus has joined #openstack-keystone15:33
bnemecMy concern is that when I run tox -e genconfig in a project, the resulting keystone_authtoken section doesn't have a password option (or any of the other options from that plugin).15:33
bnemecIt sounds like that's because the options are generated dynamically at runtime?15:33
kmallocPossibly at runtime. Also because you can use different plugins.15:34
lbragstadright...15:34
bnemecI'm wondering if there's any way to include those options in the sample config or if I just need to disable validation of the keystone_authtoken opt group because there's no way to know which options are valid ahead of time.15:34
kmallocBut can't use more than one at a time.15:34
lbragstadi just can't find that code15:34
kmallocI'd disable validatiob15:35
kmallocYou need to know the plugin to know opts.15:35
bnemeckmalloc: Okay, thanks. That's simple enough.15:36
lbragstadright - where were is the code that resolves the auth_type value to register its opts?15:36
bnemecMaybe I can dump out an info level message when we ignore a keystone_authtoken opt.15:36
kmalloclbragstad: in ksa I think15:36
lbragstadksm calls https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n3015:37
lbragstadbut idk how that resolves things?15:37
kmallocMagic15:37
lbragstadoutside of the docstring saying it does15:37
kmallocKsa doesn't create oslo opts15:38
kmallocIt converts on demand to them15:38
*** zlangi has quit IRC15:38
kmallocSo, it does some work behind the scenes.15:38
lbragstadright - i assume that's what in keystoneauth1/loading/_opts.py15:38
kmallocYeah, but you see in config the .to_oslo opt, you load the plugin and then get the opts cast from.obj15:39
kmallocReally, this is KSA magic.15:40
kmallocthis is opaque also because ksm did weird things to begin with and we carry a lot of legacy15:41
kmallocand on top of it all, ksa can't lean directly on oslo_config.15:41
lbragstadyeah - i remember that part15:41
kmallochonestly, i dislike oslo_config massively, it, imo, does not meaninfully add anything to config parsing15:42
kmallocoutside of the fixtures, and that could have been done independantly15:42
kmallocbut that aside15:43
kmallocthis really is related to oslo_config not being something ksa directly imports.15:43
lbragstadomg...15:45
lbragstadhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n86315:46
*** erus has quit IRC15:46
lbragstadhttp://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n88415:46
*** erus has joined #openstack-keystone15:47
lbragstadwhich calls - https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/conf.py#n4515:48
kmallocyep15:48
* lbragstad checks to see if it's 1700 yet15:48
lbragstadthere's your answer efried ^15:48
kmallocit's 1700 *somewhere*15:48
bnemecSomewhere, I'm sure. ;-)15:48
lbragstadmy brain hurts15:48
kmalloclbragstad:  1550 UTC, so ... 70 more minutes.15:49
efriedlbragstad: https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loading/_plugins/identity/generic.py#n69 ffs, it's because it was spelled with hyphens I never found it.15:54
* lbragstad pours efried a guinness15:54
efriedthanks, I needed that.15:55
lbragstadi think we reached the last layer of the onion though15:55
efried(it's not quite 1100 here)15:55
efriedlbragstad: Back to the original point, I don't see a default value in that opt :P15:56
efriedso it is still unclear whether that doc edit patch is right15:56
efriedbut I'm standing by my decision15:56
efriedto match the ksm documentation15:56
lbragstadi don't think they have can default values for user_domain_name and project_domain_name?15:57
lbragstadbut yeah - i agree that matching the ksm reference is a good idea15:58
cmurphyit's 1700 here :P16:00
*** KeithMnemonic has quit IRC16:01
cmurphyksm/ksa don't set a default value for the domain name or id, those come from the keystone database, that's why they need to be spelled out explicitly in the config16:01
* cmurphy partially paying attention16:02
*** efried is now known as efried_rollin16:02
lbragstadyeah - i was going to say, in the best case you'd be *assuming* a user has authorization on something in order for it to work16:04
* bnemec is jealous of cmurphy's time zone16:07
*** gyee has joined #openstack-keystone16:17
openstackgerritColleen Murphy proposed openstack/keystone master: Add domain scope support for group policies  https://review.openstack.org/64393716:22
openstackgerritColleen Murphy proposed openstack/keystone master: Remove redundant policies from v3cloudsample  https://review.openstack.org/64758616:22
*** shyamb has joined #openstack-keystone16:30
*** jamesmcarthur_ has quit IRC16:42
openstackgerritColleen Murphy proposed openstack/keystone master: Remove redundant policies from v3cloudsample  https://review.openstack.org/64758616:48
*** erus has quit IRC16:48
*** erus has joined #openstack-keystone16:48
*** dustinc has joined #openstack-keystone16:52
cmurphyheads up, if you haven't filled out the poll for the new meeting time please do so https://doodle.com/poll/zxv6d2mxngmhb3vc16:55
*** shyamb has quit IRC16:58
kmalloccmurphy: are those times supposed to convert to my timezone, or is incorrectly showing Pacific time?17:13
cmurphykmalloc: i created it using pacific time, if the times don't make sense for pacific time then i screwed up17:13
kmalloccol17:14
kmalloccool*17:14
kmallocsecond, is it intending to push the time to earlier in the day?17:14
kmalloci'm not sure what the timing issue is at the moment17:14
cmurphythe issue is that pretty soon we won't have anyone who attends from europe, and the current time is really inconvenient for wxy-xiyuan and vishakha so i thought revisiting it would be a good idea17:16
kmallocah17:17
kmallocunfortunately, the tuesday 8am, 9am (depending on DST) works the best for me. but as long as we aren't pushing it super early I can probably make it work (regardless of doodle responses)17:18
*** erus has quit IRC17:18
*** erus has joined #openstack-keystone17:19
cmurphyif we can't find something more agreeable for everyone then we can stick with the current slot17:19
kmallocjust letting you know I responded to doodle with preferred times17:20
kmallocbut pretty much anything tuesday/wed/thurs will work17:20
cmurphythanks kmalloc17:20
kmallocnow i need to get that RBAC fix rolled17:29
kmalloci figured out what needs to happen17:29
kmallocit needs a new resource object17:29
kmallocshould be straightforward17:29
kmalloci'll submit another fix (not backporting) to fix the typo in the log line17:30
lbragstadoh - i automatically assumed it was converted to my tz17:39
lbragstadoh nevermind...17:39
cmurphymaybe double check17:39
lbragstadall times displayed in America/Chicago17:40
lbragstadsweet17:40
kmallocah nice17:40
cmurphymy other motivation is all my other meetings are always scheduled at exactly that time17:43
*** mvkr has quit IRC17:44
lbragstadkmalloc we have a few laggard patches to stable/stein that need some reviews17:45
lbragstadhttps://etherpad.openstack.org/p/keystone-stein-rc2-tracking17:45
* kmalloc nods.17:45
kmalloci'll get to those once i have the RBAC thing proposed so we can backport17:45
lbragstadfantastic17:46
lbragstadkmalloc do you run your 4k monitors off usb-c?17:46
kmallocdisplay-port17:47
lbragstadto mini display port?17:47
kmallocon my laptop? uhm i think i just use HDMI17:47
kmalloci mostly use my desktops these days with 4k monitor(s)17:47
lbragstaddo you get throttled at 30 Hz refresh rates?17:47
kmalloci'd need to check the hdmi port version, but probably17:48
* lbragstad nods17:48
kmallocwith my desktop(s) I am using displayport for 1440p 144hz17:48
lbragstadi know my x1c has HDMI 1.4 but i think you have a newer version17:48
kmallocand my other desktop i'm doing HD-BaseT (HDMI over Cat7) and getting 4k@60hz 4:4:417:49
lbragstadnice17:49
*** erus has quit IRC17:49
kmallocif i was to connect the laptop, if the laptop has tb3, i'd go usb-c/tb3->displayport17:50
*** erus has joined #openstack-keystone17:50
lbragstadok - that's what i was curious about17:50
lbragstadi just ordered a displayport -> usb-c adapter17:50
lbragstadhttps://www.amazon.com/gp/product/B01NBX352B17:51
lbragstadit *should* take care of the issue17:51
lbragstad(i had to update BIOS firmware last night)17:51
kmalloclbragstad: what laptop did you replace yours with? or something else?17:54
lbragstadi got the x1c back up and running17:55
kmallocah nice17:55
kmallocanother option would be to get one of the apple-certified 5k tb3 monitors17:55
lbragstadbaby steps ;)17:55
kmallocthen you don't need an adapter17:55
kmalloc:P17:55
lbragstadyeah - that would be nice17:55
*** jamesmcarthur has joined #openstack-keystone18:05
*** jamesmcarthur has quit IRC18:53
*** jamesmcarthur has joined #openstack-keystone19:16
*** vishakha has quit IRC19:26
*** efried_rollin is now known as efried19:45
*** pcaruana has quit IRC19:53
openstackgerritColleen Murphy proposed openstack/keystone master: Remove redundant policies from v3cloudsample  https://review.openstack.org/64758620:02
*** lbragstad has quit IRC20:05
*** erus has quit IRC20:17
*** erus has joined #openstack-keystone20:17
kmallochuh20:20
kmallocthis rbac one is weird.20:21
*** erus has quit IRC20:35
*** erus has joined #openstack-keystone20:36
*** lbragstad has joined #openstack-keystone20:43
*** ChanServ sets mode: +o lbragstad20:43
*** itlinux has quit IRC20:46
openstackgerritMorgan Fainberg proposed openstack/keystone master: Raise METHOD NOT ALLOWED instead of 500 error on protocol create  https://review.openstack.org/64824120:50
kmalloccmurphy: ^ lets see what zuul has to say about that.20:50
cmurphysweet20:51
cmurphykmalloc: method not allowed is 405 though20:52
kmallocdid I typo?20:52
openstackgerritMorgan Fainberg proposed openstack/keystone master: Raise METHOD NOT ALLOWED instead of 500 error on protocol create  https://review.openstack.org/64824120:53
cmurphytypo'd in the comment plus i thought in the bug it was agreed it should be a 40420:53
kmalloclooking further it should be a 40520:53
kmallocbecause it is basically hitting where the list endpoint is... afaict20:54
kmallocthis api sucks btw. we require the protocol id on the url, which is silly20:54
cmurphyis 405 what would have happened before flask?20:54
kmallocno, before flask it would have been an unrouted 40420:54
kmallocwhich with flask became 40520:54
cmurphyand changing that isn't an api break?20:55
kmallocnot really.20:55
kmallocwe opted to make it a 405 so we can say "no a put here isn't allowed" for example, or a POST20:56
kmallocit never hit our app before20:56
kmallocit fell through and apache said 40420:56
cmurphyah okay20:57
kmallocyeah. it's a weird edge case.20:57
kmallocthat patch is probably going to fail.20:58
kmallocmy local environment exploded so i can't run tox atm.20:58
*** mchlumsky has quit IRC21:01
*** jmlowe has quit IRC21:20
*** whoami-rajat has quit IRC21:28
*** erus has quit IRC21:35
*** erus has joined #openstack-keystone21:36
*** erus has quit IRC22:01
*** erus has joined #openstack-keystone22:01
bnemec\o/ 1700. And I just spent 15 seconds staring at a Horizon page trying to remember the word "flavor", so it's clearly time to stop. ;-)22:05
*** itlinux has joined #openstack-keystone22:14
*** raildo has quit IRC22:18
*** jmlowe has joined #openstack-keystone22:20
*** rcernin has joined #openstack-keystone22:31
*** jamesmcarthur has quit IRC22:33
*** jamesmcarthur has joined #openstack-keystone22:33
*** jamesmcarthur has quit IRC22:44
*** jamesmcarthur has joined #openstack-keystone22:48
*** jamesmcarthur has quit IRC22:51
*** jamesmcarthur has joined #openstack-keystone22:52
*** jamesmcarthur has quit IRC22:55
*** erus has quit IRC22:55
*** erus has joined #openstack-keystone22:56
*** tkajinam has joined #openstack-keystone23:00
*** lbragstad has quit IRC23:48

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