Wednesday, 2016-09-07

*** tqtran has quit IRC00:06
*** shaleh|away has quit IRC00:06
*** adrian_otto has quit IRC00:07
*** adrian_otto has joined #openstack-keystone00:08
*** adrian_otto has quit IRC00:09
*** richm has joined #openstack-keystone00:09
*** esp has quit IRC00:10
*** fangxu has quit IRC00:11
*** ravelar has joined #openstack-keystone00:15
*** ravelar has quit IRC00:22
*** roxanaghe has joined #openstack-keystone00:24
*** ddieterly has quit IRC00:25
*** bigjools has quit IRC00:28
*** roxanaghe has quit IRC00:28
*** bigjools has joined #openstack-keystone00:29
*** esp has joined #openstack-keystone00:32
*** topol has joined #openstack-keystone00:36
*** ChanServ sets mode: +v topol00:36
*** ddieterly has joined #openstack-keystone00:37
*** javis has quit IRC00:50
*** spzala has joined #openstack-keystone00:57
ayoungEmilienM, so I think we can run all of the setup scrupts for Fernet and for Credentials on the overcloud.  When these are run, they assume a keystone.conf file in /etc/keystone/keystone.conf, but I think we can pass in an alternative.  So we could make an "overcloud " directory and put all of the config files in there.00:57
ayoungmkdir -p /var/tmp/etc/keystone00:57
ayoungput a stub conf file in  /var/tmp/etc/keystone/keystone.conf or where ever and then00:57
ayoungkeystone_manage --config-dir  /var/tmp/etc/keystone  fernet-setup and00:58
EmilienMayoung: that is too complicated tbh00:59
ayoungEmilienM, and then we sync that whole directory down, chopping off  /var/tmp00:59
ayoungwell, and not the conf file00:59
ayoungmake sure the whole structure is in place for each of the nodes01:00
ayoungEmilienM, I don't want to have logic in puppet that might differ from what Keystone does to generate keyhs01:00
ayoungkeys01:00
EmilienMayoung: have you seen what I did?01:00
EmilienMit's all passing CI btw https://review.openstack.org/#/c/366400/01:00
ayoungEmilienM, you are looking to run on one node and then sync to the others, rigjht?01:00
ayoungWow01:00
ayoungYeah, I saw that one passed on recheck01:01
EmilienMsee the result http://logs.openstack.org/00/366400/1/check/gate-tripleo-ci-centos-7-nonha-multinode/2084b54/logs/subnode-2/etc/keystone/credential-keys/01:01
ayoungand there was a recheck on the follow on01:01
EmilienMthat's on the overcloud01:01
EmilienMwe have the 2 keys and everything works.01:01
ayoungEmilienM, if you are cranking, I won't hold up progress01:02
ayoungI wouldn;t have tackled it that way, but this is your domain, drive on01:02
EmilienMthe way I'm doing it 1) works 2) is secure 3) can easily be changed later in a different workflow01:03
EmilienMso i guess it's not a bad option01:03
EmilienMwe need to take in account the release schedule and this thing is really blocking us01:03
EmilienMagain, doing that at the end of the cycle makes me really sad01:03
ayoungEmilienM, those are really good points.01:04
EmilienMwhat concerns me is upgrade but I'm pretty sure my stuff will work in upgrade01:05
EmilienMor maybe not, I'll test it.01:05
ayoungEmilienM, it might be the wrong way to get stuff done, but Fernet will make many people happy01:07
EmilienMsomething we need to do in tripleo is implement a mechanism for key rotations01:07
EmilienMthe mechanism to generate keys doesn't worry me at all01:07
EmilienMit can be done by puppet or keystone manage I don't care at all01:07
EmilienMwhat we want is security here and rotation will be my next iteration on this thing.01:08
EmilienMayoung: I plan to add fernet keys to tripleo when my stuff is merged.01:08
EmilienMin the meantime find a way to do rotations01:08
ayoung+++++01:08
*** javis has joined #openstack-keystone01:12
*** wangqun has joined #openstack-keystone01:19
*** browne has quit IRC01:22
*** annp has joined #openstack-keystone01:23
*** Gorian has quit IRC01:26
*** Gorian has joined #openstack-keystone01:26
*** ddieterly has quit IRC01:36
*** davechen has joined #openstack-keystone01:36
*** roxanaghe has joined #openstack-keystone01:39
*** ddieterly has joined #openstack-keystone01:40
*** roxanaghe has quit IRC01:44
*** esp has quit IRC01:45
*** marekd2 has joined #openstack-keystone01:51
*** fangxu has joined #openstack-keystone01:55
*** EinstCrazy has joined #openstack-keystone01:55
*** marekd2 has quit IRC01:56
*** spzala has quit IRC01:57
*** spzala has joined #openstack-keystone01:57
openstackgerritMerged openstack/keystone: Emit log message for fernet tokens only  https://review.openstack.org/36498601:58
openstackgerritMerged openstack/keystone: Set default value for [saml]/idp_contact_surname  https://review.openstack.org/35616001:58
*** EinstCrazy has quit IRC01:58
*** fangxu has quit IRC02:01
*** spzala has quit IRC02:02
*** EinstCrazy has joined #openstack-keystone02:03
*** ddieterly has quit IRC02:06
*** esp has joined #openstack-keystone02:14
*** asettle has joined #openstack-keystone02:15
*** asettle has quit IRC02:20
*** spzala has joined #openstack-keystone02:35
*** spzala has quit IRC02:35
*** spzala has joined #openstack-keystone02:36
*** spzala has quit IRC02:36
*** spzala has joined #openstack-keystone02:36
*** spzala has quit IRC02:37
*** spzala has joined #openstack-keystone02:37
*** spzala has quit IRC02:37
*** spzala has joined #openstack-keystone02:38
*** esp has quit IRC02:41
*** spzala has quit IRC02:42
*** spzala has joined #openstack-keystone02:58
*** spzala has quit IRC03:13
*** akscram has quit IRC03:19
openstackgerritHa Van Tu proposed openstack/keystone: [api-ref] Stop supporting os-api-ref 1.0.0  https://review.openstack.org/36645903:20
*** akscram has joined #openstack-keystone03:20
*** namnh has joined #openstack-keystone03:23
*** roxanaghe has joined #openstack-keystone03:28
*** akscram has quit IRC03:29
*** akscram has joined #openstack-keystone03:30
namnhHi everyone. Keystone in Mitaka still does not support online schema migration feature yet. Is that right?03:31
stevemarnamnh: correct03:32
namnhI saw a patch set: https://review.openstack.org/#/c/245186/9/specs/mitaka/online-schema-migration.rst . But when I see Githup, I did not see: https://github.com/openstack/keystone-specs/tree/master/specs/keystone/mitaka03:32
*** roxanaghe has quit IRC03:32
*** sdake_ has joined #openstack-keystone03:32
namnhstevemar: thanks for your reply. It means Keystone does not support upgrading without downtime from Liberty to Mitaka yet.03:34
stevemarnamnh: correct03:34
*** sdake has quit IRC03:35
namnhstevemar: Oh. I see. So Does Keystone has plan to do it?03:35
stevemarnamnh: it should be supported when you go from mitaka to newton ;)03:36
stevemarlbragstad: dolphm credential_setup is now a required step in the install process correct?03:37
stevemarlbragstad: dolphm, or should be...03:37
stevemarlbragstad: dolphm we need to update the install guide03:38
namnhstevemar: :( So if I want to upgrade from L to M then there will be downtime as link: http://docs.openstack.org/developer/keystone/upgrading.html#upgrading-with-downtime . Is that right?03:39
stevemarnamnh: correct, if it helps, the outage window can be measured in minutes03:40
stevemarnamnh: see more notes here: https://review.openstack.org/#/c/360733/03:41
*** hoangcx has joined #openstack-keystone03:42
*** links has joined #openstack-keystone03:45
namnhstevemar: I got it. I will read your link. I am researching about how to upgrade Keystone from L to M. Next time, could I ask you ? :)03:46
stevemarnamnh: i don't really have much experience in actually running proper upgrades, your best bet would be posting the operator mailing list03:46
stevemarnamnh: others have posted there before about keystone upgrades: http://lists.openstack.org/pipermail/openstack-operators/2016-August/011371.html03:47
stevemarand another: http://lists.openstack.org/pipermail/openstack-operators/2016-June/010822.html03:48
namnhstevemar: I see :) Anyway thank you so much for your time :)03:48
stevemarnamnh: np!03:48
openstackgerritHa Van Tu proposed openstack/keystone: [api-ref] Stop supporting os-api-ref 1.0.0  https://review.openstack.org/36645903:51
openstackgerritMerged openstack/keystone: Correct link type  https://review.openstack.org/36581603:53
*** markvoelker has quit IRC03:54
*** Marcellin__ has quit IRC03:57
*** esp has joined #openstack-keystone03:59
*** rdo_ has quit IRC04:07
*** roxanaghe has joined #openstack-keystone04:19
*** roxanaghe has quit IRC04:22
*** roxanaghe has joined #openstack-keystone04:25
*** stevemar has quit IRC04:28
openstackgerritEric Brown proposed openstack/keystone: Fix up some doc nits  https://review.openstack.org/36648104:28
*** esp has quit IRC04:33
*** namnh has quit IRC04:42
*** namnh has joined #openstack-keystone04:42
*** markvoelker has joined #openstack-keystone04:55
*** markvoelker has quit IRC04:59
*** tonytan_brb has quit IRC05:09
*** jaosorior has joined #openstack-keystone05:12
*** openstackgerrit has quit IRC05:18
*** openstackgerrit has joined #openstack-keystone05:18
*** hoangcx has quit IRC05:20
*** roxanaghe has quit IRC05:27
*** EinstCrazy has quit IRC05:30
*** EinstCrazy has joined #openstack-keystone05:31
*** richm has quit IRC05:41
*** sdake_ is now known as sdake05:46
*** hoangcx has joined #openstack-keystone05:49
*** adriant has quit IRC05:51
*** joerch has joined #openstack-keystone05:59
bretonmorning, keystone06:00
*** stevemar has joined #openstack-keystone06:06
*** ChanServ sets mode: +o stevemar06:06
*** EinstCrazy has quit IRC06:06
*** EinstCrazy has joined #openstack-keystone06:10
*** tonytan4ever has joined #openstack-keystone06:10
*** stevemar has quit IRC06:11
*** tonytan4ever has quit IRC06:15
*** sdake has quit IRC06:18
openstackgerritMerged openstack/keystone: [api-ref] Stop supporting os-api-ref 1.0.0  https://review.openstack.org/36645906:20
openstackgerritBoris Bobrov proposed openstack/keystone: Make fetching all foreign keys in a join  https://review.openstack.org/34797206:29
bretonsomeone, wontfix https://bugs.launchpad.net/keystonemiddleware/+bug/1620919 please06:34
openstackLaunchpad bug 1620919 in keystonemiddleware "Missing options in keystonemiddleware.auth_token._opts:list_opts" [Undecided,New] - Assigned to qingzhou (qingzhhu)06:34
*** pcaruana has joined #openstack-keystone06:34
*** topol_ has joined #openstack-keystone06:41
*** ChanServ sets mode: +v topol_06:41
*** henrynash_ has joined #openstack-keystone06:42
*** stevemar has joined #openstack-keystone06:44
*** EinstCrazy has quit IRC06:54
*** markvoelker has joined #openstack-keystone06:56
*** topol has quit IRC06:57
*** asettle has joined #openstack-keystone07:00
*** markvoelker has quit IRC07:01
*** tesseract- has joined #openstack-keystone07:02
*** EinstCrazy has joined #openstack-keystone07:03
*** jpena|off is now known as jpena07:03
*** sdake has joined #openstack-keystone07:03
openstackgerritNguyen Phuong An proposed openstack/keystone: [api-ref] Remove parameters unused in keystone v2  https://review.openstack.org/36594707:16
aloganamnh: no, you can't update without a downtime07:17
namnhaloga: Hi aloga, yes you are right when we do this from L to M. But our expection is no downtime.07:22
namnhaloga: I think the deverlopers in Keystone are trying to do the "rolling-upgrade" feature.07:23
namnhaloga: :)07:24
aloganamnh: yes, indeed07:24
aloganamnh: I upgraded a couple of weeks ago, without significant problems07:25
alogaand just a short downtime window07:25
*** EinstCrazy has quit IRC07:27
*** EinstCrazy has joined #openstack-keystone07:36
*** woodster_ has quit IRC07:39
namnhaloga: Ohh. Good for you. What release did you upgrade?07:45
alogaL -> M07:45
*** tonytan4ever has joined #openstack-keystone07:47
namnhaloga: Thanks for your informatin. One more thing, Is your test in test enviroment or product?07:50
alogaproduction07:51
alogaalthough we have a test infrastructure, were we tested the upgrade first07:51
*** tonytan4ever has quit IRC07:52
*** asettle has quit IRC07:56
namnhaloga: wow. currently, we have a plan to upgrade Openstack from L to M. Next time, could I discuss this hot topic with you? and Congratulations :-)07:56
alogayes, sure, I will be glad to help07:56
*** topol_ is now known as topol07:57
namnhaloga: Thank you :)07:59
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
henrynashnamnh, aloga: yes, in Netwon we have rolling upgrade support, so M->N can be done that way08:01
namnhaloga: btw, Did you upgrade Glance project?08:01
*** henrynash has quit IRC08:01
aloganamnh: yes08:02
alogawe have upgraded everything since... ¿essex?08:02
*** asettle has joined #openstack-keystone08:02
*** EinstCrazy has quit IRC08:03
namnhaloga: Great! I does not still find a document about upgrading in Glance, and I don't see the rolling-upgrade feature in Glance. So do you have any information about how to do it?08:05
*** mvk has quit IRC08:07
*** ChanServ sets mode: +o stevemar08:07
*** stevemar_ has joined #openstack-keystone08:07
*** ChanServ sets mode: +o stevemar_08:07
*** mvk has joined #openstack-keystone08:08
aloganamnh: http://docs.openstack.org/releasenotes/glance/mitaka.html08:09
aloganamnh: the release notes usually contain notes about the upgrade process08:09
aloganamnh: glance has been a smooth upgrade for us every time we did an upgrad08:09
aloganamnh: with minimal donwtime as well08:10
openstackgerritDavanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c  https://review.openstack.org/31843508:10
aloganamnh: usually we don't care about minimal disruptions of the service, we're not a commercial provider08:10
*** stevemar_ has quit IRC08:12
*** EinstCrazy has joined #openstack-keystone08:12
namnhaloga: IMO, Glance has not still support rolling-upgrade yet. So the our work-follow is to stop Glance service -> upgrade Glance database -> upgrade source-code and install packages dependence -> start service.08:18
*** namnh has quit IRC08:19
*** annp has quit IRC08:19
*** namnh has joined #openstack-keystone08:19
*** annp has joined #openstack-keystone08:19
namnhaloga: Is that your work-follow during upgrading?08:19
aloganamnh: the one you described08:19
namnhaloga: I see. Do you use mutilple controllers? it means HA active-active for controller node.08:23
*** rdo_ has joined #openstack-keystone08:25
*** marekd2 has joined #openstack-keystone08:26
*** openstackgerrit has quit IRC08:34
*** openstackgerrit has joined #openstack-keystone08:34
*** EinstCra_ has joined #openstack-keystone08:34
*** EinstCrazy has quit IRC08:37
*** pnavarro has joined #openstack-keystone08:46
*** links has quit IRC08:53
*** EinstCra_ has quit IRC08:55
*** links has joined #openstack-keystone08:55
*** EinstCrazy has joined #openstack-keystone08:56
*** markvoelker has joined #openstack-keystone08:57
*** markvoelker has quit IRC09:01
*** code-R has joined #openstack-keystone09:02
*** code-R_ has joined #openstack-keystone09:05
*** code-R has quit IRC09:08
*** stevemar_ has joined #openstack-keystone09:08
*** ChanServ sets mode: +o stevemar_09:08
*** mvk has quit IRC09:12
*** stevemar_ has quit IRC09:13
bretonrderose: i think i figured out why https://review.openstack.org/347972 fails the test09:22
*** amakarov_away is now known as amakarov09:25
bretonrderose: it happens because in test_user_can_change_password_after_min_age field created_at is set to the same value. This causes password_ref return the wrong password here: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql_model.py#L8009:28
bretonrderose: it seems that the difference between `joined` and `subquery` is in order of equal objects09:28
bretonand i think it's kind of luck that the tests works now fine :p09:30
*** EinstCrazy has quit IRC09:37
*** EinstCrazy has joined #openstack-keystone09:39
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add return-request-id-to-caller function(v3)  https://review.openstack.org/26745609:40
openstackgerritHarini proposed openstack/keystone: EndpointPolicy driver doesn't inherit interface  https://review.openstack.org/35258609:40
*** mvk has joined #openstack-keystone09:41
*** sdake has quit IRC09:47
*** markvoelker has joined #openstack-keystone09:57
*** hoonetorg has quit IRC09:58
*** topol_ has joined #openstack-keystone09:59
*** ChanServ sets mode: +v topol_09:59
*** markvoelker has quit IRC10:02
*** davechen has left #openstack-keystone10:02
*** topol_ has quit IRC10:04
*** richm has joined #openstack-keystone10:08
*** annp has quit IRC10:10
*** hoangcx has quit IRC10:13
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add return-request-id-to-caller function(v3/contrib)  https://review.openstack.org/26800310:20
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add release notes for return-request-id-to-caller  https://review.openstack.org/27664410:27
*** namnh has quit IRC10:29
*** swamireddy1 has joined #openstack-keystone10:37
swamireddy1Hi10:37
swamireddy1what is default supported version in L release Keystone ?10:37
swamireddy1is it V2 or V3?10:38
*** dgonzalez has quit IRC10:45
bretonswamireddy1: both10:55
*** dikonoor has joined #openstack-keystone10:55
bretonswamireddy1: in L both version are supported; there is no such thing as default API version. But we recommend using v3.10:55
*** dgonzalez has joined #openstack-keystone10:57
*** GB21 has joined #openstack-keystone11:05
*** dikonoor has quit IRC11:05
*** ddieterly has joined #openstack-keystone11:06
*** wangqun has quit IRC11:08
*** stevemar_ has joined #openstack-keystone11:09
*** ChanServ sets mode: +o stevemar_11:09
*** stevemar_ has quit IRC11:13
*** dikonoor has joined #openstack-keystone11:15
*** ddieterly has quit IRC11:28
*** swamireddy2 has joined #openstack-keystone11:34
*** swamireddy1 has quit IRC11:35
swamireddy2breton: Thanks...so with L release, is V3 fully supported as v2.011:35
*** tonytan4ever has joined #openstack-keystone11:49
*** jpena is now known as jpena|lunch11:49
*** ddieterly has joined #openstack-keystone11:51
*** tonytan4ever has quit IRC11:53
bretonswamireddy2: yes11:54
*** Marcellin__ has joined #openstack-keystone11:56
*** eandersson has joined #openstack-keystone11:57
*** markvoelker has joined #openstack-keystone11:58
*** zeus has quit IRC12:00
*** topol_ has joined #openstack-keystone12:01
*** ChanServ sets mode: +v topol_12:01
*** markvoelker has quit IRC12:03
*** links has quit IRC12:04
*** marekd2 has quit IRC12:05
*** chlong has joined #openstack-keystone12:05
*** pauloewerton has joined #openstack-keystone12:06
*** topol_ has quit IRC12:06
*** stevemar_ has joined #openstack-keystone12:10
*** ChanServ sets mode: +o stevemar_12:10
*** stevemar_ has quit IRC12:14
*** links has joined #openstack-keystone12:16
*** EinstCrazy has quit IRC12:21
*** ddieterly has quit IRC12:22
*** hoonetorg has joined #openstack-keystone12:23
dikonoordolphm: stevemar: hi..GM ..Can fernet tokens be revoked?12:23
dolphmdikonoor: yes12:23
dikonoordolphm: how would that work ? Could you point me to the code that does that..Couldn't find under https://github.com/openstack/keystone/tree/master/keystone/token/providers/fernet12:24
dolphmdikonoor: revocation events12:24
cnfI keep getting things like " Invalid service catalog service: compute" in horizon12:25
cnfi'm guessing i did something wrong in keystone12:25
dikonoordolphm: would you be able to point me to where I can check the code for revocation events. I don't see anything about revocation events in any of the fernet token related documentation or articles12:26
bretondikonoor: keystone/revoke/12:29
dolphmdikonoor: they're implemented in the keystone.revoke package12:29
*** dolphm sets mode: +v rderose12:30
dikonoorthanks breton: dolphm: I will take a look12:30
*** edmondsw has joined #openstack-keystone12:31
*** markvoelker has joined #openstack-keystone12:32
*** woodster_ has joined #openstack-keystone12:42
*** jpena|lunch is now known as jpena12:48
*** zeus has joined #openstack-keystone12:49
*** jaosorior has quit IRC12:49
*** zeus is now known as Guest4940812:50
*** jaosorior has joined #openstack-keystone12:50
*** Guest49408 is now known as zeus`12:51
cnfhmm, i don't understand where this is coming from :/12:52
*** ddieterly has joined #openstack-keystone12:52
*** zeus` is now known as zeus12:52
*** zeus has quit IRC12:52
*** zeus has joined #openstack-keystone12:52
*** swamireddy2 has quit IRC12:55
*** GB21 has quit IRC12:56
*** ddieterly has quit IRC12:57
dstanekcnf: are you seeing errors in the keystone log?13:10
*** stevemar_ has joined #openstack-keystone13:10
*** ChanServ sets mode: +o stevemar_13:10
*** links has quit IRC13:12
cnfdstanek i see 2016-09-07 13:12:16.295 26 INFO eventlet.wsgi.server [req-77656ff2-2b34-43ec-9b54-6c909611e6ab - - - - -] 192.168.13.153 - - [07/Sep/2016 13:12:16] "POST /v3/ tokens HTTP/1.1" 404 342 0.153065,13:12
cnfbut i don;t know why i'd get a 404 on it13:12
dstanekthere appears to be a space in there13:12
*** asettle has quit IRC13:12
bknudsonthere's no /v3/tokens. in v3 it's /v3/auth/tokens.13:12
dstanekshould be /v3/tokens13:12
bknudsonv2.0 has /v2.0/tokens13:12
cnfthere isn't13:13
dstanekbknudson: oh, good call13:13
cnfthat's a paste from a newline on my consokle13:13
*** asettle has joined #openstack-keystone13:13
cnfbknudson ok... where is this configured?13:13
dstanekcnf: bknudson is right. different urls between v2 and v3 for auth13:13
bknudsonevery user of keystone has to be told to use the right endpoint and version13:13
cnfand where do I do this?13:14
bknudsonin the application. It depends on the application.13:14
*** stevemar_ has quit IRC13:15
cnfi'm guessing it's nova13:15
*** topol_ has joined #openstack-keystone13:16
*** ChanServ sets mode: +v topol_13:16
dstanekcnf: do you get the useragent in the apache log? that may be a hint13:16
cnfno apache log, that's just keystone log13:16
dstanekcnf: you don't run behind a webserver at all?13:17
cnfatm, no13:17
rderosebreton: is that the only test that fails?13:17
*** su_zhang has joined #openstack-keystone13:21
bretonrderose: yes13:25
bretonrderose: i am going to propose a patch soon13:25
rderosebreton: okay, cool13:25
rderosebreton: but I thought there were more tests failing, temptest13:26
*** tonytan4ever has joined #openstack-keystone13:26
rderosemin password age was merged recently, before this patch13:26
rderoseright?13:26
bretonrderose: oh, those... yeah, i have not yet figured that out.13:27
rderosebreton: okay13:27
amakarovrderose, o/ Thank you for picking up the CI issue 1620764. Have you looked into?13:27
cnfhmz, i have no idea how to fix this :/13:27
rderoseamakarov: not yet, got caught up in something yesterday.  will do today though.13:28
bretonrderose: tempest actually failed for unrelated reason13:28
amakarovrderose, cool!13:28
*** javis has quit IRC13:29
rderosebreton: cool, I'll look for your new patch then13:29
cnfit's either nova, or horizon13:29
cnfit's the only thing i'm using, atm13:30
dstanekcnf: did you check their configs?13:30
cnfdstanek i did, but i don't quite know what to check13:30
cnfi just followed the13:31
cnfubuntu install guide13:31
dstanekcnf: easiest thing to do is grep for the incorrect URL13:31
cnfgrep for what?13:31
*** wangqun has joined #openstack-keystone13:31
cnfi just have things like auth_uri = http://keystone:5000 in nova.conf13:32
cnfjust like the install document said13:32
cnfthere is no version associated with that13:33
dstanekcnf: i was thinking you may have '/v3' somewhere13:34
cnfno, there is no /v3 anywhere, except in keystone endpoints13:34
cnfhmm, ok, maybe auth_version= works...13:36
cnfin nova.conf13:36
cnfdstanek ok, yeah, that seems to be the missing bit13:37
cnffound it on some blog13:37
cnfbknudson thanks for pointing out the api version discrepancy13:38
cnfdstanek and thanks for the help13:38
bknudsonis this in the authtoken section of nova.conf? or somewhere else?13:38
cnfopenstack isnt very good with debugging and error messages :/13:38
cnfbknudson yes, in [keystone_authtoken]13:39
bknudsonpeople need to open bugs when there are problems and maybe someone will pick it up13:39
bknudsonI thought we enhanced authtoken middleware to do version discovery... not sure when that was.13:39
bknudsonso you shouldn't have to set the version13:39
cnfbknudson i agree, but my problem atm is i'm figuratively drowning, i don't know what is a bug, and what is me doing weird stuff13:39
cnfbknudson yeah, i don't need to even set a value13:40
cnfjust auth_version=, nothing after the =13:40
bknudsonoh, so it was set to v2?13:40
cnfno, it wasn't set anywhere i can see13:40
cnfa grep in /etc/nova for auth_version only show the one I _added_13:41
cnfit wasn't there a few minutes ago13:41
dstanekbknudson: yeah, at least in the modern lib it doesn't need an explicit version set13:42
cnfdstanek so following the install document on ubuntu doesn't give you the modern lib?13:43
bknudsonyou can compare your version of keystonemiddleware with the current version on pypi13:45
bknudsonhttps://pypi.python.org/pypi/keystonemiddleware/4.9.013:45
bknudsonpypi says we only get 69 downloads of keystonemiddleware per month!13:46
bknudsonalso, apparently the formatting of the README is off13:46
dstanekcnf: no idea. it depends on what it tells you to do. i've never used that install guide13:48
cnfkeystonemiddleware-4.4.1.egg-info it seems13:49
cnfso a bit behind13:49
*** ddieterly has joined #openstack-keystone13:49
bknudsonreleased 2016-05-23, so it's not that old... authtoken shouldn't require the version to be set at all.13:50
*** ezpz has joined #openstack-keystone13:50
bknudsonmaybe there's something else in nova that's using those config options13:50
*** ddieterly has quit IRC13:51
*** ddieterly has joined #openstack-keystone13:51
*** michauds has joined #openstack-keystone13:52
dstanekcnf: are you able to narrow down if it's nova or horizon? horizon does have a setting for identity versino13:53
openstackgerritBoris Bobrov proposed openstack/keystone: Keep the order of passwords in tests  https://review.openstack.org/36676613:54
bretonrderose: ^ the patch13:54
rderosebreton: nice fix, that should work13:55
rderosebreton: thanks13:55
*** rcernin has joined #openstack-keystone13:57
*** wangqun has quit IRC14:01
*** spedione|AWAY is now known as spedione14:03
*** ayoung has quit IRC14:03
*** rodrigods has quit IRC14:06
*** rodrigods has joined #openstack-keystone14:06
samueldmqmorning keystone14:09
*** adrian_otto has joined #openstack-keystone14:11
cnfdstanek it was nova14:11
cnfdstanek horizon just does very freaky stuff if some stuff in the backend fails14:11
cnfsuch as kick you out, and not let you log back in, unless you edit the url14:12
cnfvery confusing, that14:12
cnfbknudson i'm happy to help you find what, but my openstack / keystone knowledge is rather limited14:12
*** javis has joined #openstack-keystone14:13
*** GB21 has joined #openstack-keystone14:14
*** SamYaple_ has joined #openstack-keystone14:15
dstanekcnf: that is so strange. i have not seen that before14:15
*** BjoernT has joined #openstack-keystone14:16
cnfdstanek :P14:17
*** adrian_otto has quit IRC14:20
*** asettle has quit IRC14:20
*** eandersson has quit IRC14:20
*** pnavarro has quit IRC14:20
*** Gorian has quit IRC14:20
*** SamYaple has quit IRC14:20
*** stian_ has quit IRC14:20
*** darrenc has quit IRC14:20
*** anteaya has quit IRC14:20
*** jidar has quit IRC14:20
*** su_zhang has quit IRC14:20
*** su_zhang has joined #openstack-keystone14:21
cnfright, that one line has fixed a whole bunch of weird things in horizon14:22
*** henrynash_ is now known as henrynash14:25
stevemaro/14:25
*** su_zhang has quit IRC14:26
*** ravelar has joined #openstack-keystone14:30
*** chrisshattuck has joined #openstack-keystone14:30
*** EinstCrazy has joined #openstack-keystone14:30
*** chrisshattuck has quit IRC14:31
*** adrian_otto has joined #openstack-keystone14:33
*** woodburn has quit IRC14:34
*** dikonoor has quit IRC14:35
*** adrian_otto has quit IRC14:36
*** GB21 has quit IRC14:39
*** eandersson has joined #openstack-keystone14:39
*** asettle has joined #openstack-keystone14:42
*** pnavarro has joined #openstack-keystone14:42
*** Gorian has joined #openstack-keystone14:42
*** stian_ has joined #openstack-keystone14:42
*** darrenc has joined #openstack-keystone14:42
*** anteaya has joined #openstack-keystone14:42
*** jidar has joined #openstack-keystone14:42
*** hoonetorg has quit IRC14:43
*** woodburn has joined #openstack-keystone14:43
*** Gorian has quit IRC14:44
dstanekcnf: getting closer14:45
dstanekstevemar!14:46
*** ayoung has joined #openstack-keystone14:48
*** ChanServ sets mode: +v ayoung14:48
*** joerch has quit IRC14:48
*** adrian_otto has joined #openstack-keystone14:49
*** chrisshattuck has joined #openstack-keystone14:49
*** Gorian has joined #openstack-keystone14:50
*** adrian_otto1 has joined #openstack-keystone14:52
*** adrian_otto has quit IRC14:55
*** hoonetorg has joined #openstack-keystone14:57
*** spzala has joined #openstack-keystone14:58
*** EinstCrazy has quit IRC15:01
*** sdake has joined #openstack-keystone15:03
*** sdake has quit IRC15:08
*** topol_ has quit IRC15:08
stevemardstanek: ahoy matey15:13
cnfhow do  list role members?15:22
*** sdake has joined #openstack-keystone15:24
dstanekbreton: where you running into problems for the password create_at date in tests?15:27
*** EinstCrazy has joined #openstack-keystone15:27
dstanekstevemar: last day before vacation right?15:27
*** gagehugo has joined #openstack-keystone15:28
bretondstanek: i ran into the problem while poking patch 34797215:32
openstackgerritBoris Bobrov proposed openstack/keystone: Keep the order of passwords in tests  https://review.openstack.org/36676615:32
*** stevemar_ has joined #openstack-keystone15:33
*** ChanServ sets mode: +o stevemar_15:33
dstanekbreton: cool, thanks. that's all i was wondering15:34
openstackgerritBoris Bobrov proposed openstack/keystone: Keep the order of passwords in tests  https://review.openstack.org/36676615:34
*** stevemar_ has quit IRC15:34
samueldmqcnf: role members ?15:34
samueldmqcnf: you can list role assignments and see what users are assigned what roles15:34
openstackgerritBoris Bobrov proposed openstack/keystone: Make fetching all foreign keys in a join  https://review.openstack.org/34797215:34
stevemardstanek: yeah, for you!15:35
stevemardstanek: i'm not due for a vacation for a while15:35
*** ddieterly is now known as ddieterly[away]15:35
bretoni hoped our bot to post a link to the review15:35
bretonpatch 34797215:35
samueldmqcnf: try GET /v3/role_assignments. there are also a bunch of filters available, you may want to filter based on a role with ?role_id=<role_id>15:35
bretonno? :(15:35
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683115:35
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683215:35
dstanekstevemar: oh, i thought you said that you were off Thurs/Fri this week15:36
lbragstaddolphm ayoung ^15:36
lbragstadEmilienM if you're around ^15:36
dolphmlbragstad: awesome15:36
EmilienMlbragstad: I am15:36
EmilienMlbragstad: let me look15:36
*** ravelar has quit IRC15:36
ayounglbragstad, nice.  We'll keep that effort going, but probably should run past the TC whether this is the right call...and past Security group.  I would think a mailing list posting is due.15:37
lbragstaddolphm still working though one piece and that is the doctor check to see if anything is encrypted with the null key15:37
ayoungEmilienM, I'd rather we got your changes in15:37
bretonlbragstad: will the check be dropped right after stable/newton cut?15:37
bretonlbragstad: *the null keys15:37
breton*will the null keys be dropped right after stable/newton cut?15:38
*** david-lyle_ has joined #openstack-keystone15:38
*** ddieterly[away] is now known as ddieterly15:38
EmilienMlbragstad: sounds good. My stuff in tripleo is about to merge in a few hours15:38
*** david-lyle_ has quit IRC15:38
*** hoonetorg has quit IRC15:38
lbragstadbreton well - we could but we could also issue a deprecate warning15:38
lbragstadEmilienM cool - you guys should be good to go then?15:38
lbragstaddeprecation warning*15:38
EmilienMlbragstad: probably15:38
*** su_zhang has joined #openstack-keystone15:39
bretonwait, i don't understand it15:40
bretondoes the null key always get appended?15:40
lbragstadbreton nope - it's only appended for the credential use key15:41
lbragstadusecase(15:41
lbragstad*15:41
* lbragstad clearly can't type15:41
*** chlong has quit IRC15:41
bretonlbragstad: if i create real keys for the credentials, will the null key still work?15:41
lbragstadbreton if you create real keys, the real keys will be used to encrypt and decrypt things15:42
lbragstadthe null key will still be appended to the keys list, but never used for anything15:42
*** hoonetorg has joined #openstack-keystone15:42
dolphmlbragstad: except decryption, in the event there are any credentials still encrypted with it15:43
dolphmbreton: ^15:43
*** adrian_otto1 has quit IRC15:43
lbragstaddolphm breton yeah - that will allow operators to migrate *off* the null key15:43
bknudsonwhy append the keys to the list if they're not going to be used?15:44
bretonbknudson: that's the same thing i don't understand15:44
*** adrian_otto has joined #openstack-keystone15:44
lbragstadotherwise we will be inspecting all the credential key_hash values just to see if any of them need to use the null key15:46
lbragstadwhich doesn't seem very performant15:46
lbragstadjust for populating a list of keys15:46
bretonso... the credentials are ecnrypted with key = keys[0], right?15:48
lbragstadbreton yes - https://github.com/pyca/cryptography/blob/master/src/cryptography/fernet.py#L13515:48
lbragstadbut that's an implementation detail of cryptography15:48
bretonok, i got it then.15:49
bknudsonnew credentials are encrypted with key[0]. The old ones might be any of the old keys.15:49
lbragstadup to one old key15:50
lbragstadwith keystone-manage credential_rotate - we don't allow operators to do more than one rotation without a migration15:50
bknudsoncredential_rotate could re-encrypt creds using null keys15:51
lbragstadwhy's that?15:52
bknudsonso that they wouldn't be used anymore15:52
lbragstadcredential_migrate is the step that does the re-encryption15:52
bknudsonok. I'm not too worried about it.15:53
bretonwhy are there 2 steps -- setup and migrate?15:56
lbragstadbreton there are actually three steps - setup, migrate, and rotate15:58
lbragstadsetup should only be used once to bootstrap a new repository15:59
lbragstadmigrate is used to check all credentials in the backend and make sure they are all encrypted with the current primary key15:59
lbragstadand rotate verifies all the credentials are encrypted with the current primary key before introducing a new primary key16:00
*** pcaruana has quit IRC16:01
*** su_zhang has quit IRC16:02
lbragstaddolphm thoughts on pulling the credential_api into doctor?16:02
*** su_zhang has joined #openstack-keystone16:02
*** EinstCrazy has quit IRC16:05
*** su_zhang_ has joined #openstack-keystone16:06
*** su_zhang has quit IRC16:07
*** EinstCrazy has joined #openstack-keystone16:07
*** su_zhang_ has quit IRC16:07
*** su_zhang has joined #openstack-keystone16:08
*** su_zhang has quit IRC16:08
*** su_zhang has joined #openstack-keystone16:08
*** su_zhang has quit IRC16:09
*** tesseract- has quit IRC16:09
*** su_zhang has joined #openstack-keystone16:09
*** su_zhang has quit IRC16:11
*** tqtran has joined #openstack-keystone16:11
*** chrisshattuck has quit IRC16:11
*** su_zhang has joined #openstack-keystone16:11
*** roxanaghe has joined #openstack-keystone16:12
*** chrisshattuck has joined #openstack-keystone16:14
*** su_zhang has quit IRC16:16
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685416:16
lbragstadsamueldmq responded - https://review.openstack.org/#/c/366831/116:16
*** EinstCrazy has quit IRC16:16
*** gyee_ has joined #openstack-keystone16:17
*** ravelar has joined #openstack-keystone16:17
*** code-R_ has quit IRC16:19
*** tqtran has quit IRC16:20
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683216:20
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685416:20
samueldmqlbragstad: replied16:24
lbragstadsamueldmq per your comment - make what valid16:26
lbragstad?16:26
samueldmqlbragstad: are we planning to support another backend for the keys ?16:28
lbragstadthere is a spec for it, yes16:29
samueldmqlbragstad: btw another comment in https://review.openstack.org/#/c/366832 (see if it makes sense)16:29
samueldmqlbragstad: ok, so I was just arguing that we put things inthe comment that will still be valid after we do it16:29
bretonsamueldmq: mnikolaenko works on it, i am going to discuss it with you at the summit.16:29
samueldmqlbragstad: so the implementer of the new backend won't need to find that doc and fix it16:29
*** esp has joined #openstack-keystone16:30
samueldmqlbragstad: I am talking about the python doc (first discussion there)16:31
samueldmqlbragstad: I am fine either way, not hard on that, just thought it would make more sense16:31
*** ddieterly is now known as ddieterly[away]16:32
*** jaosorior has quit IRC16:33
*** gus has quit IRC16:33
lbragstadsamueldmq so is your concern that when we implement pluggable encryption backends this will be missed?16:33
lbragstadsamueldmq responded - https://review.openstack.org/#/c/366832/216:34
*** ayoung has quit IRC16:35
*** ddieterly[away] is now known as ddieterly16:35
samueldmqlbragstad: ok, migrate from the null key to a proper key repo16:35
lbragstadsamueldmq yep16:35
samueldmqlbragstad: I was associating that with the db migraiton16:35
lbragstadsamueldmq makes sense16:36
*** ayoung has joined #openstack-keystone16:36
*** ChanServ sets mode: +v ayoung16:36
samueldmqlbragstad: the original migration adding columns etc, I mean16:36
samueldmqlbragstad: because the data will still be migrated (re-encrypted with new creds), right?16:36
lbragstadsamueldmq the data migration during `keystone-manage db_sync --migrate` will encrypt all the credentials, yes16:37
samueldmqlbragstad: KK16:38
samueldmqthanks16:38
ayounglbragstad, essentially, you have forced Tripleo to support Fernet, which, while painful, is a major accomplishment.16:38
lbragstad...16:38
lbragstadyou're welcome?16:38
ayounglbragstad, thank you16:39
ayounglbragstad, that said,  I think the null key approach will be kind to all of the other distros out there16:39
*** LamT_ has joined #openstack-keystone16:40
*** sigmavirus is now known as irvirus16:40
ayoungas I said, we should ask the world at large (operators) whether this is something they will or won't want.  Having a Null key might be a compliance liability, so lets confirm before we commit16:40
*** irvirus is now known as sigmavirus16:40
lbragstadwell - it's sole purpose is to easy upgrades... if deployers want to make sure they are in compliance with whatever security requirements they need, they should be reading release notes and upgrading with a proper key_repository16:41
lbragstadease*16:41
*** gus has joined #openstack-keystone16:42
lbragstaddstanek ping16:47
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683216:51
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685416:51
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683116:51
dstaneklbragstad: hiya16:51
lbragstaddstanek quick python 3 question16:52
lbragstadi think i figured it out - but curious if you would look at what I came up with16:52
lbragstadline 34 here - https://review.openstack.org/#/c/366831/1..2/keystone/common/fernet_utils.py,unified16:53
lbragstadwas failing python34 tests without the encode()16:53
lbragstadi tested it locally on python27 and python34 - does it make sense?16:53
*** ddieterly is now known as ddieterly[away]16:53
*** GB21 has joined #openstack-keystone16:54
*** ravelar has quit IRC16:55
dstaneklbragstad: yeah i think so. b64 requires bytes and chr(0) returns text16:56
*** topol_ has joined #openstack-keystone16:56
*** ChanServ sets mode: +v topol_16:56
lbragstaddstanek yeah - that's what it looked like it was failing on16:56
dstaneklbragstad: you could have just done b'\x00' * 3216:56
lbragstaddstanek oh - true16:56
*** slberger has joined #openstack-keystone16:58
*** pnavarro has quit IRC16:59
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683217:02
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685417:02
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683117:02
*** ddieterly[away] is now known as ddieterly17:02
*** gyee_ has quit IRC17:03
openstackgerritMerged openstack/keystone: [api-ref] Correcting parameter's type  https://review.openstack.org/36554917:04
lbragstaddolphm does this still make sense to do now that we should never hit MultiFernet errors? https://bugs.launchpad.net/keystone/+bug/1619758/comments/417:05
openstackLaunchpad bug 1619758 in OpenStack Identity (keystone) "Credential Encryption breaks deployments without Fernet" [Undecided,In progress] - Assigned to Lance Bragstad (lbragstad)17:05
*** ddieterly is now known as ddieterly[away]17:06
bretonhow do i run a test from MySQLOpportunisticIdentityDriverTestCase?17:07
lbragstadbreton you have to bootstrap your mysql database with a specific openstack user17:07
lbragstadbreton something like - GRANT ALL PRIVILEGES ON *.* TO 'openstack_citest' @'%' identified by 'openstack_citest' WITH GRANT OPTION;17:08
lbragstadthe tests somehow hook into that and if that user is present, the mysql tests will be run...17:09
lbragstadsame thing with postgres17:09
bretonlbragstad: awesome, thank you17:12
dstaneklbragstad: breton: yes. the project config has a good example17:12
lbragstadbreton no problem17:12
*** gyee_ has joined #openstack-keystone17:12
*** gyee_ has joined #openstack-keystone17:13
bretoncould you please run keystone.tests.unit.identity.backends.test_sql.MySQLOpportunisticIdentityDriverTestCase.test_change_password on your localhosts?17:13
dstanekbreton: http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/macros.yaml#n87117:13
*** links has joined #openstack-keystone17:15
bretonit fails for me on master17:17
*** jpena is now known as jpena|away17:19
*** mvk has quit IRC17:21
openstackgerritMerged openstack/keystone: Fix up some doc nits  https://review.openstack.org/36648117:22
*** fangxu has joined #openstack-keystone17:23
*** ayoung has quit IRC17:27
*** asettle has quit IRC17:28
*** links has quit IRC17:29
bretonsoooo, it fails on my localhost, but succeeds in a virtual machine17:31
*** Marcellin__ has quit IRC17:37
dstaneklbragstad: should the releasenote in support_encrypted_credentials_at_rest-93dcb67b3508e91a.yaml be update to say a credential repo *should* be created and mention the null key?17:37
dstaneklbragstad: also do we need to reach out to install guides and let them know about this change?17:38
lbragstaddstanek yeah - we do17:38
lbragstaddstanek  we documented that stuff here - https://etherpad.openstack.org/p/keystone-credential-encryption-null-key17:38
lbragstadit's essentially a list of todos17:38
dstaneklbragstad: kk, let me know if you need any help17:39
lbragstaddstanek thanks for the reviews - did you see my last comment on https://review.openstack.org/#/c/366832/417:39
*** harlowja has quit IRC17:46
dstaneklbragstad: way ahead of you. trying to catch up on reviews a bit today17:47
*** harlowja has joined #openstack-keystone17:49
openstackgerritSteve Martinelli proposed openstack/keystone: New notes on advanced upgrade/fallback for cluster  https://review.openstack.org/36073317:49
*** su_zhang has joined #openstack-keystone17:51
*** code-R has joined #openstack-keystone17:55
dstaneklbragstad: also your commit messages are always too wide17:55
*** code-R_ has joined #openstack-keystone17:56
lbragstaddstanek do you have a vim trick that does that for you?17:57
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683217:58
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685417:58
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683117:58
dstaneklbragstad: yes, let me find it17:59
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683217:59
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685417:59
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683117:59
*** code-R has quit IRC18:00
lbragstaddstanek samueldmq all comments addressed ^18:00
*** code-R_ has quit IRC18:02
dstaneklbragstad: actually i think it's all in fugitive. i used to have a simple ftplugin that i wrote, but it looks like i got rid of it18:06
*** gagehugo has quit IRC18:12
*** code-R has joined #openstack-keystone18:14
*** code-R has quit IRC18:14
*** code-R has joined #openstack-keystone18:15
amakarovcolleagues, looks like we have some weird timezone issue18:15
bretonyep, with passwords' created_at18:15
*** chrisshattuck has quit IRC18:16
stevemarrderose: amakarov whats up with https://bugs.launchpad.net/keystone/+bug/1620764 ?18:17
openstackLaunchpad bug 1620764 in OpenStack Identity (keystone) "migration test fails on table addition" [Undecided,New] - Assigned to Ron De Rose (ronald-de-rose)18:17
openstackgerritSean Perry proposed openstack/keystone: Project domain must match role domain for assignment  https://review.openstack.org/36517718:17
rderosestevemar: not sure yet, been stuck in meetings all morning. planning to dig into this, this afternoon.18:18
stevemarrderose: coolio18:18
amakarovstevemar, either I'm doing something wrong or table don't gets created in migration tests18:18
samueldmqlbragstad: just an import to be removed there18:19
samueldmqlbragstad: other than that the chain looks good to me18:19
amakarovstevemar, I've just moved delegation model table creation to new migration repo and adjusted tests accordingly18:19
*** ddieterly[away] is now known as ddieterly18:26
openstackgerritEric Brown proposed openstack/keystone: More nit doc fixes  https://review.openstack.org/36690018:28
*** ravelar has joined #openstack-keystone18:29
*** code-R_ has joined #openstack-keystone18:32
*** ravelar has quit IRC18:34
*** code-R has quit IRC18:35
*** ddieterly is now known as ddieterly[away]18:35
openstackgerritLance Bragstad proposed openstack/keystone: Log warning if null key is used for encryption  https://review.openstack.org/36683218:39
openstackgerritLance Bragstad proposed openstack/keystone: Add docs for the null key  https://review.openstack.org/36685418:39
openstackgerritLance Bragstad proposed openstack/keystone: Introduce null key for credential encryption  https://review.openstack.org/36683118:39
bretonhttps://bugs.launchpad.net/keystone/+bug/1621200 here is a fun bug18:39
openstackLaunchpad bug 1621200 in OpenStack Identity (keystone) "MySQLOpportunisticIdentityDriverTestCase.test_change_password fails in UTC+N timezone" [Undecided,New]18:39
*** ayoung has joined #openstack-keystone18:39
*** ChanServ sets mode: +v ayoung18:39
*** ddieterly[away] is now known as ddieterly18:41
*** su_zhang has quit IRC18:42
lbragstaddstanek samueldmq addressed - thanks for all the reviews ^18:42
openstackgerritSean Perry proposed openstack/keystone: Project domain must match role domain for assignment  https://review.openstack.org/36517718:44
dstaneklbragstad: np18:47
lbragstaddstanek do you recall if your caching work had an impact on https://review.openstack.org/#/c/314854/ ?18:48
*** code-R_ has quit IRC18:48
*** tonytan4ever has quit IRC18:56
*** amakarov is now known as amakarov_away18:57
*** sdake has quit IRC19:02
*** javis has quit IRC19:04
*** clenimar has quit IRC19:10
*** sdake has joined #openstack-keystone19:10
bretonlbragstad: probably yes19:12
bretonlbragstad: catalog was affected19:12
bretonlbragstad: and now is fixed19:12
*** su_zhang has joined #openstack-keystone19:13
*** joerch has joined #openstack-keystone19:14
harlowjaayoung yt19:16
harlowjacome in adam19:16
harlowjalol19:16
ayoungthe number you have reached is no longer in service19:16
*** su_zhang has quit IRC19:18
harlowjaha19:18
harlowjasoooooo19:18
harlowjacan i volunteer u for a k8s + keystone-free-for-all kind of intro/questions and ...19:18
harlowjawink wink19:18
harlowjahttps://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/19:18
harlowjajust was in that meeting19:18
harlowjaand it basically boils down to (woah u guys are starting to make things like what keystone has, but well not enough people that know keystone, woah, let's talk about what we maybe think keystone does)19:19
harlowjathen its like 'woah' maybe we should do this in a different meeting19:19
harlowjaand woah maybe someone can get a keystone expert to do a q&a and such19:19
harlowja(and here we are)19:19
harlowjalol19:19
openstackgerritMerged openstack/keystone: Keep the order of passwords in tests  https://review.openstack.org/36676619:20
*** rcernin has quit IRC19:21
*** ddieterly is now known as ddieterly[away]19:21
*** ravelar has joined #openstack-keystone19:21
breton>  The Zoom Client for Linux allows you to start or join Zoom meetings on Ubuntu, Fedora, and many other Linux distributions.19:29
*** mvk has joined #openstack-keystone19:29
bretonwhy couldn't they use something usual?19:30
bretonharlowja: i'd love to participate there19:30
bretonand i am actually hoping to contribute to k8s a little later19:31
*** tqtran has joined #openstack-keystone19:32
*** fangxu has quit IRC19:37
harlowjabreton lol19:37
harlowjaif someone wants to (adam or other) do a little intro, deep-dive, q&a i'd be very grateful to that person19:37
harlowjaif that someone is interested in k8s thats cool to19:38
harlowja(answer not needed immediatly btw)19:39
notmorganayoung: If you think you have reached this recording in error, hang up and try your call again19:41
harlowjalol19:41
notmorganharlowja: oh hai19:41
harlowjahey yo19:41
notmorganwhen do you want someone to Q&A?19:42
notmorganif it can be next week I can volunteer19:42
notmorganthis week i am sans laptop (lost power cable) and ~1000mi from home19:42
harlowjai think that can be fine/work19:42
notmorgandriving back to PDX on friday19:42
harlowjawth, u only allowed to bike back19:42
harlowjalol19:42
notmorganharlowja: are you in the bay area? or you in CO? or some other location?19:43
harlowjai am all around u19:43
harlowjalol19:43
ayoungharlowja, Keystone sucks.  Avoid it at all costs.19:43
harlowjai am in the sky, in the earth19:43
notmorganeh, socal -> PDX = long bike ride19:43
ayoungThe problem, of course, is that you cannot avoid it.19:43
notmorganbut it's actually a nice drive if you avoid I519:43
harlowjai'm in bay area19:43
harlowja:-P19:43
ayoungharlowja, I had a slew of specs that were designed just to solve this problem.  They all died in committee19:44
notmorganharlowja: i'll ping you, maybe grab a drink or some such saturday when I'm there.19:44
notmorganayoung: you can blame me for all of the fails :P19:44
harlowjahmmmm, might be outside climbing on saturday :-/19:44
harlowjamove that to sunday, lol19:44
notmorganharlowja: damn and I don't have my gear with me.19:44
*** ddieterly[away] is now known as ddieterly19:44
ayoungnotmorgan, I think it was jamielennox|away that killed them, actually19:44
notmorganactually... i just need to get new climbing gear (hey ayoung, that "just" was "just" for you ;)19:45
ayoungthe idea of externalizing the mapping, getting rid of the need to got to keystone to get a token first, but still doing the mapping and rolle look up19:45
ayoungnotmorgan, always happy to talk about climbing gear19:45
notmorganayoung: i think i killed part of it but not permanently, more of a "fix X first"19:45
notmorgani am almost tempted to swing up to yosemite on my way back north19:45
ayoungnotmorgan, you might have wounded it, but working on Tripleo and getting priorities from elsewhere really killed it19:45
notmorganexcept how croweded it will be19:46
ayoungnotmorgan, got to Yose19:46
ayoungthat just means yhou are more likely to find a climbing party19:46
notmorganand that i don;t have a camp ground and gear.19:46
harlowjau can do some hiking i guess19:46
ayoungperfect time of year to climb19:46
ayoungharness and shoes are all you need19:46
notmorganyeah i need to buyt new ones19:46
openstackgerritRichard Avelar proposed openstack/keystone: POC sql query revoked tokens  https://review.openstack.org/35937119:46
ayoungthere is a rock shop in Yose19:46
notmorganmy shoes stiching and rubber came apart.19:46
ayoungprices are not too jacked up19:46
notmorganeh, i think i want to get back out and in shape again19:47
harlowjaya, come on guys19:47
notmorgani'll prob just hit a climbing gym in PDX when i get home19:47
harlowjastop being bums with kids and stuff19:47
harlowjalol19:47
* notmorgan has no kids19:47
harlowjaplanet granite is in PDX now19:47
ayoungyou don't need to be in climbing shape to do the ROyal Arches.  Just cardio19:47
* notmorgan has medical issues that *finally* are getting dealt with today.19:47
harlowja(planet granite == bay area gym)19:47
ayoungharlowja, I got up Moby Grape this summer, at least19:47
harlowjacools19:48
notmorganayoung: i want to go do snake dike19:48
notmorganayoung: http://www.supertopo.com/rock-climbing/Yosemite-Valley-Half-Dome-Snake-Dike19:48
ayoungnotmorgan, also do not need to be in shape for that.  Nor do you need much gear19:48
harlowjaya, i'll do that with u if can get a solid time :-P19:48
ayoung5 quickdraws IIRC19:48
harlowjai got more than 519:48
harlowjalol19:48
ayoung2 for each anchor, and one for the bolt in the middle19:48
notmorganayoung: i think it was 7 quick draws last time my buddy went but he over-did the protection19:48
notmorganbut basically yeah19:49
*** chrisshattuck has joined #openstack-keystone19:49
*** kfox1111 has joined #openstack-keystone19:49
harlowjaya, i'll do it19:49
ayoungspeaking of Crowded....count the nuimber of parties  http://younglogic.com/jessandadam/Pictures/2001-2002/halfdome/tn/p1010007.jpg.html19:49
harlowjacan drag some others along probably to19:49
notmorganayoung: my goal is to go do SE Butress on Cathedral Peak one day, Snake Dike the next, then some hiking up mist trail19:50
ayoungAll good climbs19:50
ayoungSE Butt significantly harder19:50
notmorganup and back + summit of cathedral peak, camp in Tuolumne19:50
notmorganyeah.19:50
harlowjaso perhaps breton notmorgan next wed, like 11am PST?19:50
notmorgan5.9 ish iirc19:50
ayoungoh...that one19:50
ayoungI was thinkg East Butt of Higher Cathedral19:50
notmorganwell, you can continue up19:51
ayoungSE of Catherdral Peak is a highway19:51
ayounglots of people, soloists19:51
ayoungonkly issue therei s the altitude19:51
notmorganoh wait19:51
notmorganno, the 5.9 one not SE19:51
ayoungEichorn, on the other end, much more fun climb19:51
kfox1111harlowja: I've been trying to kind of educate the k8s folks on keystone for a while now.19:51
notmorganSE is 5.619:51
harlowjaayoung if u intersted also, u more than welcome to join ;)19:51
harlowjakfox1111 no doubt19:51
notmorganharlowja: yeah wednesday works for me19:51
harlowjai applaud your efforts kfox111119:51
ayounghttp://younglogic.com/jessandadam/Pictures/2003/EichornPinnacle/19:51
harlowjaand give u a hug19:51
harlowjaha19:51
ayoungharlowja, I want the Nose.19:51
harlowjaya, me to19:52
kfox1111thx. :)19:52
ayounghttp://adam.younglogic.com/2011/06/fear/19:52
harlowjaayoung maybe if we actually plan far enough ahead, we could do it19:52
notmorganayoung: South Face - thats the one19:52
notmorganayoung: 5.819:52
harlowjai don't currently know enough people that could do the nose :-P19:52
harlowja(or try to do the nose)19:52
notmorganharlowja: i wish i was in shape for the nose19:52
harlowja(or have the gear to try to do the nose)19:52
notmorganor ... ANY route on el cap19:52
kfox1111notmorgan: some back story...19:52
harlowjaya, kfox1111 is the k8s historian for this stuff :)19:53
ayoungharlowja, Just logisitics19:53
*** tonytan4ever has joined #openstack-keystone19:53
harlowjaya, logistics also19:53
kfox1111they don't have multitenancy really yet and they are starting to push ahead to get there.19:53
ayoungyou really don't have to climb that hard, just know that you are going to aid the tough stuff19:53
ayounghauling the pig19:53
harlowjaman, aiding19:53
harlowjajeez, killing me man, lol19:53
ayoungok...back the K8s19:53
kfox1111but not having done it before, they are still really thinking in terms of one authentication plugin that's as simple as 'username/password' and dabling a bit with 'groups'.19:53
notmorgankfox1111: ah19:53
ayounghad someone internally bugging me about K8s and Keystone yesterday19:53
notmorgankfox1111: oh yeah don't back yourself into that corner to start :P19:54
notmorgana little bit more rich of a architecture opening future development is a must19:54
kfox1111then implemented an rbac system on top of that, maping group to api roles, so kind of like the oslo policy stuff.19:54
notmorganouch. so basically didn't look at keystone history :(19:54
ayoungkfox1111, Keystone can give you the roles.19:54
kfox1111notmorgan: yeah. they are making all the same mistakes again as they don't have experience with it yet. I was hoping to head that off.19:54
ayoungNeed the policy engine, but K8s got that already19:54
notmorganyeah lets help them not do that19:55
kfox1111yup. what I kind of want is,19:55
kfox1111kube to accept keystone tokens,19:55
kfox1111(scoped)19:55
ayoungkfox1111, nah19:55
ayoungjust auth right to K8s19:55
ayoungdo the mapping and role lookup from k8s19:55
kfox1111and then use their rbac system as a oslo policy replacement mapping keystone roles to api calls.19:55
ayoungexactly19:55
notmorgankfox1111: that sounds like 100% the right approach19:56
kfox1111then the kubernetes system can be integrated with the  openstack dashboard and heat easily.19:56
notmorganclearly needs some details filled in19:56
notmorganbut solid19:56
ayoungkfox1111, if you want, the user can pass userid/p[assword to k8s, k8s gets a token, ignores it, and just uses the token request response19:56
notmorganand avoids the ick of openstack AuthZ.19:56
harlowjaya, it gets more complicated cause there are things idk about k8s and there visions for RBAC also19:56
notmorganwithout being incompat19:56
notmorgani like it19:56
ayoungneed to get the roles into Keystone.  Use implied roles to map K8s roles to Admin/member19:57
kfox1111ayoung: thats what they did.19:57
kfox1111but on a multitenant cloud like ours, that lets everyone in the whole organization do anything. :/19:57
kfox1111We already have projects/roles in keystone and just want to reuse them.19:57
notmorgankfox1111: thats a reasonable expectation19:58
notmorganand should be doable19:58
kfox1111I want to basically do an OS_TOKEN=$(openstack token get);19:58
kfox1111then# kubectl get pod19:58
notmorganayoung: expect some code drops from me next week.19:58
kfox1111for my users.19:59
notmorganayoung: i was going to do it this week but lacking a power cable for mylaptop and unable to just "buy" one at like bestbuy...19:59
kfox1111or better, kubectl does thet token get if ones not there.19:59
kfox1111so kubectl would work like any other openstack command.19:59
kfox1111notmorgan: so, the moral of the story, they are thinking totally from the k8s is an island kind of thing,20:00
notmorgankfox1111: i would be inclined to start with a simple wrapper POC that grabs the token20:00
ayoungkfox1111, so the thing keystone gives you is a link between the k8s and openstack view of auth.  Not sure that makes sense for most users.  There are a couple use cases where it makes sense to integrate them, but even there I would be less than thrilled20:00
kfox1111and we're looking for a k8s is a proper openstack service thing.20:00
notmorgankfox1111: before baking in any other magic that should be based on OCC20:00
lbragstadsweet - I'll dig for those bug numbers20:00
ayoungdidn't they have a project for that?20:00
ayoungkuryr or soemthing?20:00
notmorgankfox1111: but do it in stages and build it up20:00
notmorganlbragstad: oh hai20:00
ayoungNo, not that...20:00
notmorganayoung: yeah it isn;t that20:01
kfox1111occ?20:01
notmorgankfox1111: os-client-config?20:01
ayoungMagnum20:01
kfox1111oh. yeah.20:01
ayoungits Beautiful!20:01
notmorgankfox1111: it has all the shade logic in it.20:01
notmorgankfox1111: which if you're doing "get me a token"... use it if in python20:01
notmorganoh please use it20:01
ayounghttp://cdn.quotesgram.com/small/98/10/1625414547-Zoolander-Magnum.png20:01
lbragstadnotmorgan o/20:01
kfox1111notmorgan: fyi: https://github.com/kubernetes/kubernetes/pull/2539120:01
kfox1111I actually got all the server bits working. but its kind of stuck deciding how to map openstack constructs to k8s ones.20:02
kfox1111part of the problem is the two projets use similar terms very differently.20:02
kfox1111for us, role is just a string.20:02
kfox1111for them, its a complicated rbac construct.20:02
ayoungkfox1111, so, in most cases, k8s is separate from OpenStack20:02
notmorganayoung: The man has only one look for Christ's sake! Blue Steel, Ferrari, Le Tigre? They're the same face! Doesn't anyone notice this?! I feel like I'm taking crazy pills.20:03
ayoungit is an app that runs on top of it20:03
kfox1111ayoung: only so far. ;)20:03
kfox1111not the way I want to deplyu it. ;)20:03
kfox1111I want to replace nova with it. ;)20:03
notmorgankfox1111: oh interesting20:03
ayoungkfox1111, are you going to use a container to deploy a virtual machine?20:03
lbragstaddstanek samueldmq mind doing follow ups on https://review.openstack.org/#/c/366831/ ?20:03
kfox1111or at least have a seperate nova pool and k8s pool for my users.20:03
lbragstadsince that's the first patch in the chain20:03
notmorgankfox1111: if you don't need multi-tenancy, raw k8s is ok20:03
kfox1111ayoung: kolla-kubernetes. :)20:03
*** gyee_ has quit IRC20:04
notmorganotheriwse you might need the bay (magnum parlance) model20:04
dstaneklbragstad: nope, it's on my list. just going through things in gertty order20:04
*** openstackgerrit has quit IRC20:04
lbragstaddstanek thanks20:04
*** openstackgerrit has joined #openstack-keystone20:04
kfox1111yeah, a bay is a heavy handed way to provide simulated multitenancy.20:04
* lbragstad cranks 'The Chain' by fleetwood mac20:04
*** BjoernT has quit IRC20:04
notmorgankfox1111: it's not that heavy20:04
kfox1111k8s is working on native multitenancy.20:04
ayounglbragstad, listening to the Billy Joel discography in chronologic order myself20:05
kfox1111notmorgan: heavy in that two tenants don't share vm's with kube on them.20:05
lbragstadayoung +220:05
notmorgankfox1111: it's about 2% overhead ftr. but it fills the gap until native multitenancy20:05
kfox1111multitenancy across a single bare metal cloud would be much more efficient.20:05
ayoungRootbeer Rag just came on20:05
*** spzala has quit IRC20:05
kfox1111notmorgan: not talking about cpu overhead, more memory utilizatoin.20:05
notmorgankfox1111: even less overhead there with a minimal OS.20:06
*** spzala has joined #openstack-keystone20:06
kfox1111the extra vm layers tend to consume lots of extra memory, meaning you cant pack as much.20:06
notmorgankfox1111: but it takes some careful crafting20:06
kfox1111yeah.20:06
notmorgankfox1111: i've seen ~1% overhead on memory20:06
notmorganbut it needs to be a good image20:06
notmorgannot "stock centos"20:06
notmorganor some such20:06
kfox1111anyway, the k8s folks are working on proper multitenancy, and this is part of it.20:06
* kfox1111 nods20:06
notmorganfair enough20:06
kfox1111plus, magnum integration.20:07
notmorgani'm curious how it's going to play at the kernel level bvecause that isthe big concern in containers and multitenancy20:07
notmorganless about the API20:07
kfox1111the deployed by magnum k8s cluster should be able to use the existing keystone and restrict access to just the tenant that deployed it.20:07
* notmorgan nods.20:07
kfox1111then the user doesn't have to deal with a whole nother authz/authn system.20:07
notmorgani think we can come up with a way to bridge them20:07
bknudsonwhen we were in boston for the meetup billy joel was having a concert at fenway20:07
kfox1111notmorgan: part of that is how much you trust your tenants. :)20:07
notmorganthe key is really coming down to unpacking the token.20:07
kfox1111public cloud, not so much.20:08
notmorgankfox1111: zero trust of any user of any api20:08
notmorgankfox1111: even in private clouds.20:08
kfox1111when you can fire users that do something horible, thats a different level of isolation.20:08
notmorgankfox1111: architect for security, saves headaches down the line20:08
kfox1111agreed.20:08
notmorganbut i also *might* be in the minority overall20:08
kfox1111but the risks with containers are, it *should* be safe, but there may be bugs...20:08
kfox1111same was true of vm's, but *should* be a little more isolated, so maybe safer....20:09
*** scarlisle has quit IRC20:09
kfox1111Its not for me to decide if container multitenancy is right for a given org over vm isolation.20:09
kfox1111its probably ok for some and not others.20:09
kfox1111I know they are also working on node level isolation.20:10
*** spzala has quit IRC20:10
kfox1111sharing a single kube control plane, but land different tenants on different pools of nodes.20:10
kfox1111that might be a good middleground.20:10
kfox1111oh. meeting time. gtg. bbiab20:11
ayoungkfox1111, can you throw me the link for the k8s review?20:19
ayounghttps://github.com/kubernetes/kubernetes/pull/2539120:20
ayoungFOUND IT20:20
ayoungkfox1111, liggett grabbed me yesterday to talk it through20:20
ayounglets see if we can get him here...20:21
ayoungkfox1111, I assured him you and harlowja actually knew enough about Keystone to be dangerous20:23
*** su_zhang has joined #openstack-keystone20:23
harlowjalol20:23
ayoungso, there were 3 use cases20:23
ayoung1 was "kubernetes inside a project"20:23
* harlowja reading backlog20:23
ayoung2 was "kerbernetes across multiple related projects"20:24
ayoungand 3 was "kubernetes as a service"20:24
ayoungand by that last, I mean that a kube instance could talk to VMs in multiple projects, where there was no relationship between the projects20:24
ayoungkubernetes inisde a proejct can be, I hope, completely divided from Keystone for most people20:25
harlowjai may or may not have put to much commentary on that PR, lol20:25
harlowjaayoung i hope so also20:25
ayoungit as 2 that is interesting...using Hierarchical multitenancy in Keystone to deal with a Kube instance that spanned multiple porjects20:25
ayoungharlowja, so...I tend to look at things from an Enterprise perspective, as opposed to the RAXers here who look at hosted or puiblic cloud.  From my customer cases, it is almost all users in AD or LDAP20:26
harlowjaright, that's my use-case currently20:26
ayoungso, if Kubernetes can do LDAP, and maintain the equivalent of role assignments itself20:26
ayoungyou don't link Kube and Keystone20:27
ayoungthe real need to link is where workflow needs a common view of things20:27
harlowjathats an option, yes, perhaps the best one (though it sucks in that u have roles in some place, roles in another, disjoint views on RBAC)20:27
ayoungbut even then, you can have Kube talk direct to LDAP for Auth20:27
harlowjaright20:28
ayoungbut then Kube roles and Keystone roles have no relationship20:28
ayoungso, assuming you use Keystone to manage roles, what you need to do is to be able to get an LDAP user, and figure out what Keystojne calls her, and then get her role assignments20:28
ayoungfetching a token implies that the user passed the PW to Kube20:28
*** pauloewerton has quit IRC20:29
ayoungwhich is normal, and also horribly wrong20:29
ayoungso, let's say the you run Kube behind mod_auth_gssapi and use Kerberos to auth to it20:29
harlowjak20:30
harlowjai'm with u20:30
harlowjathen that solves the auth is different, but uses a similar/same backend as keystone20:32
harlowjaso likely a unified thing say providing a view on both would just have 2 tokens then20:32
ayoungso if you do Kerberos, the thing you want is to get the mapping20:33
ayoungthen you could use Keystone to manage the role assignments for both OPenstack and Kube20:33
ayoungyou could also to S4U2 proxy and have Kuber request a token for the user20:33
harlowjawoah20:34
harlowjais that a new U2 song?20:34
harlowjalol20:34
harlowjaso in theory it seems ok, this is where it gets into details though that i can't quite figure out20:35
harlowjalike where is k8s trying to go in terms of RBAC20:35
harlowjaare they dead-set on (make ours?)20:35
ayoungwhen you get a token, use that to set roles.20:36
kfox1111back.20:36
ayoungOtherwise, let Kubernetes dictate roles20:37
*** BjoernT has joined #openstack-keystone20:37
kfox1111I think kube roles should be treated like oslo.policy rules.20:37
openstackgerritMerged openstack/keystone: More nit doc fixes  https://review.openstack.org/36690020:37
kfox1111then I can use keystone roles on my users/projects and map those roles to api permissions.20:37
ayoungkfox1111, please keep a civil tongue in your mouth20:37
kfox1111ayoung: sorry. :)20:38
ayoungHeh20:38
ayoungnah, I think I agree with what you are saying20:38
harlowjaoslo.policy is the best20:38
harlowjahaha20:38
ayoungKube should use the Keystone roles as the input.  Using Im,plied roles, you could convert "_member_" to "kubernetes_editor" or whatever it isi20:39
harlowja(i have to say that)20:39
kfox1111exactly. :)20:39
ayoungkfox1111, I just would not push for some sort of mapping engine...Keystone already has one, and just use it20:40
*** asettle has joined #openstack-keystone20:40
bretonharlowja: next wed 11am PST sounds good20:40
ayoungharlowja, I havea blog post on s4u2, but I think I know a better one to send to you if you care.  It lets one kerberized service get a service ticket for another one on behalf of a user20:41
harlowjaayoung sure will read if u send it :)20:41
ayoungso if a user goes to Kuber, and Kube needs to talk to keystone, Kube can (automatically) get a ticket to do so20:41
*** BjoernT has quit IRC20:41
ayoungharlowja, is this from the Architect in our group https://ssimo.org/blog/id_011.html20:41
openstackgerritDolph Mathews proposed openstack/keystone: Update sample keystone.conf for Newton  https://review.openstack.org/36695820:41
kfox1111ayoung: agreed. what I mean by mapping is,20:42
stevemardolphm: +++20:42
kfox1111how do we expose the keystone project/role information in a way the k8s rbac system can use it.20:42
kfox1111thats all.20:42
kfox1111their current belief is to expose it through a k8s group.20:42
harlowjaayoung u the architect man20:42
kfox1111I'm not sure that fits well.20:42
harlowjalol20:42
ayoungharlowja, hardly.  That would be simo20:43
harlowja:-P20:43
*** michauds has quit IRC20:43
lbragstadsamueldmq you were really familiar with the caching stuff20:45
harlowjakfox1111 so for my own knowledge, whats a k8s group20:45
harlowjacould probably ask some internal folks20:45
lbragstadsamueldmq do you remember what the impact of those patches on making fernet default?20:45
harlowjanamespace, group, user20:45
ayoungharlowja, I wanted external APIs to be able to lookup mappings and roles without actually handing out tokens.  That is what notmorgan and I were bantering about earlier20:45
harlowjais a group like a project, lol20:45
*** GB21 has quit IRC20:46
samueldmqlbragstad: you refering to dstanek's cache fix?20:46
lbragstadsamueldmq yeah - i thought that would have had an impact on making fernet default (?)20:46
kfox1111harlowja: their vision of auth is very basic.20:46
kfox1111so username = something like an ldap username. group = something like an ldap group.20:47
kfox1111just a string that is tagged onto some number of users.20:47
harlowjak20:47
samueldmqlbragstad: well, I was hoping that was going to fix the issues with caching thete20:47
samueldmqThere20:47
lbragstadsamueldmq now that the credential encryption work is wrapping up i'm revisiting make fernet default things20:47
samueldmqBut from my tests it doesn't lok to be the case20:47
kfox1111user='kfox', groups=['pnnl_employees', 'admin']20:47
lbragstadsamueldmq oh - really?20:47
harlowjakfox1111 right tag like20:48
samueldmqTempest keeps failing unless you disable revocation cache20:48
lbragstadhuh20:48
kfox1111thats all they currently have to work with. :/20:48
samueldmqlbragstad: yeah your change to make it default should've be passing on masted20:48
samueldmqMaster20:48
lbragstadsamueldmq that was being worked with https://review.openstack.org/#/c/345688/ ?20:48
samueldmqIf that had fixed the issue20:48
samueldmqlbragstad: Yes, that'd pass on máster if the issue was only the cache invalidation across processes20:49
openstackgerritLance Bragstad proposed openstack/keystone: WIP: Switch fernet to be the default token provider.  https://review.openstack.org/34568820:50
kfox1111btw, can the openstack cli and horizon do federated logins yet?20:52
kfox1111last I heard, it still was a show stopper. :/20:52
*** jaugustine has left #openstack-keystone20:52
david-lylekfox1111: Horizon had federated login since Liberty or Mitaka? unless you're talking about k2k, then no20:53
kfox1111yeah. k2k.20:53
kfox1111:/20:53
david-lylethere's a patch that hasn't landed20:54
kfox1111I really want to use k2k for scaling reasons. each region would get its own keystone, and then have a master keystone.20:54
* david-lyle recites the famous openstack verse20:54
harlowjakfox1111 interseting (sorry in and out of this conversation as i multitask)20:54
kfox1111:/20:54
lbragstadsamueldmq do you know if we have a bug open for documenting the issues with revocation event caching.20:54
lbragstad?20:54
kfox1111david-lyle: yeah. I've been watching it but haven't seen movement in a long long time. :/20:54
kfox1111was hoping I missed it somehow.20:54
samueldmqlbragstad: not site. I thoughts you had open one at that time20:55
*** shaleh has joined #openstack-keystone20:55
ayoungkfox1111, no you don't20:55
ayoungyou don't want K2K20:55
samueldmqlbragstad: I will check once I get to my PC, talking from mobile phone right now20:55
kfox1111why not?20:55
ayoungwhat you want is an external IdP and keystone only doing role assignments20:56
lbragstadsamueldmq cool, thanks... i'm digging right now, too20:56
ayoungand probably Fernet so the Keystones don't have to talk to each other20:56
kfox1111ayoung: kind of... a keystone being the idp though is something easier for me to deal with then setting up/managing another idp.20:56
ayoungkfox1111, AHAHAHAHAHAHA20:56
ayoungNo20:56
ayoungKeystone is not an IdP20:57
ayoungit is a delegation server20:57
samueldmqlbragstad: nice20:57
kfox1111ayoung: potato patato. doesn't change what I really want to use it for. :)20:57
ayoungkfox1111, that should not be laughter20:57
ayoungthat should be read as me screaming20:57
kfox1111I want ad to provide the authen. I want a central keystone for managing tenants,20:57
kfox1111and federated keystones per region for scaling.20:58
ayoungYep20:58
kfox1111I don't care what you call that. :)20:58
ayoungbut you don't need K2K for that20:58
*** javis has joined #openstack-keystone20:58
kfox1111hmm.. then how would you do that?20:58
ayoungJust either have independent Keystones for each region20:58
kfox1111how do you maintain tenancy across independent keystones then?20:59
*** iurygregory_ has joined #openstack-keystone20:59
ayoungMapping from the AD groups20:59
ayoungand if you need a tighter sync than that, use DB replication instead20:59
kfox1111I want to be able to login once, and have that unscoped token work for all the regions.20:59
kfox1111and I don't nessisarily trust the admins on each of the regions.21:00
kfox1111so federation covers that case.21:00
ayoungbug 96869621:00
openstackbug 968696 in Glance ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Sharat Sharma (sharat-sharma)21:00
kfox1111ayoung: exactly.21:00
kfox1111adminness would be per region, per keystone.21:00
kfox1111but tenantness can be maintaned at the root keystone in the tree.21:01
ayoungkfox1111, I'm thinking what you want is more like this:21:01
kfox1111that one I trust. it can be hardened more then the other keystones.21:01
ayoungcentral Keystone that takes all writes.  Distributed Keystones for reads21:01
ayoungreplicate from central to remote21:01
ayoungand...21:01
ayoungsomething more21:02
ayoungthe central keystone should not honor tokens from the remote21:02
kfox1111you'd need some way to ensure the read only keystones couldn't issue tokens that had privs you didn't want them to have.21:02
ayoungmaybe the central one uses a different set of Fernet keys?21:02
openstackgerritRon De Rose proposed openstack/keystone: [WIP] POC Validate adding new table doesn't break tests (do not review)  https://review.openstack.org/36697421:02
kfox1111could work, but I don't think the code is there today. :/21:02
ayoungkfox1111, actually, that would work today21:03
kfox1111you'd have to create some kind of cross keystone fernet key trusts.21:03
ayoungeach of the remote keystones gets a different MySQL user, one that has read only access21:03
ayoungor, read write access to their replicated DB, but no backflow21:03
ayoungdon't sync the keys between the keystones21:03
kfox1111how would stuff like heat trusts work then?21:04
ayoungnone of the keystones honor keys issued by the others21:04
kfox1111yeah, maybe read write local might cover it...21:04
ayoungtrust need to be made in the central Database21:04
kfox1111though you could get into weird sync issues...21:04
ayoungor...21:04
kfox1111heat would need an admin cred.21:04
*** fangxu has joined #openstack-keystone21:04
kfox1111which breaks the whole reason to split. :/21:04
ayoungsince trusts is its own table space, you could have each keystone have their own set of tables for those21:04
ayoungits ok, admin would only be good on its own keystone21:05
kfox1111hmm... could be..21:05
kfox1111but would have a problem if you tried to use one trust in another region... but that may be ok.21:05
lbragstadsamueldmq you tested https://review.openstack.org/#/c/345688/ by turning off revocation caching and it worked - right?21:05
kfox1111it may be possible to pull it apart and order it that way. it really feels like its relying on some delicate internals to make work though.21:06
kfox1111it would be ok if keystone provided that as a feature.21:06
ayoungkfox1111, you would have to either do trusts only centralized, or only per region.21:06
kfox1111but I'd be reluctant to try it myself without that kind of garantee.21:06
ayoungWell....21:06
samueldmqlbragstad: Yes sir21:06
ayoungor you could do centralized, and then replicate out to the regions,21:06
lbragstadhumm21:06
ayoungso anytjhing centralized would be good cluster wide, but anything written in the regions would only be valid in that region21:07
kfox1111yeah, that might work better. but again, trusts may be a problem.21:07
ayoungthis could actually be quite cool21:07
kfox1111ah. yeah.21:07
kfox1111k2k_lite? :)21:07
ayoungeach region "inherits" the keystone from central, and then layers its own data on top21:07
ayoungnah21:07
kfox1111yeah. that would be cool.21:07
openstackgerritDoug Hellmann proposed openstack/python-keystoneclient: standardize release note page ordering  https://review.openstack.org/36698221:08
ayoungkfox1111, so, one shortcoming of Fernet is that the central Keystone could not issue tokens that would be valid across the regions, but that is, I think, OK21:08
kfox1111it may be easy to write a check that if it fails the local keystone check, pushes back to the central keystone.21:09
*** marst has joined #openstack-keystone21:09
kfox1111though one of my hopes for the k2k thing was it would convert to a local keystone token, and then all the api requests never would have to go all the way back to the central keystone,21:10
lbragstadsamueldmq so far i'm not seeing a bug for the revocation caching stuff... i wonder if ravelar knows?21:10
kfox1111impoving central keystone performance.21:10
marstHello. How do I start keystone service after devstack system reboot? There's no more /opt/stack/keystone/bin/keystone-all. Found this: http://openstack.10931.n7.nabble.com/devstack-How-to-start-all-OpenStack-services-after-restarting-system-td117156.html but it doesn't start keystone.21:13
marstSorry if this is wrong place to ask. Appreciate any help.21:13
*** BjoernT has joined #openstack-keystone21:19
*** edmondsw has quit IRC21:19
*** adrian_otto has quit IRC21:21
bretonmarst: it should be started21:21
bretonmarst: if not, you probably need to restart apache2 and uwsgi21:21
breton(not sure if it's uwsgi though by default)21:22
marstbreton: I rebooted devstack system and run "screen -c stack-screen". I can see nova services up and running, but not keystone.21:23
bretonmarst: why do you think that keystone is not running?21:23
bretonmarst: try saying "curl localhost:5000"21:24
marstcurl http://10.11.12.2:35357/v3/auth/tokens21:25
marstcurl: (7) Failed connect to 10.11.12.2:35357; Connection refused21:25
marst[stack@controller devstack]$ ps -ef | grep keys21:26
marstroot      3128  2916  0 Sep06 pts/2    00:00:00 sudo tail -f /var/log/httpd/keystone.log21:26
marstroot      3157  2923  0 Sep06 pts/3    00:00:00 sudo tail -f /var/log/httpd/keystone_access.log21:26
marstroot      3199  3128  0 Sep06 pts/2    00:00:00 tail -f /var/log/httpd/keystone.log21:26
marstroot      3201  3157  0 Sep06 pts/3    00:00:00 tail -f /var/log/httpd/keystone_access.log21:26
marststack    14054  2915  0 17:26 pts/1    00:00:00 grep --color=auto keys21:26
*** gyee_ has joined #openstack-keystone21:29
marstbreton: shall I just run "uwsgi --http 127.0.0.1:35357 --wsgi-file $(which keystone-wsgi-admin)"?21:32
bretonmarst: no idea. I know that some time ago restarting apache2 was enough.21:36
*** su_zhang has quit IRC21:37
*** su_zhang has joined #openstack-keystone21:38
*** su_zhang has quit IRC21:38
*** su_zhang has joined #openstack-keystone21:38
marstbreton: Yay! Finally found the reason:21:39
marstSep 07 17:38:50 controller httpd[17954]: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:500021:39
marstSep 07 17:38:50 controller httpd[17954]: (13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:500021:39
marstSep 07 17:38:50 controller httpd[17954]: no listening sockets available, shutting down21:39
marstSep 07 17:38:50 controller httpd[17954]: AH00015: Unable to open logs21:39
marstthat's from systemctl status httpd.service21:40
marstthank you!21:40
*** LamT_ has quit IRC21:41
*** asettle has quit IRC21:43
*** jmccrory has quit IRC21:53
*** jmccrory has joined #openstack-keystone21:53
*** spzala has joined #openstack-keystone21:54
openstackgerritLance Bragstad proposed openstack/keystone: WIP: Switch fernet to be the default token provider.  https://review.openstack.org/34568821:54
*** jmccrory has quit IRC21:55
*** adrian_otto has joined #openstack-keystone21:55
*** jmccrory has joined #openstack-keystone21:55
*** jmccrory has quit IRC21:57
*** jmccrory has joined #openstack-keystone21:57
lbragstadsamueldmq ^ new version that works with the KeyRepository fixture stuff that was refactored21:58
*** chrisshattuck has quit IRC21:58
*** chrisshattuck has joined #openstack-keystone22:00
samueldmqlbragstad: nice, let's see what Jenkins says22:01
*** javis has quit IRC22:01
*** su_zhang has quit IRC22:01
*** BjoernT has quit IRC22:02
*** su_zhang has joined #openstack-keystone22:05
openstackgerritRon De Rose proposed openstack/keystone: Return password_expires_at during auth  https://review.openstack.org/36700822:09
*** tonytan4ever has quit IRC22:10
*** chlong has joined #openstack-keystone22:12
bretonrderose: got any ideas about https://bugs.launchpad.net/keystone/+bug/1621200 ?22:13
openstackLaunchpad bug 1621200 in OpenStack Identity (keystone) "MySQLOpportunisticIdentityDriverTestCase.test_change_password fails in UTC+N timezone" [Undecided,New]22:13
*** roxanaghe has quit IRC22:13
rderosebreton: is this related to the eager loading patch?22:13
bretonrderose: no22:14
bretonrderose: happens on master22:14
marstbreton: selinux was enabled by default in the system. reboot made selinux active again and stopped apache from running. disabled selinux, restarted httpd and now everything works. thank you so much for help and support! :)22:14
bretonrderose: eager loading runs into it once in a while, maybe the same rootcause22:14
rderosebreton: hmm...22:15
bretonmarst: awesome, glad you figured it out.22:15
*** slberger has left #openstack-keystone22:15
*** joerch has quit IRC22:15
bretonrderose: i debugged and for some reason created_at for the old password becomed datetime.datetime.now(), but doesn't get changed in the database22:16
openstackgerritLance Bragstad proposed openstack/keystone: WIP: Switch fernet to be the default token provider.  https://review.openstack.org/34568822:16
openstackgerritLance Bragstad proposed openstack/keystone: Use freezegun for change password tests  https://review.openstack.org/36701722:16
rderosebreton: the old password is getting reset?22:17
bretonrderose: because created_at becomes now(), it becomes the most recent password22:17
bretonrderose: don't know that yet22:17
bretonrderose: i think you don't see the issue in UTC-N because old password gets now() too, but your now() is earlier than utcnow()22:18
*** marst has left #openstack-keystone22:18
rderosebreton: ah...22:18
bretonrderose: but for me now() > utcnow()22:18
*** roxanaghe has joined #openstack-keystone22:19
bretonthe question is why it doesn't happen on sqlite.22:19
rderosebreton: I think this would be why:22:19
rderosehttps://github.com/openstack/keystone/blob/master/keystone/common/sql/contract_repo/versions/002_password_created_at_not_nullable.py#L3822:19
rderosebreton: defaults to now(); not necessarily utcnow22:20
bretonrderose: ok. But what the value from the db is not used?22:21
breton*why22:21
breton> server_default=sql.func.now()22:22
bretonshouldn't it be22:22
bretonserver_default=sql.func.now22:22
bretonwithout ()22:22
breton?22:22
*** su_zhang has quit IRC22:23
rderosebreton: I don't think so, but let me verify this22:23
*** sdake has quit IRC22:24
rderosebreton: from the examples I've seen, it shows it with the ()22:25
rderosehttp://docs.sqlalchemy.org/en/latest/core/defaults.html22:25
bretonyes, looks like it22:26
*** BjoernT has joined #openstack-keystone22:26
*** BjoernT has quit IRC22:26
*** spedione is now known as spedione|AWAY22:27
rderosebreton: the database should be configured to utc, right?22:29
bretonrderose: no idea. I use debian defaults.22:30
bretoni just know that it needs to be restarted after tz change22:30
bretonworked on ubuntu defaults too btw, on amakarov_away localhost22:33
breton*worked == was reproducible22:33
rderosebreton: okay, let me dig into this one22:35
rderoseamakarov_away: you around?22:36
*** asettle has joined #openstack-keystone22:44
*** adriant has joined #openstack-keystone22:44
*** spzala has quit IRC22:45
*** spzala has joined #openstack-keystone22:46
*** spzala has quit IRC22:46
*** spzala has joined #openstack-keystone22:47
*** spzala has quit IRC22:47
*** spzala has joined #openstack-keystone22:47
*** spzala has quit IRC22:47
*** spzala has joined #openstack-keystone22:48
*** spzala has quit IRC22:48
*** spzala has joined #openstack-keystone22:48
*** spzala has quit IRC22:48
*** asettle has quit IRC22:49
*** spzala has joined #openstack-keystone22:49
*** spzala has quit IRC22:49
*** spzala has joined #openstack-keystone22:49
*** spzala has quit IRC22:50
*** ddieterly is now known as ddieterly[away]22:50
bretonrderose: ok, the value gets changed in the database too22:50
*** ddieterly[away] has quit IRC22:50
*** topol_ has quit IRC22:50
*** spzala has joined #openstack-keystone22:50
*** spzala has quit IRC22:50
*** spzala has joined #openstack-keystone22:51
*** spzala has quit IRC22:51
bretonrderose: http://paste.openstack.org/show/568254/ before user_ref.password = utils.hash_password(new_password)22:51
*** spzala has joined #openstack-keystone22:52
bretonrderose: http://paste.openstack.org/show/568255/ after user_ref.password = utils.hash_password(new_password)22:52
*** spzala has quit IRC22:52
bretonrderose: note how the password ending with 5VfP1 gets a new created_at.22:52
*** spzala_ has joined #openstack-keystone22:53
*** spzala has joined #openstack-keystone22:53
*** spzala has quit IRC22:53
*** spzala_ has quit IRC22:53
rderosebreton: yeah, the it gets a default (non-UTC) from func.now()22:53
*** spzala has joined #openstack-keystone22:53
rderosebreton: and then when changed, gets UTC22:53
*** spzala has quit IRC22:53
rderosebreton: expired gets set, so I think I will use that to fix this22:54
*** spzala has joined #openstack-keystone22:54
*** spzala has quit IRC22:54
*** spzala has joined #openstack-keystone22:55
*** roxanaghe has quit IRC22:55
*** spzala has quit IRC22:55
*** spzala has joined #openstack-keystone22:56
*** spzala has quit IRC22:56
rderosebreton: in other words:22:56
rderosehttp://paste.openstack.org/show/568256/22:56
rderosebreton: instead of: return self.local_user.passwords[-1]22:56
*** spzala_ has joined #openstack-keystone22:56
*** spzala has joined #openstack-keystone22:56
*** spzala has quit IRC22:56
*** spzala_ has quit IRC22:56
rderosebreton: maybe...22:57
*** spzala has joined #openstack-keystone22:57
*** spzala has quit IRC22:57
*** spzala has joined #openstack-keystone22:57
*** spzala has quit IRC22:58
rderosezzzeek: can func.now() return utc timestamp?22:58
*** spzala has joined #openstack-keystone22:58
*** spzala has quit IRC22:58
*** spzala has joined #openstack-keystone22:59
*** spzala has quit IRC22:59
*** spzala has joined #openstack-keystone23:00
*** spzala has quit IRC23:00
bretonrderose: i still don't understand why func.now() gets applied23:00
*** spzala has joined #openstack-keystone23:01
*** roxanaghe has joined #openstack-keystone23:01
*** spzala has quit IRC23:01
bretonrderose: https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql_model.py#L115 only expires_at gets changed here23:01
openstackgerritSean Perry proposed openstack/keystone: Add domain check in domain-specific role implication  https://review.openstack.org/35126423:01
*** spzala has joined #openstack-keystone23:02
*** spzala has quit IRC23:02
*** spzala has joined #openstack-keystone23:03
bretonrderose: http://paste.openstack.org/show/568369/ this is what is being sent to mysql at the moment23:03
*** spzala has quit IRC23:03
*** javis has joined #openstack-keystone23:03
*** harlowja has quit IRC23:03
*** chrisshattuck has quit IRC23:03
*** spzala has joined #openstack-keystone23:04
*** spzala has quit IRC23:04
*** spzala has joined #openstack-keystone23:04
*** spzala has quit IRC23:05
*** ravelar has quit IRC23:05
*** spzala has joined #openstack-keystone23:05
*** spzala has quit IRC23:05
*** spzala has joined #openstack-keystone23:06
*** spzala has quit IRC23:06
rderosebreton: it gets applied so that I can make the created_at column nullable23:07
*** spzala has joined #openstack-keystone23:07
*** spzala has quit IRC23:07
*** spzala has joined #openstack-keystone23:08
*** spzala has quit IRC23:08
bretonrderose: i don't understand how that's connected23:08
*** spzala has joined #openstack-keystone23:08
*** spzala has quit IRC23:08
rderosebreton: I think what's happening is func.now() is setting the created_at date for the old password23:09
*** spzala has joined #openstack-keystone23:09
rderosebreton: when you change it, the created_at date is getting set from the application layer (utc)23:09
*** spzala has quit IRC23:09
rderosebreton: does that make sense?23:10
*** spzala has joined #openstack-keystone23:10
*** spzala has quit IRC23:10
bretonrderose: probably yes. But why default=datetime.datetime.utcnow is not enough?23:10
*** tonytan4ever has joined #openstack-keystone23:10
bretonrderose: and why it gets set on UPDATE password SET expires_at=... ?23:10
*** spzala has joined #openstack-keystone23:11
*** spzala has quit IRC23:11
rderosebreton:  default=datetime.datetime.utcnow doesn't work for server_default23:11
bretonrderose: lets drop server_default then at all23:11
*** spzala has joined #openstack-keystone23:11
*** spzala has quit IRC23:12
*** spzala has joined #openstack-keystone23:12
rderosebreton: then I cannot make the column not nullable because the created_at would not automatically get updated23:12
*** spzala has quit IRC23:12
rderosebreton: we need the server_default in order to make this column not nullable23:13
*** spzala has joined #openstack-keystone23:13
*** spzala has quit IRC23:13
bretonrderose: so... setting default=datetime.datetime.utcnow alone isn't enough?23:13
rderosebreton: correct23:14
*** spzala has joined #openstack-keystone23:14
rderosebreton: and setting a datetime default is way more complicated than I ever thought would be23:14
*** spzala has quit IRC23:14
*** spzala has joined #openstack-keystone23:15
*** spzala has quit IRC23:15
bretonrderose: ok. But i still think that server_default behaves not as we would want it to23:15
*** tonytan4ever has quit IRC23:15
*** spzala has joined #openstack-keystone23:15
rderosebreton: correct, if it's not utc23:15
rderosebreton: right?23:15
*** spzala has quit IRC23:15
bretonrderose: even if it is utc23:15
rderosebreton: if it is utc, then there isn't a problem23:16
bretonrderose: it gets executes even on unrelated UPDATE23:16
bretonrderose: it will be. It executes on UPDATE of unrelated column23:16
*** spzala has joined #openstack-keystone23:16
bretonrderose: even if there is already something in created_at23:16
*** spzala has quit IRC23:16
rderosebreton: oh, I missed that part23:17
rderosebreton: it shouldn't...23:17
*** spzala has joined #openstack-keystone23:17
*** spzala has quit IRC23:17
bretonrderose: and it DOES NOT execute on create. The datetime on create is correct.23:18
*** spzala has joined #openstack-keystone23:18
rderosehmm...23:18
*** spzala has quit IRC23:18
rderosebreton: yeah, that totally doesn't make sense23:18
*** spzala has joined #openstack-keystone23:19
*** spzala has quit IRC23:19
*** spzala has joined #openstack-keystone23:20
*** spzala has quit IRC23:20
bretonalso, my english terrible degrades at night. Good night, will poke the issue tomorrow again.23:20
*** spzala has joined #openstack-keystone23:20
*** spzala has quit IRC23:20
*** spzala_ has joined #openstack-keystone23:20
*** spzala_ has quit IRC23:21
rderosebreton: okay, thanks for finding this btw23:21
rderosegoodnight23:21
*** spzala has joined #openstack-keystone23:21
*** spzala has quit IRC23:21
*** spzala has joined #openstack-keystone23:22
*** spzala has quit IRC23:22
*** spzala has joined #openstack-keystone23:23
*** spzala has quit IRC23:23
*** spzala has joined #openstack-keystone23:24
*** spzala has quit IRC23:24
*** spzala has joined #openstack-keystone23:24
*** spzala has quit IRC23:24
*** spzala has joined #openstack-keystone23:25
*** spzala has quit IRC23:25
*** spzala has joined #openstack-keystone23:26
*** spzala has quit IRC23:26
*** spzala has joined #openstack-keystone23:26
*** spzala has quit IRC23:27
*** spzala has joined #openstack-keystone23:27
*** spzala has quit IRC23:27
*** spzala has joined #openstack-keystone23:28
*** spzala has quit IRC23:28
*** spzala has joined #openstack-keystone23:29
*** spzala has quit IRC23:29
*** spzala has joined #openstack-keystone23:30
*** spzala has quit IRC23:30
*** spzala has joined #openstack-keystone23:30
*** spzala has quit IRC23:30
*** spzala has joined #openstack-keystone23:31
*** spzala has quit IRC23:31
*** spzala has joined #openstack-keystone23:32
*** spzala has quit IRC23:32
*** spzala has joined #openstack-keystone23:32
*** spzala has quit IRC23:33
*** spzala has joined #openstack-keystone23:33
*** spzala has quit IRC23:33
*** spzala has joined #openstack-keystone23:34
*** fangxu has quit IRC23:34
*** spzala has quit IRC23:34
*** spzala has joined #openstack-keystone23:35
*** spzala has quit IRC23:35
*** spzala has joined #openstack-keystone23:36
*** spzala has quit IRC23:36
*** spzala has joined #openstack-keystone23:36
*** spzala has quit IRC23:37
*** spzala has joined #openstack-keystone23:37
*** spzala has quit IRC23:37
*** fangxu has joined #openstack-keystone23:38
*** spzala has joined #openstack-keystone23:38
*** spzala has quit IRC23:38
*** spzala has joined #openstack-keystone23:39
*** spzala has quit IRC23:39
*** spzala has joined #openstack-keystone23:40
*** spzala has quit IRC23:40
*** spzala has joined #openstack-keystone23:41
*** spzala has quit IRC23:41
*** spzala has joined #openstack-keystone23:41
*** spzala has quit IRC23:41
*** spzala has joined #openstack-keystone23:42
*** spzala has quit IRC23:42
*** spzala has joined #openstack-keystone23:43
*** spzala has quit IRC23:43
*** spzala has joined #openstack-keystone23:44
*** spzala has quit IRC23:44
*** spzala has joined #openstack-keystone23:44
*** spzala has quit IRC23:44
*** spzala has joined #openstack-keystone23:45
*** asettle has joined #openstack-keystone23:45
*** spzala has quit IRC23:45
*** spzala has joined #openstack-keystone23:45
*** tonytan4ever has joined #openstack-keystone23:45
*** spzala has quit IRC23:46
*** edmondsw has joined #openstack-keystone23:46
*** spzala has joined #openstack-keystone23:46
*** spzala has quit IRC23:46
*** spzala has joined #openstack-keystone23:47
*** spzala has quit IRC23:47
*** spzala has joined #openstack-keystone23:48
*** spzala has quit IRC23:48
*** spzala has joined #openstack-keystone23:49
*** spzala has quit IRC23:49
*** edmondsw has quit IRC23:49
*** spzala has joined #openstack-keystone23:50
*** spzala has quit IRC23:50
*** spzala_ has joined #openstack-keystone23:50
*** spzala_ has quit IRC23:50
*** spzala has joined #openstack-keystone23:50
*** spzala has quit IRC23:50
*** asettle has quit IRC23:51
*** spzala has joined #openstack-keystone23:51
*** spzala has quit IRC23:51
openstackgerritRon De Rose proposed openstack/keystone: Fixes password created_at errors due to server_default  https://review.openstack.org/36702523:51
*** spzala has joined #openstack-keystone23:52
*** spzala has quit IRC23:52
*** spzala has joined #openstack-keystone23:53
*** spzala has quit IRC23:53
*** spzala has joined #openstack-keystone23:53
*** spzala has quit IRC23:53
*** spzala has joined #openstack-keystone23:55
*** spzala has quit IRC23:55
*** spzala has joined #openstack-keystone23:55
*** spzala has quit IRC23:56
*** spzala has joined #openstack-keystone23:56
*** spzala has quit IRC23:57
*** spzala has joined #openstack-keystone23:57
*** spzala has quit IRC23:57
bretonrderose: i lied, i didn't go to sleep23:57
rderosebreton: :)23:58
bretonrderose: and i was wrong about server_default23:58
bretonrderose: http://dev.mysql.com/doc/refman/5.7/en/timestamp-initialization.html23:58
rderosebreton: you were?23:58
*** spzala has joined #openstack-keystone23:58
*** spzala has quit IRC23:58
bretonrderose: TIMESTAMP and DATETIME columns have no automatic properties unless they are specified explicitly, with this exception: By default, the first TIMESTAMP column has both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP if neither is specified explicitly.23:58
openstackgerritRon De Rose proposed openstack/keystone: Fixes password created_at errors due to the server_default  https://review.openstack.org/36702523:58
openstackgerritRon De Rose proposed openstack/keystone: Fixes password created_at errors due to the server_default  https://review.openstack.org/36702523:59
*** spzala has joined #openstack-keystone23:59
*** spzala has quit IRC23:59
bretonBy default, the first TIMESTAMP column has  both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP if neither is specified explicitly.23:59
rderosebreton: yeah, saw that as well23:59
bretonthis23:59
bretoncreated_at is our first TIMESTAMP column23:59
rderosebreton: so it's updating the timestamp if any column is updated23:59
rderoseI hate this!!23:59
*** spzala has joined #openstack-keystone23:59

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