Monday, 2017-07-17

*** thorst has joined #openstack-keystone00:59
*** ducttape_ has joined #openstack-keystone01:03
*** thorst has quit IRC01:04
*** ducttape_ has quit IRC01:07
*** zhurong has joined #openstack-keystone01:20
*** zhurong has quit IRC01:23
*** liujiong has joined #openstack-keystone01:24
*** markvoelker has joined #openstack-keystone01:29
*** liujiong_lj has joined #openstack-keystone01:36
*** liujiong has quit IRC01:37
*** liujiong_lj is now known as liujiong01:39
*** sbezverk has quit IRC01:42
*** markvoelker has quit IRC02:03
*** zhurong has joined #openstack-keystone02:31
openstackgerritzhengliuyang proposed openstack/keystone master: Assert default project id is not domain  https://review.openstack.org/48423502:51
*** markvoelker has joined #openstack-keystone03:00
*** thorst has joined #openstack-keystone03:01
*** dave-mccowan has quit IRC03:04
*** thorst has quit IRC03:05
*** markvoelker has quit IRC03:34
*** links has joined #openstack-keystone03:44
*** hoonetorg has quit IRC04:05
*** markvoelker has joined #openstack-keystone04:30
openstackgerritMerged openstack/keystonemiddleware master: Redundant adminURL in test_gives_v2_catalog  https://review.openstack.org/47945804:33
*** Dinesh_Bhor has joined #openstack-keystone04:46
*** thorst has joined #openstack-keystone05:01
*** ducttape_ has joined #openstack-keystone05:03
*** zhurong has quit IRC05:04
*** markvoelker has quit IRC05:04
*** thorst has quit IRC05:06
*** ducttape_ has quit IRC05:08
openstackgerritzhengliuyang proposed openstack/keystone master: Assert default project id is not domain  https://review.openstack.org/48423505:19
*** nicolasbock has joined #openstack-keystone05:28
*** zhurong has joined #openstack-keystone05:29
*** sbezverk has joined #openstack-keystone05:34
openstackgerritLiChunlin proposed openstack/keystone master: Add a hacking rule for string interpolation at logging  https://review.openstack.org/48425005:45
*** rcernin_ has joined #openstack-keystone06:00
*** nicolasbock has quit IRC06:13
openstackgerritSamriddhi proposed openstack/keystone master: Added index.rst in each sub-directory  https://review.openstack.org/48415706:14
*** nicolasbock has joined #openstack-keystone06:15
openstackgerritSamriddhi proposed openstack/keystone master: Added new docs to admin section  https://review.openstack.org/48416506:19
*** edmondsw has joined #openstack-keystone06:39
*** edmondsw has quit IRC06:43
*** namnh has joined #openstack-keystone06:58
openstackgerritSamriddhi proposed openstack/keystone master: Expanded the best practices subsection in devdocs  https://review.openstack.org/47654106:59
*** markvoelker has joined #openstack-keystone07:01
*** thorst has joined #openstack-keystone07:02
*** thorst has quit IRC07:07
*** phalmos has quit IRC07:09
*** toddnni has quit IRC07:18
*** aojea has joined #openstack-keystone07:19
*** toddnni has joined #openstack-keystone07:25
*** tesseract has joined #openstack-keystone07:32
*** markvoelker has quit IRC07:35
*** aselius has quit IRC08:02
*** ducttape_ has joined #openstack-keystone08:03
*** ducttape_ has quit IRC08:08
afazekasandreaf, ping08:27
*** thorst has joined #openstack-keystone08:27
*** markvoelker has joined #openstack-keystone08:31
*** thorst has quit IRC08:32
*** tesseract has quit IRC08:50
*** tesseract has joined #openstack-keystone08:53
*** daidv__ has joined #openstack-keystone09:00
*** markvoelker has quit IRC09:05
namnhHi everyone, I see the config file like nova.conf, neutron.conf. There is a option named "user_domain_name" in "keystone_authtoken" section. But I don't find the option declared anymore. Do you know what do the option purpose for?09:45
*** markvoelker has joined #openstack-keystone10:02
bretonnamnh: it sets user's domain name10:06
*** liujiong has quit IRC10:06
namnhbreton: thanks for your reply. But I don't find the option that is declared anywhere. I am wondering how it is called?10:07
bretonnamnh: service user's domain name10:07
bretonnamnh: what do you understand by declared?10:08
*** jistr is now known as jistr|afk10:09
bretonnamnh: i guess it is described in keystoneauth package: https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/_plugins/identity/v3.py#L2510:09
*** d0ugal has joined #openstack-keystone10:13
andreafafazekas: pong10:15
*** edmondsw has joined #openstack-keystone10:15
*** edmondsw has quit IRC10:19
*** d0ugal has quit IRC10:19
*** kiennt_ has joined #openstack-keystone10:26
namnhbreton: great, you are right, one more thing, do you know how can I get value if the option. I tried "CONF.keystone_authtoken.user_domain_name" but it didn't work.10:26
*** thorst has joined #openstack-keystone10:28
*** thorst has quit IRC10:32
*** mvk has quit IRC10:33
*** markvoelker has quit IRC10:35
*** aloga has quit IRC10:36
*** aloga has joined #openstack-keystone10:36
*** kiennt_ has quit IRC10:37
*** ganso has joined #openstack-keystone10:43
*** ganso has left #openstack-keystone10:44
*** namnh has quit IRC10:57
*** raildo has joined #openstack-keystone10:58
*** mvk has joined #openstack-keystone11:00
*** thorst has joined #openstack-keystone11:08
*** thorst has quit IRC11:09
*** thorst has joined #openstack-keystone11:16
afazekasandreaf, https://review.openstack.org/#/c/479286/11:18
afazekasandreaf, The keystone behavior as it was discussed ages before http://lists.openstack.org/pipermail/openstack-dev/2014-July/039140.html is invalid , so we do not really need to maintain backward invalidity11:19
afazekasandreaf, tempest testing that api call since https://review.openstack.org/#/c/462507/211:22
openstackgerritMerged openstack/ldappool master: Turn on warning-is-error for sphinx build  https://review.openstack.org/48414611:27
*** hoonetorg has joined #openstack-keystone11:32
*** markvoelker has joined #openstack-keystone11:32
*** raildo has quit IRC11:56
*** markvoelker has quit IRC11:56
*** markvoelker has joined #openstack-keystone11:57
*** aojea has quit IRC11:57
openstackgerritDmitri Plakhov proposed openstack/keystone master: Added filtering of empty extra properties  https://review.openstack.org/48433812:01
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Fix masked variable name  https://review.openstack.org/48434012:06
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Add support for service type aliases  https://review.openstack.org/48434112:06
*** jistr|afk is now known as jistr12:17
*** raildo has joined #openstack-keystone12:18
openstackgerritM V P Nitesh proposed openstack/keystone master: Can add description for role creation in OSC  https://review.openstack.org/48434812:22
*** ducttape_ has joined #openstack-keystone12:27
*** edmondsw has joined #openstack-keystone12:34
*** edmondsw has quit IRC12:34
*** edmondsw has joined #openstack-keystone12:35
*** ducttape_ has quit IRC12:42
*** ducttape_ has joined #openstack-keystone12:43
*** ducttape_ has quit IRC12:43
openstackgerritMerged openstack/python-keystoneclient master: Update URLs in documents according to document migration  https://review.openstack.org/48372412:45
*** catintheroof has joined #openstack-keystone12:51
*** aojea has joined #openstack-keystone12:52
*** aojea has quit IRC12:56
*** ayoung has joined #openstack-keystone13:03
*** edmondsw_ has joined #openstack-keystone13:04
*** edmondsw has quit IRC13:07
*** aojea has joined #openstack-keystone13:19
*** zhurong has quit IRC13:22
*** aojea has quit IRC13:26
*** lbragstad has quit IRC13:26
*** superdan is now known as dansmith13:33
*** markvoelker_ has joined #openstack-keystone13:33
*** markvoelker has quit IRC13:33
*** edmondsw has joined #openstack-keystone13:34
*** edmondsw_ has quit IRC13:36
*** links has quit IRC13:37
*** markvoelker_ has quit IRC13:38
*** markvoelker has joined #openstack-keystone13:39
*** bknudson has joined #openstack-keystone13:41
*** ducttape_ has joined #openstack-keystone13:45
*** aojea has joined #openstack-keystone13:48
*** ducttape_ has quit IRC13:50
*** sbezverk has quit IRC13:51
*** ducttape_ has joined #openstack-keystone13:51
*** sbezverk has joined #openstack-keystone13:51
cmurphybknudson: if you have time I wonder if you could weigh in on this backport https://review.openstack.org/#/c/483308/ ? it's related to a bug you originally reported13:56
*** lwanderley has joined #openstack-keystone13:59
*** chlong has joined #openstack-keystone14:05
*** lucasxu has joined #openstack-keystone14:06
bknudsonI'm not seeing the change to actually fix the bug…14:06
bknudsonoh, that's here: https://review.openstack.org/#/c/217348/14:07
bknudsonok, so https://review.openstack.org/#/c/483308/ is a follow-on.14:09
*** chlong has quit IRC14:10
bknudsonif you want to know if some behavior changed then try it out. Not worth trying to interpret the code.14:11
bknudsonand I don't have the time to try this out right now. I can add it to my list.14:12
hrybackianyone in here with some THT experience that can lend me an eye?14:18
*** lbragstad has joined #openstack-keystone14:29
*** ChanServ sets mode: +o lbragstad14:29
cmurphybknudson: was more looking for insight on the original intent than on actual behavior, but no worries, i'll dig some more14:32
openstackgerritMerged openstack/pycadf master: Update URL in docs as per the doc-migration spec  https://review.openstack.org/48395814:32
*** gyee has joined #openstack-keystone14:37
*** aojea has quit IRC14:40
gagehugoo/14:43
lbragstado/14:43
*** aselius has joined #openstack-keystone14:47
*** lwanderley has quit IRC14:48
*** ayoung has quit IRC14:49
edmondswlbragstad see the comments I just added in https://bugs.launchpad.net/keystone/+bug/1704205 and let me know what you think14:51
openstackLaunchpad bug 1704205 in OpenStack Identity (keystone) "GET /v3/role_assignments?effective&include_names API fails with unexpected 500 error" [Undecided,New]14:51
knikollao/14:59
openstackgerritLance Bragstad proposed openstack/keystone master: Remove duplicate configuration sections  https://review.openstack.org/48416715:00
*** lucasxu has quit IRC15:00
openstackgerritLance Bragstad proposed openstack/keystone master: Remove duplicate configuration sections  https://review.openstack.org/48416715:01
openstackgerritLance Bragstad proposed openstack/keystone master: Remove duplicate configuration sections  https://review.openstack.org/48416715:05
lbragstadcmurphy: rebased and resolved the merge conflicts there ^15:06
*** gyee has quit IRC15:06
andreafafazekas: I don't disagree that 204 is incorrect, but it's what keystone returns now - so changing might break someone, if it's not done in a "discoverable" way15:08
*** gyee has joined #openstack-keystone15:08
*** otleimat has joined #openstack-keystone15:08
*** lwanderley has joined #openstack-keystone15:16
*** lwanderley has quit IRC15:17
*** lucasxu has joined #openstack-keystone15:27
*** aojea has joined #openstack-keystone15:31
afazekasandreaf, most user checks for 2** , I have doubts about is it really breaks someone in practice.  Likely the users using the GET version and not really using it too frequently (however I do not have real statistics about this call)  .15:34
andreafafazekas: yeah I agree that most people will check for 2**15:35
andreafafazekas: but we have no way of knowing15:35
*** chlong has joined #openstack-keystone15:36
*** aojea has quit IRC15:36
*** chlong has quit IRC15:38
afazekasandreaf, you are right about this, but IMHO more piratical and simpler simply just changing it to 200, I expect it will cause less headache in the long run than considering which version do we have ATM15:39
*** david-lyle has joined #openstack-keystone15:40
lbragstadkeystone doesn't support microversions at the moment15:40
andreafyeah I agree it's more practical, but it breaks a principle, so if we are going to do it I want to make sure it's clear to everyone15:40
andreafis there a patch up on keystone side for this already? afazekas @lbragstad15:41
afazekasIt is clear to me, and as I said I consider the rfc stuff more important principal15:41
lbragstadandreaf: for microversion support in keystone?15:42
andreaf@lbragstad: heh no I meant to change the return code from 204 to 20015:42
lbragstadandreaf: oh - I'm not sure, I can check15:42
lbragstadandreaf: parsing the bug report - I don't see a patch to keystone that changes that response15:44
andreaf@lbragstad: no worries, I was just wandering about https://review.openstack.org/#/c/479286/ - afazekas before we do any change on Tempest side I would like to make sure the keystone project decided to change the response code15:45
*** chlong has joined #openstack-keystone15:45
lbragstadandreaf: ack - that makes sense15:45
andreaf@lbragstad: plans to support microversions in keystone?15:45
lbragstadandreaf: i don't expect keystone to attempt making that change until we have microversions15:45
lbragstadandreaf: we've talked about it a couple times, specifically at the PTG in atlanta15:46
*** aloga_ has joined #openstack-keystone15:46
lbragstadandreaf: this was the recap we had on it during the PTG - https://etherpad.openstack.org/p/pike-ptg-keystone-ocata-carry-over15:46
afazekaslbragstad, If keystone does not wants to change that code in this cycle, likely I need to make sure it has bad status code also on centos/rhel , otherwise it would fail the default tempest tests..15:48
*** ducttape_ has quit IRC15:49
afazekashttps://bugzilla.redhat.com/show_bug.cgi?id=146679915:49
openstackbugzilla.redhat.com bug 1466799 in mod_wsgi "mod_wsgi forces HEAD to GET" [Unspecified,New] - Assigned to webstack-team15:50
lbragstadafazekas: so if rhel/centos are using mod_wsgi 4.3.0 you don't have a problem, right?15:54
*** aloga_ has quit IRC15:54
*** swain has joined #openstack-keystone15:55
afazekaslbragstad, It would pass the tempest test, but It would not be rfc friendly15:55
lbragstadafazekas: right - but it would work until we get to a point where we can fix the actual response code15:56
*** aloga_ has joined #openstack-keystone15:56
*** hoonetorg has quit IRC15:57
lbragstadmorgan: ping16:01
openstackgerritGage Hugo proposed openstack/keystone master: Enable sphinx todo extension  https://review.openstack.org/48441116:04
*** lwanderley has joined #openstack-keystone16:08
afazekaslbragstad, changing package version this time is not so easy  also shipping different versions with openstack is complicated.  We served the `right` status code in prev year(s) ,  it is unpleasant we would need to make it non rfc friendly in-order to pass tempest. For RHEL users that mod_wsgi update would give a different status code than what they had before.   Anyone who is dealing with multiple openstacks they would see both codes anyway,16:10
afazekas until today  we did not received any blame from any user because we have 200 .16:10
openstackgerritGage Hugo proposed openstack/keystonemiddleware master: Enable sphinx todo extension  https://review.openstack.org/48441516:11
*** aloga_ has quit IRC16:15
morganlbragstad: pong16:15
lbragstadi just got done re-reading https://bugs.launchpad.net/keystone/+bug/1576765 after reviewing https://review.openstack.org/#/c/484338/116:16
openstackLaunchpad bug 1576765 in OpenStack Identity (keystone) "Potential DOS: Keystone Extra Fields" [Medium,Triaged]16:16
lbragstadmorgan: thoughts on filtering extras?16:16
morganlbragstad: sadly16:17
morganbreak in behavior16:17
morgancan't accept it16:17
morganbreaks contract16:17
lbragstadok - that's what i was thinking16:17
lbragstadmorgan: what if there was the ability to filter optionally?16:18
openstackgerritGage Hugo proposed openstack/keystoneauth master: Enable sphinx todo extension  https://review.openstack.org/48441716:18
morganlbragstad: eh. i don't see a huge benefit to that16:19
morganthe short answer is "please, please, please do not use extras"16:19
*** rcernin_ has quit IRC16:19
morganextras are terrible.16:19
lbragstadagreed16:19
morganand should die... but ca't16:19
morgancan't*16:19
lbragstadat least until we have microversions or v516:19
lbragstadv4*16:19
morganyep16:21
morgani -2'd that patch btw16:21
morganand set the extras bug to "wont fix"16:21
lbragstadmorgan: setting to won't fix because the fix for it breaks API backwards compatibility?16:22
lbragstadmorgan: the specification you proposed only breaks backwards compatibility if the operator ops into it, right?16:23
*** prashkre has joined #openstack-keystone16:24
*** aojea has joined #openstack-keystone16:26
openstackgerritLance Bragstad proposed openstack/keystone master: Move performance documentation to admin-guide  https://review.openstack.org/48138316:27
*** aojea has quit IRC16:30
*** ducttape_ has joined #openstack-keystone16:34
*** knikolla has quit IRC16:40
*** hoonetorg has joined #openstack-keystone16:41
openstackgerritMerged openstack/keystone master: Update info about logging in admin guide  https://review.openstack.org/47858316:41
*** spotz has quit IRC16:42
*** spotz has joined #openstack-keystone16:45
*** aojea has joined #openstack-keystone16:45
*** aojea has quit IRC16:49
*** hoonetorg has quit IRC16:54
openstackgerritMatthew Edmonds proposed openstack/keystone master: don't validate trust in policy  https://review.openstack.org/48219017:01
*** aojea has joined #openstack-keystone17:03
*** hoonetorg has joined #openstack-keystone17:03
*** chlong has quit IRC17:03
morganlbragstad: breaks compat17:06
*** mvk has quit IRC17:06
morganlbragstad: lets not have more "opt in" type options that changes API workings17:06
*** aojea has quit IRC17:07
*** aojea has joined #openstack-keystone17:12
*** aojea has quit IRC17:16
*** lwanderley has quit IRC17:16
*** harlowja has joined #openstack-keystone17:17
*** chlong has joined #openstack-keystone17:19
*** aojea has joined #openstack-keystone17:21
*** aojea has quit IRC17:25
*** ducttape_ has quit IRC17:28
*** ducttape_ has joined #openstack-keystone17:28
*** aojea has joined #openstack-keystone17:31
*** hoonetorg has quit IRC17:34
*** knikolla_ has joined #openstack-keystone17:34
knikolla_bouncer down again :(17:34
*** aojea has quit IRC17:36
*** mvk has joined #openstack-keystone17:37
*** ducttape_ has quit IRC17:39
*** swain is now known as zenyatta17:39
*** aojea has joined #openstack-keystone17:40
*** zenyatta is now known as swain17:42
*** ducttape_ has joined #openstack-keystone17:44
*** aojea has quit IRC17:45
*** sjain has joined #openstack-keystone17:45
*** aojea has joined #openstack-keystone17:50
*** aojea has quit IRC17:51
*** aojea has joined #openstack-keystone17:51
openstackgerritSamriddhi proposed openstack/pycadf master: Switch from oslosphinx to openstackdocstheme  https://review.openstack.org/48392217:52
openstackgerritSamriddhi proposed openstack/pycadf master: Turn on warning-is-error for sphinx build  https://review.openstack.org/48394517:53
*** hoonetorg has joined #openstack-keystone17:54
*** aojea has quit IRC17:56
openstackgerritSamriddhi proposed openstack/pycadf master: Switch from oslosphinx to openstackdocstheme  https://review.openstack.org/48392217:58
*** hoonetorg has quit IRC17:59
*** ducttape_ has quit IRC17:59
*** tesseract has quit IRC18:01
*** ducttape_ has joined #openstack-keystone18:04
*** ducttap__ has joined #openstack-keystone18:06
*** sjain has quit IRC18:06
*** aojea has joined #openstack-keystone18:07
*** sjain has joined #openstack-keystone18:08
*** ducttape_ has quit IRC18:10
*** aojea has quit IRC18:11
*** aojea has joined #openstack-keystone18:16
*** aojea has quit IRC18:21
*** rcernin has joined #openstack-keystone18:26
samueldmqmorgan: lbragstad: sjain and I need help understanding the "Relationship" URLs we have in our api docs18:26
samueldmq:-)18:26
sjainhttps://developer.openstack.org/api-ref/identity/v3/?expanded=password-authentication-with-unscoped-authorization-detail18:27
*** ducttap__ has quit IRC18:32
*** ducttape_ has joined #openstack-keystone18:32
*** aojea has joined #openstack-keystone18:35
*** aojea has quit IRC18:37
edmondswlbragstad replied to your concern in https://review.openstack.org/#/c/48219018:46
lbragstadedmondsw: cool - thanks!18:46
edmondswlbragstad short answer... there's no interoperability concern here18:46
openstackgerritSamriddhi proposed openstack/keystone master: Reorganised developer documentation  https://review.openstack.org/47660618:46
*** dpar has joined #openstack-keystone18:46
edmondswif you still think otherwise, let's discuss18:46
lbragstadedmondsw: this is moving a 403 -> 400 though18:47
lbragstadoh - nevermind18:47
*** SamYaple has quit IRC18:47
*** SamYaple has joined #openstack-keystone18:47
edmondswyou'r right... I think I said 401 -> 400, but yes, it's 403 -> 400... but it still has no interoperability impact18:47
lbragstadedmondsw: can you walk me through that?18:48
edmondswclients already have to support both 403 and 40018:48
edmondswso no client will be affected by this change18:48
lbragstadedmondsw: is there documentation on that - so i can educate myself/18:49
*** ducttape_ has quit IRC18:49
lbragstadi buy the fact clients should already support 400 and 403, but what about if a client issues a request to an Ocata installation and a Pike installation?18:50
edmondswlbragstad well there are the HTTP RFCs...18:50
edmondswlbragstad what about it?18:50
lbragstadedmondsw: http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html describes interoperability across versions in a single deployment, but also interoperability across deployments and versions18:51
edmondswlbragstad yep, I'm familiar18:51
edmondswsat in those meetings at the PTG18:51
lbragstaddoes that change break the second one?18:52
edmondswlbragstad some might tell you that it might, but no, it doesn't18:52
edmondswnot IMHO anyway18:52
edmondswactually, this all may be moot... let me check something18:52
lbragstadcan you share your reasoning as to why you don't think it does?18:53
*** ducttape_ has joined #openstack-keystone18:56
edmondswlbragstad https://github.com/openstack/keystone/blob/master/keystone/trust/controllers.py#L130-L13218:56
edmondswthe same check as before is still done... just in that code segment instead of in policy18:56
edmondswlbragstad I already shared the reasoning... that clients are already coded to support both 403 and 400, so it doesn't matter which you give... they will handle it18:57
edmondswlbragstad the only case where anyone would see a change in the response code is if there were 2 problems with the request... they didn't specify a trustor_user_id matching their own user_id (403) and they didn't make a valid request (400)18:59
edmondswlbragstad formerly, the 403 issue would have been noticed first and a 403 returned18:59
edmondswlbragstad now the 400 would be noticed first and 400 returned18:59
edmondswlbragstad but the 400 is actually a better response here, so you're actually helping clients, not harming them19:00
edmondswinterop doesn't really come into this at all, since clients have to be coded to handle it already19:00
edmondswlbragstad or if you don't like that reasoning, here's another... clients aren't going to make a request that would see this change... their developers will code them to make valid requests19:03
*** nicolasbock has quit IRC19:03
openstackgerritSamriddhi proposed openstack/keystone master: Added new subsections to developer docs  https://review.openstack.org/47663519:04
edmondswlbragstad what the interop guidelines were concerned about is changing what error code signifies a given problem. This isn't doing that. 403 is still used if trustor_user_id doesn't match context.user_id.19:05
lbragstadedmondsw: but 403 was used if the trustor didn't exist, right19:05
lbragstad?19:05
*** nicolasbock has joined #openstack-keystone19:05
edmondswlbragstad ^ that last may be the best reasoning19:06
lbragstads/didn't exist/wasn't in the request/19:06
edmondsw403 was incorrectly used if trustor_user_id was not specified at all in the request. The client would not have been able to distinguish that from a real 403 case, so that's bad and sticking with it helps noone19:06
lbragstadedmondsw: yeah - i'm not arguing that it is wrong19:07
edmondswright, we're talking about what is best for clients, specifically from an interop perspective... this change is better for clients is what I'm saying19:08
lbragstadwhat i'm really trying to get to here is whether or not we need a microversion in order to do something like this, which is why i went to the guidelines19:08
edmondswno19:09
*** cmurphy has quit IRC19:09
*** cmurphy has joined #openstack-keystone19:10
*** ducttape_ has quit IRC19:10
*** knikolla has joined #openstack-keystone19:14
*** knikolla_ has quit IRC19:16
openstackgerritGage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/48445619:20
*** ducttape_ has joined #openstack-keystone19:22
openstackgerritJaewoo Park proposed openstack/keystone master: WIP: Add project tags  https://review.openstack.org/47031719:27
*** ducttape_ has quit IRC19:28
*** harlowja has quit IRC19:32
*** ducttape_ has joined #openstack-keystone19:34
*** sjain has quit IRC19:36
*** dave-mccowan has joined #openstack-keystone19:44
*** boris-42__ has joined #openstack-keystone19:48
openstackgerritNicolas Helgeson proposed openstack/keystone master: WIP: Add project tags  https://review.openstack.org/47031719:49
*** ducttape_ has quit IRC19:53
*** swain has quit IRC19:55
*** sjain has joined #openstack-keystone19:57
*** nicolasbock has quit IRC19:58
openstackgerritGage Hugo proposed openstack/keystone master: Add exception for project tag not found  https://review.openstack.org/48447119:58
morganhistorically even without microversions19:59
openstackgerritGage Hugo proposed openstack/keystone master: Add exception for project tag not found  https://review.openstack.org/48447119:59
morganchanging the error code to a more correct one has been ok19:59
morganaka 400->403, 403->40019:59
morganetc19:59
morganchanging a success code is *not* ok19:59
morganthis sounds like 400 is more correct20:00
morganso, shouldn't be an issue20:00
*** ducttape_ has joined #openstack-keystone20:02
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Add support for service type aliases  https://review.openstack.org/48434120:03
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Fix masked variable name  https://review.openstack.org/48434020:03
*** jdennis has quit IRC20:06
openstackgerritGage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/48445620:07
*** ducttape_ has quit IRC20:09
*** jdennis has joined #openstack-keystone20:10
*** dklyle has joined #openstack-keystone20:12
*** david-lyle has quit IRC20:13
*** ducttape_ has joined #openstack-keystone20:13
*** dave-mccowan has quit IRC20:17
openstackgerritMatthew Edmonds proposed openstack/keystone master: don't validate trust in policy  https://review.openstack.org/48219020:17
*** david-lyle has joined #openstack-keystone20:26
*** dklyle has quit IRC20:27
*** chlong has quit IRC20:27
lbragstadmorgan: thanks for the confirmation20:29
lbragstadmorgan: when i was reading http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html I was referencing the following20:30
lbragstad"Changing the response status code from one form of client error to another (e.g., 403 to 400) or one form of success to another (e.g., 201 to 204)."20:30
lbragstadwhich is listed under20:30
lbragstad"The following changes do require a version change:"20:30
*** prashkre has quit IRC20:30
lbragstadit'd be nice if more of those exception or examples were easier to find20:31
*** chlong has joined #openstack-keystone20:32
*** sjain has quit IRC20:32
*** raildo has quit IRC20:34
morganit was originally was changing error codes ok20:36
openstackgerritKristi Nikolla proposed openstack/keystone master: Make the devstack plugin more configurable for federation  https://review.openstack.org/48448020:36
morgani guess now the answer is it is't ok20:36
morganfor 400->other 40020:36
morganso... we can't make that change edmondsw20:36
edmondswmorgan I think this is all a misunderstanding / misinterpretation20:37
edmondswyes we can20:37
edmondswthis will help clients, and has no impact on interop20:37
edmondswonce you understand what "this" is20:38
openstackgerritKristi Nikolla proposed openstack/keystone master: Make the devstack plugin more configurable for federation  https://review.openstack.org/48448020:38
edmondswmorgan note: I did not change what error code is returned for a given problem... it as 403 before, it is 403 now20:38
edmondswall that changed was the order that error conditions are checked... we'll now detect an error that causes us to return 400 before we detect an error that causes us to return 403 in this case20:39
*** ppiela_ is now known as ppiela20:39
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for projec tags  https://review.openstack.org/48448320:40
edmondswnot specifying trustor in a request is rightly a 400. Specifying an invalid trustor is a 40320:40
morganedmondsw: we cannot change the error code for a given action unless we make a new version, just like we cannot change success codes20:40
lbragstadgagehugo: thanks for breaking that up20:40
edmondswmorgan but we aren't20:40
morganif it previously would be a 40320:40
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/48448320:40
morganis the behavior changing at all20:40
morganfor a given request20:40
gagehugolbragstad np, we're gonna attempt a sprint this week to get that all done btw20:41
morganthat is the question i am asking. if the exact same request would be a 403 instead of a 400 now (or vice-versa) for whatever reason, we can't accept the change20:41
lbragstadif a trustor isn't included in the request to create a trust a 400 will be returned20:41
morganinstead of a 403?20:41
gagehugolbragstad thanks for the quick feedback!20:41
edmondswmorgan there is one case (which no client would ever do) wherein you don't specify a trustor_user_id in the request that you would now get a 400 instead of a 403. And that's a good thing, with no harm to interop20:41
lbragstadgagehugo: no problem - let me know how the sprint goes or where you need focused reviews20:42
gagehugowill do!20:42
edmondswclients have to already support both 400 and 403... nobody will be affected20:42
edmondswlogically, they can't be20:42
morganedmondsw: it isn't the clients, it is people using the rest api that are affected20:42
morganaka, shade (long term), etc20:42
edmondswmorgan them either20:42
morganwe can't change this per the standard20:42
edmondswespecially them20:42
edmondswthey can't possibly be affected20:42
morganif we now return a 400 instead of a 403 for a request, unfortunately, we are wrong20:43
edmondswI understand what the reasoning is here, protecting shade, etc... this does that20:43
edmondswshade/etc. are not impacted by this change20:43
morganthis is where microversions or major api versions are needed20:43
edmondswno, it's not20:43
morganhow does this not violate the standard by the working group?20:44
edmondswtell me how this change affects shade?20:44
edmondswor anything else, hypothetically20:44
morganit doesn't today, shade uses the client lib20:44
morganif shade was using the REST api (it is moving towards this), and it sends a request w/o a trustor in it, it is coded for a 403, now it gets a 40020:44
morganit is broken20:44
edmondswit would never do that20:44
edmondswright?20:44
morganit doesn't matter if it ever would or not20:45
morganit is the behavior of the API, which is a contract.20:45
edmondswbecause you don't write something (shade, or anything else) that makes an API request which will never work20:45
morganlook, i'm not happy about this, ok. i'm just enforcing the rules.20:45
edmondswthe API contract isn't changing here20:45
morganhave lbragstad ok the patch (+2) as is, and i will not argue, he's the one the tc/api-wg will badger20:45
morganand end users.20:46
edmondswI helped make these rules... this isn't what they were talking about20:46
morganthe contract is implicitly the behavior currently happening20:46
morganthen go clarify the rules.20:46
lbragstadyeah - i looked at the rules and that's what i came up with20:46
morganor get lbragstad / api folks to +1/+2 this20:46
morganand if this is not what you want the API interop rules to be, we need to fix them20:47
lbragstadi agree that this is wrong and that it should be a 400, i understand that bit20:47
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/48448320:47
lbragstadbut when i pulled up the guidelines, it seems pretty clear that we're breaking them unless there is a version change of some kind (e.g. microversions)20:47
morgani refuse to play moving goal posts here. the way i see it is: 1) We agree to the rules and we follow them, 2) we agree to the rules and fix them when they are wrong (this case?), 3) we disregard the rules.20:48
morganthe rules as they stand look to say this code is a violation of them20:48
morgani just don't see how we are supposed to divine the "well they don't apply here" from the verbiage currently used.20:48
lbragstadif there are exceptions to the rule that I'm not understanding (which is totally a possibility), we should work to clarify the documentation20:49
edmondswI always thought keystone just disregarded the api rules :)20:49
morganedmondsw: clearly =/20:49
edmondswedmondsw that's nothing to do with this change, though... I assert this change is in compliance with the rules20:49
morganftr, i didn't agree to nor think we should restrict correction of error/status code within the same class.20:49
morganbut the api standards for openstack says we do.20:50
* mordred waves to edmondsw and morgan20:50
edmondswwe could work to clarify the docs until we're blue in the face... those discussions are so much fun, and slow is an understatement20:50
lbragstadedmondsw: the rules state we need a new version if we move within the 400-499 class20:50
lbragstadall i'm doing is reading the docs20:51
edmondswmordred, I think you'd agree this change doesn't affect interop at all... https://review.openstack.org/#/c/482190/20:51
lbragstadhttp://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html#evaluating-api-changes20:51
* morgan put a -1 on the code.20:51
lbragstadmordred: o/20:51
mordredWELL - I agree with the sentiment that it doesn't - but in practice we have never published guidance that people should not be super-strict with things like 400 vs. 40320:51
morgani'll circle back up when either we have a change to the guidelines (a pending review with some +1/+2 and a "we are accepting this change"), or when we don't change the status code... OR when lbragstad is comfortable with the change.20:52
mordredso in the absence of having said that, we're in a position where we have to assume pople have coded to the specifics of the existing defacto api20:52
morganmordred: and the API-WG guidelines explicitly say a new version is needed for changing within a class of status codes20:53
mordredyup20:53
morganso, since we are following those, we would need a new version here.20:53
morgan*or* clarification on those guidelines20:53
mordredmorgan: that's why I agree with you - even though I think we COULD have decided on a more liberal policy many years ago that would have allowed such a thing wihtout a bump20:53
lbragstad=/20:53
morgan*or* an agreement that keystone doesn't care about the guidelines, whichc ase i wont bother looking at them for reviews.20:54
mordredbut we didn't - so changing it now would be moving the goal posts on someone we don't know with code we haven't seen20:54
morgan(i don't think that last one is a good plan)20:54
lbragstadthis is like the third discussion we've had about return codes for various APIs within a week20:54
morganmordred: ftr, i don't like this guideline.20:54
morganmordred: but, happy to enforce it as long as needed.20:55
morganedmondsw: ^20:55
lbragstadyeah - i don't see much wiggle room in enforcing it20:55
lbragstadwe either do or we don't and what happens if we don't20:56
*** harlowja has joined #openstack-keystone20:56
mordredmorgan: yah. same here. I also disagree with it - but they are the way we've decided to behave and I'd rather we all decide to change than have some projects behave differently20:57
lbragstadi'd agree with that20:57
mordredI mean- it might be time to make the argument that we need to document a return-code contract of a different strictness and figure out how to get to that point20:58
lbragstadeven thought i don't necessarily agree with keystone's behavior in this case and i think it should be fixed20:58
morgannow, if the guideline is changed or clarified in a way that makes this kind of change compatible, i'm 100% behind this change and fixing the behavior20:58
lbragstadmorgan: ++20:58
lbragstadme too - i completely agree20:58
lbragstadif we have the flexibility to fix it without a version - that's great20:58
morganbut... for now we can't change it based upon our interpretation (and confirmation of our interpretation by mordred) of the guidelines...which we agree to follow20:59
lbragstadotherwise we need to look at version in order to do this20:59
morganlbragstad: i think we should make keystone v420:59
morganftr20:59
lbragstadi do too20:59
morgan(and no, i'm not joking)20:59
lbragstadme either20:59
morganbut auth cannot/should not be changed with it.20:59
morganthat was the painful part of v2->v320:59
lbragstadyeah20:59
mordredI agree with that- especially once we get the version discovery out to everyone so that people are consuming the things that are there21:00
mordredbecause if auth didn't change, actually consuming a new api version is not hard when discovery works21:00
morganmordred: i still wnat to move auth to /auth21:01
*** lucasxu has quit IRC21:01
morgan(keep it where it is for v2/v3 but make /auth the *correct* way to auth w/ keystones going forward)21:01
morganthen we could do v4 easily.21:01
morgan*shrug*21:01
lbragstadmorgan: didn't you want to make it so you could specify the version or interpretation of auth in the request?21:02
mordredmorgan: I fully support that as long as we have a mechanism to discover a cloud supports the new good thing - and will happily help validate that whatever mechanism that is will not make people ragey21:02
mordredmorgan: ++21:02
morganmordred: i'd just do that on the discovery doc.21:02
morgan<<auth>>21:02
mordred++21:02
morganwhere if that exists it is explicitly the auth endpoint21:02
* morgan needs to finish the new yaml catalog21:02
morganit's mostly done21:02
bknudsonauth to keystone? Isn't that what facebook is for?21:03
morganjust need a couple methods and it's working21:03
morganbknudson: dns dude. all 100% dns21:03
morganbknudson: it's the MX record i want to use btw21:03
morganso you get priority on auth endpoints21:03
*** prometheanfire has joined #openstack-keystone21:03
morgan:P21:03
prometheanfireI can't find anything so don't know if it's in dev or not, but is U2F a thing that's being worked on or done (or not)?21:04
* prometheanfire waves at lbragstad 21:04
lbragstadprometheanfire: o/21:04
morganprometheanfire: not cuirrently being worked on21:04
morganit'd be something nice to have.21:05
morganif we can figure out how to do it sanely21:05
morganwith a rest API U2F would be very hard to do sanely21:05
lbragstadprometheanfire: we have a TOTP implementation for two-factor, but that's it21:05
prometheanfirek, thanks21:05
morganTOTP works21:05
prometheanfiretotp is a nice step21:05
prometheanfireI'll be sure to mention it21:05
* prometheanfire needs to read up on the u2f spec21:06
prometheanfireit requires signing things right?21:06
bknudsonneed u2f in curl21:06
prometheanfireheh21:08
lbragstadprometheanfire: yeah - it does21:09
openstackgerritKelly Hall proposed openstack/keystone master: WIP: Add project tags  https://review.openstack.org/47031721:09
lbragstadhttps://developers.yubico.com/U2F/Protocol_details/Overview.html21:09
prometheanfireguess that's why it's in gpg tokens21:10
*** thorst has quit IRC21:10
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/48448321:23
*** chlong has quit IRC21:26
*** prometheanfire has left #openstack-keystone21:31
openstackgerritMerged openstack/keystone master: Added new docs to admin section  https://review.openstack.org/48416521:33
*** rcernin has quit IRC21:33
*** dave-mccowan has joined #openstack-keystone21:34
openstackgerritMerged openstack/pycadf master: Switch from oslosphinx to openstackdocstheme  https://review.openstack.org/48392221:36
openstackgerritMerged openstack/pycadf master: Turn on warning-is-error for sphinx build  https://review.openstack.org/48394521:36
*** ducttape_ has quit IRC21:43
*** ducttape_ has joined #openstack-keystone21:45
*** ducttape_ has quit IRC21:46
*** ducttape_ has joined #openstack-keystone21:48
*** clarkb has joined #openstack-keystone21:54
clarkbhello keystoners, ran across http://logs.openstack.org/27/481227/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/7343f1b/logs/screen-g-api.txt.gz?level=WARNING#_Jul_14_06_17_19_629740 while digging into the uncategorized list from elastic-recheck. Looks like keystone returned a 500 error to glance which eventually bubbled up to a nova error in tempest21:55
clarkbI'm not finding much more info other than apache returns a 500 from keystone to glance then a 503 from glance to nova as expected21:55
clarkbany chance someone can look into that and find a root cause that maybe we can track with e-r?21:55
clarkblbragstad: ^21:55
lbragstadclarkb: interesting - i can try to dig into it21:57
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/48448322:03
*** edmondsw has quit IRC22:10
*** thorst has joined #openstack-keystone22:10
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/47013722:10
*** ducttap__ has joined #openstack-keystone22:10
*** ducttape_ has quit IRC22:14
*** thorst has quit IRC22:15
*** bknudson has quit IRC22:18
openstackgerritGage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/48445622:20
*** bknudson has joined #openstack-keystone22:23
*** bknudson has quit IRC22:23
*** edmondsw has joined #openstack-keystone22:26
openstackgerritGage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/48445622:28
*** edmondsw has quit IRC22:31
openstackgerritKelly Hall proposed openstack/keystone master: WIP: Add project tags  https://review.openstack.org/47031722:33
*** thorst has joined #openstack-keystone22:41
gagehugolbragstad should we add a reno for the db migrations?22:42
lbragstadgagehugo: for project tags?22:42
gagehugoyeah22:42
lbragstadgagehugo: i'd probably just add a single release note once everything is implemented22:42
lbragstadSomething short and sweet that just says "Hey, we support project tags now, find the api docs here'22:43
*** thorst has quit IRC22:43
lbragstadespecially since the addition of a project-tags table isn't something that should affect operators22:43
lbragstad(e.g. it doesn't use triggers or anything weird like that)22:43
gagehugolbragstad I wasn't sure if we were supposed to include anything about updating the DB specifically in it22:44
gagehugohttps://review.openstack.org/#/c/472396/22:44
lbragstadhttps://review.openstack.org/#/c/472396/13/releasenotes/notes/project-tags-1e72a6779d9d02c5.yaml looks good22:46
gagehugook22:47
openstackgerritMorgan Fainberg proposed openstack/keystone master: Add yaml-loaded filesystem catalog backend  https://review.openstack.org/48351422:52
morganlbragstad: ^ needs testing22:53
*** edmondsw has joined #openstack-keystone22:57
morganmordred: ^ fixing the templated catalog22:58
morganeandersson: ^ cc22:58
mordredmorgan: woot22:58
morganit needs tests but *should* work22:58
morganit natively renders a v3 catalog from the raw data instead of trying to convert22:58
eanderssonlooks good - will see if I can test it out soonTM22:58
morganand ... actually is a bit more comprehensive in how it builds a consistent catalog than the sql one22:59
* morgan would not be opposed to recommending the yaml one be the default choice 22:59
morganonce it is verified working22:59
*** edmondsw has quit IRC23:02
*** catintheroof has quit IRC23:07
openstackgerritGage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/48448323:09
*** dpar has quit IRC23:12
*** chlong has joined #openstack-keystone23:24
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Remove deprecated_since parameter for interface  https://review.openstack.org/48452823:24
openstackgerritGage Hugo proposed openstack/keystone-specs master: Update project-tags spec  https://review.openstack.org/48452923:25
mordredmorgan, cmurphy, lbragstad: https://review.openstack.org/484528 removes that deprecated_since param that gave cmurphy pause23:25
mordreddid it as a followup since the other patch is at the bottom of a stack23:26
mordredoh - she had a nit on a help string too23:27
openstackgerritMonty Taylor proposed openstack/keystoneauth master: Remove deprecated_since for interface and fix text  https://review.openstack.org/48452823:28
mordredk. fixed that oo23:28
cmurphymordred: while you're fixing things i think lbragstad had an issue with https://review.openstack.org/#/c/48274423:33
mordredcmurphy: ++ thanks- forgot that one23:35
openstackgerritNicolas Helgeson proposed openstack/keystone master: WIP: Add project tags  https://review.openstack.org/47031723:48
mordredcmurphy, lbragstad: I'll clean that up as part of one more followup I wanna get done tomorrow23:48
openstackgerritMorgan Fainberg proposed openstack/keystone master: Add yaml-loaded filesystem catalog backend  https://review.openstack.org/48351423:58

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