Wednesday, 2019-01-30

*** imacdonn has quit IRC00:00
*** imacdonn has joined #openstack-keystone00:00
kmalloci was thinking of just merging it into a config group00:24
kmallocjwt and then call it jws_XXXX and jwe_XXX00:24
kmallocso it would be in the [jwt_tokens] group00:24
lbragstadoh - not sharing keys though?00:24
kmalloc+2 as is fwiw00:24
lbragstadok right00:24
kmallocjust mull over the single confg option group00:25
lbragstadwill do00:25
lbragstadi can respin it tomorrow if needed00:25
kmallocyeah no worries if you don't00:26
kmallocmostly a think it over and decide if it makes sense in a single config group vs multipler00:26
*** ileixe has joined #openstack-keystone00:58
adriantNot sure if anyone here would have an opinion, but I'm proposing Adjutant's service type as 'operator-logic':
adriantknikolla: you've looked at it, thoughts on my choice of service-type?01:14
*** markvoelker has joined #openstack-keystone01:36
*** sapd1_ has quit IRC01:40
*** markvoelker has quit IRC01:41
*** tkajinam_ has joined #openstack-keystone01:47
*** tkajinam has quit IRC01:50
gagehugolbragstad: sorry I was out yesterday and today01:58
lbragstadgagehugo no worries01:58
lbragstadglad you're back01:59
openstackgerritMerged openstack/keystone master: Adjust Indents to meet PEP8 E117
*** lbragstad has quit IRC02:19
*** erus1 has quit IRC02:27
*** markvoelker has joined #openstack-keystone02:37
*** Dinesh_Bhor has joined #openstack-keystone02:43
*** Nel1x has quit IRC03:03
*** markvoelker has quit IRC03:08
*** Nel1x has joined #openstack-keystone03:20
*** sapd1_ has joined #openstack-keystone03:55
*** whoami-rajat has joined #openstack-keystone04:02
*** erus1 has joined #openstack-keystone04:09
*** ayoung has quit IRC04:24
*** Dinesh_Bhor has quit IRC04:33
*** Nel1x has quit IRC04:34
*** Dinesh_Bhor has joined #openstack-keystone04:38
*** ileixe has quit IRC05:05
*** erus1 has quit IRC05:36
*** ileixe has joined #openstack-keystone05:38
*** aojea has joined #openstack-keystone06:23
*** aojea has quit IRC06:27
*** pcaruana has joined #openstack-keystone08:10
*** tkajinam_ has quit IRC08:15
*** markvoelker has joined #openstack-keystone08:16
*** awalende has joined #openstack-keystone08:24
*** bnemec has joined #openstack-keystone08:31
*** awalende has quit IRC08:35
*** awalende has joined #openstack-keystone08:35
*** xek has joined #openstack-keystone08:38
*** awalende has quit IRC08:39
*** awalende has joined #openstack-keystone08:40
*** markvoelker has quit IRC08:49
*** Dinesh_Bhor has quit IRC09:10
*** ileixe has quit IRC09:29
*** Dinesh_Bhor has joined #openstack-keystone09:34
*** markvoelker has joined #openstack-keystone09:47
*** awalende has quit IRC09:48
*** awalende has joined #openstack-keystone09:55
*** shyamb has joined #openstack-keystone09:58
brtknrare application credentials available in mitaka?10:08
brtknre.g. for kubernetes cloud provider with limited subset of priviledges of the user that generated the credential10:09
brtknrnot clear from this: when it was introduced10:12
brtknri can see here that it was implemented from queens onwards:
*** shyamb has quit IRC10:13
*** shyamb has joined #openstack-keystone10:13
*** dr_gogeta86 has quit IRC10:15
*** markvoelker has quit IRC10:19
*** dr_gogeta86 has joined #openstack-keystone10:20
openstackgerritMerged openstack/keystone master: Add experimental job for CentOS
openstackgerritMerged openstack/keystone master: Handle special cases with msgpack and python3
cmurphybrtknr: it was implemented for queens
cmurphybrtknr: that's very strange that it appears in the backlog directory there, that seems like some apache htaccess issue10:42
cmurphyor just that the file was never removed from disk when we moved it out of the backlog10:44
brtknrcmurphy: I'm looking at trust as a possible way to do this...10:46
brtknrIs a trust scoped to a particular project10:46
brtknre.g. I have an admin user and I want to create a service account with trust delegated to a particular project, is this what its for?10:47
brtknrcmurphy: ^10:47
brtknrI'm currenty failing at even this:10:49
brtknrubuntu@devstack-queens:/opt/stack/devstack$ openstack --os-project-id=a5a518cb29be42b083c439125eb1a36d trust show 94c31d36983f4edca247895a7017092b10:49
brtknrNo trust with a name or ID of '94c31d36983f4edca247895a7017092b' exists.10:49
cmurphybrtknr: yes that is essentially what trusts are for10:49
brtknrwhereas, when I do `openstack trust list`, i can clearly see the same trust-id listed there10:49
cmurphy--os-project-id is the project you are authenticating with when you make the trust list request, it's not the project the trust was created for10:51
cmurphyso openstack trust show 94c31d36983f4edca247895a7017092b should work10:51
brtknrhmm, but its not10:54
brtknrthis is on stable/queens10:54
cmurphyhow did you create the trust?10:55
cmurphythis works for me on master we haven't changed the trust code much between queens and now10:58
brtknropenstack trust show works fine on master branch11:01
brtknron stable/queens, not so much11:02
brtknrI didnt create it11:02
brtknrIt was created by Magnum11:03
brtknrWhat does this mean? Authentication cannot be scoped to multiple targets. Pick one of: project, domain, trust or unscoped11:09
*** shyamb has quit IRC11:15
*** Dinesh_Bhor has quit IRC11:16
*** markvoelker has joined #openstack-keystone11:16
*** mvkr has joined #openstack-keystone11:29
cmurphybrtknr: it means you have too many scopes in your environment, for example maybe you set both OS_PROJECT_ID and OS_TRUST in your environment variables11:39
*** Dinesh_Bhor has joined #openstack-keystone11:43
*** markvoelker has quit IRC11:50
*** Dinesh_Bhor has quit IRC11:51
*** shyamb has joined #openstack-keystone12:07
*** shyamb has quit IRC12:24
*** shyamb has joined #openstack-keystone12:25
*** shyamb has quit IRC12:30
*** erus1 has joined #openstack-keystone12:32
*** markvoelker has joined #openstack-keystone12:47
*** markvoelker has quit IRC13:13
brtknrcmurphy: okay i got it working but i still need to explicitly specify --os-user-domain-id 66e2326c9fb1467282edee13deec087e13:26
brtknrI would have thought this would be inferred automatically13:27
*** abhishek has joined #openstack-keystone13:40
cmurphybrtknr: os-user-domain-id means the domain of the user who is trying to authenticate, it is used as a namespace for the user so that you can refer to the user by username, it's not needed if you use --os-user-id/OS_USER_ID13:40
brtknrcmurphy: its slightly annoyign that you need to specify the username if you're already specifiying user-id13:43
brtknrbut thanks for the tip!13:44
cmurphybrtknr: you don't13:44
cmurphyif you have user id then you don't need username or user-domain13:44
brtknrcmurphy: i do13:44
cmurphybrtknr: i'm quite sure you do not13:44
brtknri am currently doing this: openstack --os-username b95eabac-cc33-457a-9005-29f8c435c4bf_5d8f687a7d5945689c728a3c947255d7 --os-password ymAADG7B28ftDTEtdf --os-trust-id 4582fdd6760b48169cce8871df188084 --os-auth-url --os-user-id aa55d38d6d3d429e87c0c5fd1e39c649 server list13:45
brtknrif i omit --os-username part, it doesnt work13:45
cmurphywhat does it do?13:45
brtknrMissing parameter(s):13:47
brtknrSet a username with --os-username, OS_USERNAME, or auth.username13:47
brtknrthis is on the master branch13:47
cmurphymaster branch of keystone or of python-openstackclient?13:48
brtknrof keystone13:49
*** erus1 has quit IRC13:49
*** erus1 has joined #openstack-keystone13:49
*** pcaruana has quit IRC13:50
brtknri just updated my python-openstackclient pip package, no luck13:51
brtknrstrangely, if i use a placeholder username, it works13:52
brtknreg. --os-username dummy13:52
brtknrit doesnt have to be a real username13:53
cmurphybrtknr: wow you are right13:54
cmurphythat seems really broken13:55
brtknrthanks for cross checking :)13:55
*** pcaruana has joined #openstack-keystone13:57
openstackgerriterus proposed openstack/keystone master: Add OpenSUSE support in devstack federation plugin
cmurphybrtknr: filed a bug!/story/200489814:06
brtknrcmurphy: for a moment i thought it had something to do with trust-id but it seems to be broken regardless! thanks for filing the bug!14:08
brtknrcmurphy: do you suspect the python-openstackclient or keystone itself?14:11
*** dave-mccowan has joined #openstack-keystone14:11
*** dave-mccowan has quit IRC14:16
cmurphybrtknr: it's an issue with the validation on the client side14:17
cmurphyno python-openstackclient14:18
brtknris that resposible for validation?14:18
brtknroh right14:18
cmurphyit does some client side validation14:18
cmurphyhi knikolla14:19
*** lbragstad has joined #openstack-keystone14:19
*** ChanServ sets mode: +o lbragstad14:19
erus1hi hi14:24
cmurphyhey erus114:24
erus1how are you?14:25
cmurphyI'm good, how are you erus1 ?14:25
erus1i'm so-so, couldn't sleep again cmurphy :(14:26
cmurphywe need to get you some air conditioning14:26
erus1hot it's really heavy these days14:27
erus1btw, i'm with the experimental jobs for suse, should i to use py35 o just py3?14:28
cmurphyerus1: just py314:28
erus1heat* xD14:28
lbragstadi'm wondering if people have thoughts about the jws key rotation utility14:29
*** erus1 has quit IRC14:29
lbragstadthe more i think about it, the more i'm not sure if having a jws_setup and jws_rotate makes sense14:30
*** erus1 has joined #openstack-keystone14:30
cmurphylbragstad: explain?14:30
lbragstadso - fernet uses symmetric encryption, right?14:30
brtknrcmurphy: Ive fixed it! It had to be done in osc_lib14:31
brtknrI'll push it upstream14:31
cmurphybrtknr: awesome!14:31
lbragstadand we need to have a staged key to make sure we can gracefully rotate keys without experiencing false positives with token validation14:31
*** aojea_ has joined #openstack-keystone14:32
lbragstadso - rotation appears to fill an important role in that sense (for symmetric keys and management of that repository)14:32
lbragstadfor jws - we're using asymmetric14:32
lbragstadand keystone can only use a single private key to sign tokens14:33
lbragstadthe public keys are in a separate repository14:33
openstackgerriterus proposed openstack/keystone master: Add experimental job for OpenSUSE
lbragstadbut if you have to rotate a key pair on a host, having a staged key doesn't really help you?14:34
* cmurphy ponders14:35
brtknrcmurphy: ^14:35
lbragstadthis is what i have written down - which is probably easier to read than my irc chicken scratch
cmurphylbragstad: I guess as long as this is only about signature validation and not about decryption then I can't think of a reason to rotate the private key14:38
*** awalende has quit IRC14:39
*** awalende has joined #openstack-keystone14:40
*** mchlumsky has joined #openstack-keystone14:43
*** erus1 has quit IRC14:43
*** erus1 has joined #openstack-keystone14:43
*** awalende has quit IRC14:44
lbragstadcmurphy yeah - i expect rotation to be a less frequent operations14:45
lbragstadbut i was thinking, what would be reasonable behavior when you perform jws_rotate twice?14:45
*** Dinesh_Bhor has joined #openstack-keystone14:46
lbragstadwrite a private key to ``keystone.conf [jws_tokens] private_key_repository`` and put the public in the other repository?14:46
lbragstadalso - we might run into naming issues since we don't have a convention for the public/private key pair names14:47
cmurphyi'm not sure what you mean, why should jws_rotate twice be different than once?14:47
lbragstadi'm assuming jws_rotate would create a new key pair14:48
lbragstadif we already have a private.pem in the private key repository, would we just do privaten.pem?14:50
*** erus1 has quit IRC14:50
lbragstadsame with the public keys...14:50
*** erus1 has joined #openstack-keystone14:51
lbragstadthat might be weird for operators planning on using something like rsync to key the entire public key directory in sync across all nodes in their deployment14:51
brtknrcmurphy: I've added a unit test14:52
brtknrfor user_id14:52
cmurphylbragstad: for the private key if we don't need the same staging process as we have for fernet then i think it would just overwrite private.pem14:52
cmurphylbragstad: for the public key i guess we'd need some kind of naming convention with incrementing values14:52
lbragstadcmurphy in the jws_rotate script?14:53
lbragstadif jws_rotate is going to be creating a new key pair, we need to make sure operators sync the new public key to the other nodes before we replace the current private.pem14:53
lbragstadotherwise tokens will only be validatable on the node they are issued from14:54
cmurphyoh good point14:54
lbragstadand yeah - the naming convention for public keys seems a little strange to me...14:54
lbragstadi thought about using a system identifier14:55
lbragstador a uuid, but neither of those feel like great solutions?14:55
lbragstadi can also imagine operators wanting to have a specific convention and that would make generalizing the implementation in keystone-manage tough14:56
lbragstadall in all, i wonder if we should just have a ``keystone-manage jws_create_keypair`` that just generates a key pair and writes the corresponding keys to public.pem and private.pem in the working director14:58
lbragstadthen let operators use config management tools to push the new public.pem to other nodes, copy the new private.pem to the private key repository, etc..14:59
brtknrcmurphy: please take a look at the unit test I uploaded15:03
brtknrIt seems to be passing15:03
brtknrDont think osc_lib afaics15:03
cmurphybrtknr: commented15:06
cmurphylbragstad: that doesn't sound bad to me, they have to do something similar for managing their regular ssl certs anyways15:07
lbragstadcool - i'll update the series15:07
*** aojea_ has quit IRC15:09
*** aojea_ has joined #openstack-keystone15:09
cmurphyanother possibility could be to do it in stages, like 1. keystone-manage jws_keypair_start -> generates public key and staged private key, 2. (go rsync the public key yourself), 3. keystone-manage jws_keypair_ready -> promotes the staged private key to real private key15:10
cmurphythat third part is basically just a mv so that would be a little silly15:10
lbragstadthat's an option15:10
*** aojea_ has quit IRC15:13
brtknrcmurphy: I am not sure how to test for this!15:34
*** Dinesh_Bhor has quit IRC15:37
cmurphybrtknr: try this
brtknrthanks :016:00
brtknrI tried the test before the patch and it fails as expected16:00
*** pcaruana has quit IRC16:01
brtknrcmurphy: ^16:01
*** pcaruana has joined #openstack-keystone16:17
brtknrcmurphy: the thing with not being able to do `openstack trust show trust-id` on stable/queens is still an issue16:38
*** gyee has joined #openstack-keystone16:42
*** abhishek has quit IRC16:42
*** pcaruana has quit IRC16:45
cmurphybrtknr: can you report it as a keystone bug
brtknrcmurphy: wait, I think I figured it out16:57
brtknrI can only run `openstack trust list` as admin user16:58
brtknrbut in order to invoke `trust show` i need to be the `trustor`, even the admin cannot show a trust16:58
brtknrthis is the case in both queens and master branch16:59
*** bnemec has quit IRC17:14
openstackgerritLance Bragstad proposed openstack/keystone master: Add configuration options for JWS provider
openstackgerritLance Bragstad proposed openstack/keystone master: Add keystone-manage create_jws_keypair functionality
openstackgerritLance Bragstad proposed openstack/keystone master: Add test fixture for the JWS key repository
openstackgerritLance Bragstad proposed openstack/keystone master: Add PyJWT as a requirement
openstackgerritLance Bragstad proposed openstack/keystone master: Implement JWS token provider
openstackgerritLance Bragstad proposed openstack/keystone master: Add JWS token provider documentation
*** xek_ has joined #openstack-keystone18:08
*** xek has quit IRC18:10
*** pcaruana has joined #openstack-keystone18:17
cmurphybrtknr: okay yes i think that is expected, especially if it didn't change between branches18:33
*** awalende has joined #openstack-keystone18:40
*** awalende has quit IRC18:45
*** aojea has joined #openstack-keystone19:04
*** aojea has quit IRC19:09
hrybackikmalloc: is dogpile.cache.memcached only good for a single server? E.g., use oslo_cache.memcache_pool when you want to have multiple daemons?19:57
hrybackisingle instance of memcached*19:58
kmallocBoth work for multiple servers.19:59
kmallocPool limits the number of connections to memcache.19:59
kmallocSo you don't spin too many up.19:59
hrybackiack /me reads more20:00
*** aojea has joined #openstack-keystone20:07
*** erus1 has quit IRC20:07
*** erus1 has joined #openstack-keystone20:08
*** xek_ has quit IRC20:45
*** xek_ has joined #openstack-keystone20:46
*** xek_ has quit IRC21:03
*** aojea has quit IRC21:08
*** aojea has joined #openstack-keystone21:08
kmallocEventlet tends to spin up a connection per greenlet and that can overload the memcache server.21:26
*** erus1 has quit IRC21:26
*** erus1 has joined #openstack-keystone21:26
*** aojea has quit IRC21:31
*** aojea has joined #openstack-keystone21:32
lbragstadkmalloc i respun the entire jwt stack21:35
lbragstadaddressed the configuration group naming21:35
lbragstadand clarified the keystone-manage utility bits21:35
kmallocWill review after shower, had to do emergency last minute painting of my old place before carpet was installed >.<21:36
kmallocTurns out someone (sigh, me) got the wrong touch up paint.21:36
kmallocSooooo... There were white streaks all over the walls.21:37
lbragstadi've been there - that sucks21:37
lbragstadi have painting to do tonight, too21:37
lbragstadnot really looking forward to it.. i feel your pain21:37
kmallocI just wish I owned the place.. at least that way I wouldn't be painting this awful flat white that of you look wrong at it, it smudges and then needs to be repainted21:38
kmallocEggshell people eggshell... You can use magic eraser on it.21:38
kmallocAnd even wash it.21:38
*** aojea has quit IRC21:39
hrybackiquality paint is key to flat white (granted you may need to put on more coats than you like initially)21:50
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add API for /v3/access_rules
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add SQL migrations for app cred capabilities
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add driver support for app cred capabilities
hrybackiflat white walls with semi-gloss trim can really make a room pop with the right accents21:50
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add manager support for app cred capabilities
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add API changes for app cred capabilities
openstackgerritColleen Murphy proposed openstack/keystone master: [WIP] Add capabilities to token validation
*** openstackgerrit has quit IRC21:50
eanderssonIs there a reason why the catalog shouldn't render properly if a project name/id isn't provided?21:57
eanderssonReferring to this code path21:58
eanderssonIf project_id is None, all urls with e.g. $(project_id) will fail to render and not show up when you do something like openstack catalog list21:59
*** ianw_pto is now known as ianw21:59
eanderssonNot sure if it is just a template issue, or WAI22:00
*** openstackgerrit has joined #openstack-keystone22:03
openstackgerritIslam Musleh proposed openstack/keystone master: Converting the API tests to use flask's test_client
*** whoami-rajat has quit IRC22:20
kmallochrybacki: not "flat" but the flatest paint that was made by the manufacturer... usually it's used where it can't be touched.22:22
kmallochrybacki: also it was one of those stupid custom colors that can only be made at the corporate stores.22:23
openstackgerritMerged openstack/keystone master: Expose receipt_setup and receipt_rotate command
kmalloclbragstad: did we want to make JWSKeyPair work like fernetsetup?22:40
lbragstadwell - that's something cmurphy and i were talking about a little bit earlier22:41
kmalloci'm happy with it as is.22:42
kmallocbut just asking before +2ing22:42
lbragstadin case you want to understand the context22:42
lbragstadthe tl;dr is that asymmetric keys don't really have the same rotation flow that symmetric keys do22:42
openstackgerritMerged openstack/keystone master: PY3: switch to using unicode text values
*** lbragstad has quit IRC22:48
*** lbragstad has joined #openstack-keystone22:54
*** ChanServ sets mode: +o lbragstad22:54
*** tkajinam has joined #openstack-keystone23:01
kmalloclbragstad: the cleanup_instance is very specific to instantiated classes and how things are run23:39
kmallocit can lead to bleeding through.23:39
kmalloclbragstad: it's simply safer to do an explicit cleanup.23:39
lbragstadkmalloc yeah - i was just trying to recreate it23:42
lbragstadso i could understand how it actually works23:42
kmallocit doesn't happen often23:42
kmallocor consistently.23:43
kmallocit's hard to test for because test classes swap between runners as needed23:44
kmallocso you may or may not see the attribute on a further test because of where it is scheduled23:44

Generated by 2.15.3 by Marius Gedminas - find it at!