19:00:44 <lbragstad> #startmeeting keystone-office-hours
19:00:44 <openstack> Meeting started Tue Jul 25 19:00:44 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:47 <openstack> The meeting name has been set to 'keystone_office_hours'
19:00:51 <knikolla> efried: hmmm… not sure if mod_wsgi deploys it as a service
19:01:19 <knikolla> the logs should be at /var/log/keystone/keystone.log or in a screen
19:02:37 <knikolla> efried: any particular reason you're deploying through mod_wsgi?
19:02:55 <efried> uhm.  Is that not what's supposed to be happening.
19:02:57 <efried> ?
19:03:18 <mordred> lbragstad, samueldmq, morgan can I sell any of you on a +A for https://review.openstack.org/#/c/486506 and its friend https://review.openstack.org/#/c/486355 ?
19:03:25 <efried> I'm using the local.conf from our (PowerVM) CI.  Can't claim to understand everything that's in there.
19:03:33 <knikolla> efried: it's deprecated. the default deployment method is uwsgi now.
19:03:33 * mordred has a lovely chocolate mousse to offer ...
19:04:03 <efried> Lemme ask my CI guy why we're doing that...
19:04:52 <lbragstad> mordred: yeah - i should be able to give it a review a little later (unless someone else gets to it first)
19:05:18 <mordred> efried: might just be old and not updated yet
19:05:42 <efried> He says we couldn't get it working right away, and other things have been higher priority since then.
19:05:50 <mordred> lbragstad: woot - thanks! once that exists I have patches for os-client-config to actually, you know, use it! :)
19:05:50 <knikolla> efried: mordred: i see a comment on the local.conf referring to mod_wsgi being deprecated, so it's recent enough.
19:06:02 <mordred> nod
19:06:12 <knikolla> but most values there are pretty outdated. neutron is enabled by defaul now. for example.
19:06:16 <samueldmq> mordred: what is that useful for?
19:06:23 <samueldmq> get_current_versioned_data
19:06:59 <samueldmq> I looked at it earlier today, but I assume I got a bit lost in the difference from get_versioned_data
19:07:10 <mordred> samueldmq: if youhave done get_endpoint_data and have an EndpointData object and now you want to find microversion info (or other metadata) on the endpoint described by that EndpointData
19:07:32 <mordred> samueldmq: get_versioned_data takes the versions you want to look for as arguments
19:07:56 <samueldmq> mordred: and where is the last EndpointData stored in the meantiem
19:07:57 <samueldmq> ?
19:08:13 <mordred> samueldmq: consuming code
19:08:39 <mordred> samueldmq: lemme show a consumption patch
19:08:43 * efried trying with uwsgi...
19:08:48 <samueldmq> mordred: why is it not passed to that function as an argument then?
19:08:59 <samueldmq> mordred: kk that should ease the understandinig
19:09:06 <samueldmq> so many typos ... sorry
19:09:21 <mordred> samueldmq: OH - so I can explain that onemaybe easier
19:09:21 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add policy for project tags  https://review.openstack.org/486757
19:10:09 <mordred> samueldmq: user says "endpoint_data = session.get_endpoint_data(service_type='block-storage')" - no version argument is given, because the user just wants whatever is in the catalog
19:10:24 * samueldmq nods
19:10:58 <mordred> samueldmq: then, at a later point in the program, the user needs some microversion info - they still don't have a version range they are interested - they just want the info for the thing they've got
19:11:10 <mordred> samueldmq: so without get_current_versioned_data they'd need to do:
19:11:57 <mordred> samueldmq: get_versioned_data(endpoint_data.api_version, (endpoint_data.api_version[0], 'latest'))
19:12:07 <mordred> which is just awkward :)
19:12:55 <samueldmq> hmm what would endpoint_data.api_version look like?
19:13:21 <mordred> it's a version tuple - so (3, 0) or (2, 0)
19:13:42 <samueldmq> is that the version the user wants?
19:13:54 <mordred> I meanm, I supose the user could actually also just do "get_versioned_data(endpoint_data.api_version, endpoint_data.api_version)
19:13:59 <samueldmq> the second argument is min/max, that's clear
19:14:14 <mordred> samueldmq: api_version is the version that was found for the endpoint in question
19:14:43 <mordred> so if EndpointData is data about an endpoint, EndpointData.api_version is the major api versino of that endpoint
19:15:25 <samueldmq> mordred: and what's the difference of the endpoint_data the user already has and the result of get_versioned_data(endpoint_data.api_version, endpoint_data.api_version)
19:17:00 <morgan> mordred: as soon as I am home from lunch.
19:17:03 <mordred> samueldmq: microversoin information - the initial endpoint_data may not have it if doing the fetch of the version discovery document was not needed to satisfy the initial request
19:17:29 <mordred> samueldmq: we try to avoid such a GET if we can so that we don't fetch when it's not needed
19:23:23 <samueldmq> mordred: kk. I've got a comment in https://review.openstack.org/#/c/486506
19:23:27 <samueldmq> a question
19:26:31 <mordred> awesome
19:26:33 <mordred> thanks!
19:26:53 <samueldmq> mordred: nvm me, I confused normalize_version_number with _normalize_version_args
19:29:39 <mordred> samueldmq::) - I was just saying that :)
19:30:45 <samueldmq> mordred: :) do you have an example using that?
19:30:52 <samueldmq> you mentioned earlier you have some code ..
19:31:54 <mordred> oh - right - I thought I did, but now I can't find it - I'm going to blame jetlag
19:32:00 * mordred keeps looking
19:33:22 <samueldmq> mordred: hmm.. so get_current_versioned_data is what will trigger the min and max microversion values to be set, right?
19:33:38 <samueldmq> in the endpointdata itself
19:34:17 <mordred> samueldmq: well, it will return a new EndpointData with those filled in - but yes, exactly
19:34:19 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add new tags attribute to project  https://review.openstack.org/470317
19:34:20 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/484483
19:34:20 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/484456
19:34:48 <samueldmq> mordred: kk yes, as get_endpoint_data fills in another endpointdata based in the current one
19:37:42 <mordred> ++
19:39:44 <efried> mordred Was this what you were looking for? https://review.openstack.org/#/c/485868/1
19:40:20 <efried> knikolla et al, uwsgi didn't help, same result.
19:40:25 <mordred> efried: yes! I knew I'd written code somewhere ... thanks!
19:40:28 <samueldmq> mordred: that will also cause the latest minor version ot be discovered, right?
19:40:29 <mordred> samueldmq: ^^
19:40:46 <efried> aha!, but now I have a journalctl for it!
19:40:53 <samueldmq> mordred: like if the endpointdata has (3,0), min will be (3,0) and max will be (3,latest) in the re-discovery
19:41:26 <efried> It's paste.  Stupid paste.  Thanks for the help knikolla
19:41:56 <mordred> samueldmq: yah - there isn't actually much story around multiple parallel major versions with different minor versions
19:42:07 <knikolla> efried: anytime. if all you need is a basic devstack with the usual services, the samples/local.conf is usually good enough for me, without any changes.
19:42:31 <efried> knikolla My victim is PowerVM, where nothing is that simple :)
19:42:51 <knikolla> efried: good luck!
19:43:06 <mordred> samueldmq: it's written like (3,0), (3,latest) because the api_version in endpoint_data is probably inferred from the url, so if we just did "(3, 0), (3, 0)" it might actually fail because the actual version of the endpoint might be 3.4
19:43:22 <mordred> samueldmq: but there will only be the one v3 endpoint
19:44:50 <samueldmq> mordred: ah that's smart
19:45:07 <samueldmq> so we can infer a range from what we got from the url
19:45:35 <samueldmq> and get what we want/need from catalog (3.4 in that example)
19:45:49 <mordred> yes! exactly
19:46:45 <samueldmq> mordred: approved. sorry for the mess and dumb questions :-)
19:48:26 <mordred> samueldmq: no - those are great questions! thanks for the review
19:57:54 <openstackgerrit> Merged openstack/keystone master: Move auth plugin development doc to contrib guide  https://review.openstack.org/484168
20:27:08 <knikolla> rodrigods: around?
20:35:28 <openstackgerrit> Kristi Nikolla proposed openstack/keystone master: In the devstack plugin, restart keystone after modifying conf  https://review.openstack.org/487202
20:36:14 <knikolla> one bug down, hopefully
20:37:56 <lbragstad> knikolla: nice - i assume we'll be able to see the tempest plugin tests pass?
20:38:00 <lbragstad> if it works
20:38:26 <knikolla> lbragstad: i wasn't able to test it. but based on the log files, the diagnosis is very plausible.
20:40:33 <knikolla> lbragstad: i still need to move the tests to using a local shibboleth rather than testshib. but i think i will have to prioritize getting k2k functional testing up before that.
20:40:49 <lbragstad> yeah - that makes sense
20:41:30 <knikolla> lbragstad: already have a patch up for keystone-as-an-idp in the plugin. and i'm fairly familiar with multinode devstack configuration, if that's the route we want to go for it.
21:07:49 <openstackgerrit> Merged openstack/keystoneauth master: Add tests to specifically test trailing slash behavior  https://review.openstack.org/486355
21:08:41 <openstackgerrit> Merged openstack/keystoneauth master: Record the discovered major api version  https://review.openstack.org/486506
21:21:15 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Emit deprecation warning for federated domain/project APIs  https://review.openstack.org/487219
21:34:35 <rodrigods> knikolla, now i am
21:44:56 <openstackgerrit> Samriddhi proposed openstack/keystone master: Removed token-provider doc  https://review.openstack.org/483276
21:45:40 <lbragstad> #link https://goo.gl/9vuCjS
21:45:51 <lbragstad> ^ link to all bugs targeted to pike-rc1
21:48:38 <breton> why have we chosen to use the expand-migrate-contract procedure instead of nova's versionedobjects?
21:53:32 <lbragstad> breton: the reasoning, at least from what I remember of that conversation, was because keystone doesn't really have a layer that sits in between the app and the database
21:54:19 <lbragstad> breton: all nova-apis or nova-compute nodes talk to nova-conductor to get things from the database
21:55:08 <lbragstad> which it nice in some ways because it allows you to make nova-conductor smart enough to handle representing objects in specific ways depending on the backend
21:56:12 <lbragstad> but for keystone - if you scale it out horizontally, each node can make requests directly to the data store
22:04:05 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Consolidate certificate docs to admin-guide  https://review.openstack.org/477685
22:04:23 <lbragstad> #endmeeting