18:01:40 <dstanek> #startmeeting keystone
18:01:40 <openstack> Meeting started Tue Sep 20 18:01:40 2016 UTC and is due to finish in 60 minutes.  The chair is dstanek. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:44 <openstack> The meeting name has been set to 'keystone'
18:01:49 <dstanek> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:01:58 <dstanek> the first bunch or topics are really just announcements; let's get started
18:02:05 <dstanek> #topic RC status
18:02:14 <dstanek> RC1 was tagged on Thursday last week, we will be releasing RC2 this week or next
18:02:20 <dstanek> #link https://launchpad.net/keystone/+milestone/newton-rc2
18:02:28 <dstanek> Only bug has been backported so far: link https://bugs.launchpad.net/keystone/+bug/1621200
18:02:29 <openstack> Launchpad bug 1621200 in OpenStack Identity (keystone) newton "password created_at does not honor timezones" [High,Fix committed] - Assigned to Ron De Rose (ronald-de-rose)
18:02:53 <dstanek> if you know of other bugs that need to be backported we should get on that
18:03:23 <dstanek> questions, comments or concerns?
18:03:41 <bknudson> other than this problem keystone is perfect.
18:03:54 <dstanek> ++
18:04:09 <dstanek> moving along then
18:04:14 <dstanek> #topic newton retrospective
18:04:25 <dstanek> #link https://etherpad.openstack.org/p/keystone-newton-retrospective
18:04:39 <dstanek> has everyone seen this yet?
18:04:51 <lbragstad> yup
18:04:53 <bknudson> new to me
18:05:13 <rderose> started, but need to add more
18:05:14 <dstanek> it would be really great if everyone can help out and add some content
18:05:47 <dstanek> this way we can all improve and make sure as a project we are healthy
18:05:54 <lbragstad> ++
18:06:10 <dstanek> no reason to 'make keystone great again' if we never let it slip
18:06:39 <rderose> :)
18:06:44 <dstanek> so please do take a few minutes to give some honest feedback
18:07:02 <dstanek> questions, comments or concerns?
18:07:20 * ayoung needs more time to work on Keystone
18:07:27 * bknudson too
18:08:08 <gagehugo> wtb more time
18:08:12 <dstanek> maybe this cycle you'll get to focus more on it
18:08:24 <dstanek> #topic release stable/mitaka
18:08:34 <dstanek> we were waiting on https://review.openstack.org/#/c/369618/ but this is now merged
18:08:44 <dstanek> proposed to release 9.2.0
18:08:50 <dstanek> #link https://review.openstack.org/#/c/372771/
18:09:03 <dstanek> Are there any other fixes that folks want in mitaka? it'll soon become the N-2 release -- only security and critical fixes are backport candidates
18:10:29 <dstanek> this is the part where you guys/gals give some feedback
18:10:54 <rodrigods> hope the ksc functional tests issue is not related to keystone server
18:11:07 <rodrigods> will talk more about when the topic arrives
18:11:59 <stevemar_droid> I'm marginally paying attention
18:12:45 <dstanek> either everyone is sleeping or keystone/mitaka is perfect :-) either way i'll move on
18:12:56 <dstanek> #topic service provider filters [knikolla]
18:13:01 <stevemar_droid> I was expecting Breton to have a few he wanted to back port:)
18:13:05 <knikolla> o/
18:13:07 <dstanek> knikolla: are you around?
18:13:12 <dstanek> you have the floor
18:13:44 <knikolla> so i ran into that spec in the backlog. was interested in picking it up. what's the status? why was it sent back to the backlog? is there interest for me to pick it up?
18:13:52 <dstanek> stevemar_droid: i don't think i saw him at roll call
18:14:04 <knikolla> it's potentially useful for some of my projects
18:14:06 <knikolla> in the long term
18:14:15 <rodrigods> knikolla, you can pick it up
18:14:24 <dstanek> #link https://review.openstack.org/#/c/371754/
18:14:27 <rodrigods> about the status... i'm not sure
18:14:34 <rodrigods> think the better source is the bp
18:14:46 <dstanek> who created the spec?
18:14:47 <lbragstad> I thought folks were on the fence about it since we couldn't decide if we wanted to improve OS-EP-FILTER or just create something new
18:14:53 <samueldmq> lbragstad: ++
18:14:59 <stevemar_droid> I don't remember why it went to backlog. It involves creating a lot of new APIs :(
18:15:00 * rodrigods did
18:15:06 <samueldmq> I was for creating a new, as sp has nothing to do with endpoints
18:15:17 <stevemar_droid> The os-ep-fikter stuff has been buggy
18:15:26 <rodrigods> samueldmq, it has everything to do with endpoints
18:15:31 <shaleh> ++
18:15:35 <samueldmq> not in our APIs
18:15:44 <rodrigods> that's true
18:16:09 <rodrigods> conceptually, they are just another region endpoint
18:16:20 <dstanek> is there more discussion needed about the actual proposal?
18:16:21 <rodrigods> but was implemented/displayed differently
18:16:23 <bknudson> I think we should create something new rather than continuing with endpoint filtering
18:16:33 <notmorgan> bknudson ++
18:16:51 <lbragstad> bknudson why is that?
18:16:57 <samueldmq> bknudson: ++
18:17:03 <samueldmq> that's my opinion too
18:17:03 <notmorgan> the catalog should be almost static
18:17:04 <bknudson> I just don't see how endpoint filtering can be efficient
18:17:28 <notmorgan> changing based upon scope is just awful and will never be efficient
18:17:45 <bknudson> right, since the catalog is static there should be what are essentially named catalogs.
18:17:47 <rodrigods> that idea came from reseller
18:17:48 * notmorgan gets on this soapbox again
18:17:59 <rodrigods> and hide SPs based on domains
18:18:14 <rodrigods> so if i'm inside a reselled cloud (aka a domain)
18:18:17 <notmorgan> SPs should be removed from the catalog and under their own api
18:18:25 <rodrigods> my seller won't be able to see my SPs
18:18:26 <notmorgan> since they are much more limitedly used
18:18:38 <notmorgan> catalog is used for a ton of things
18:18:44 <notmorgan> to make the basic cloud work
18:18:53 <samueldmq> notmorgan: ++
18:18:59 <dstanek> notmorgan: ++
18:19:10 <dstanek> it doens't make sense to have them there
18:19:14 <notmorgan> SPs are used for federation and are use heavily when federated, but shouldn't be conflated with the catalog wich is the local cloud.
18:19:28 <lbragstad> dstanek the service providers in the catalog you mean?
18:19:38 <samueldmq> auth catalog ?
18:19:39 <rodrigods> think our plugins rely on them being on the catalog
18:19:41 <dstanek> lbragstad: yes
18:19:44 * rodrigods needs to double check
18:19:56 <bknudson> plugins can be changed
18:20:00 <notmorgan> rodrigods: somewhat, but that can be changes
18:20:08 <notmorgan> samueldmq: no. call it service providers
18:20:15 <notmorgan> don't overload the name catalog more ;)
18:20:53 <notmorgan> i don;t know where catalog Tng work is
18:20:54 <samueldmq> :)
18:20:55 <rodrigods> isn't this an API change?
18:21:03 <notmorgan> but with that work, SPs should not exist in the catalog
18:21:11 <bknudson> maybe catalog TNG work will get started back up in O.
18:21:24 <ayoung> I think I had a spec that matches "named catalogs" bknudson
18:21:32 <notmorgan> catlog tng should also move catlog to /catalog
18:21:35 <bknudson> ayoung: yep, I've seen it.
18:21:44 <notmorgan> which could then handle named catlogs
18:21:47 <notmorgan> or whatever
18:21:52 <ayoung> notmorgan, yes
18:22:00 <notmorgan> but again catalogs should be effectively static
18:22:03 <ayoung> catalog/default  and catalog/all
18:22:05 <notmorgan> named or not
18:22:32 <ayoung> make it a git repo and you can do git checkout catalog:<tag>
18:22:44 <ayoung> catalog fetch should be separate from the token anyway
18:22:55 <dstanek> ayoung: ++
18:22:56 <notmorgan> ayoung: yes
18:22:59 <lbragstad> that would be glorious
18:23:07 <ayoung> Want to do it based on hash, actually, so we can tell if the default has changed
18:23:10 <rodrigods> back to PKI!
18:23:11 <rodrigods> (kidding)
18:23:32 <ayoung> rodrigods, that was where the idea came from, but it stands on its own even for uuid tokens
18:23:42 <dstanek> knikolla: so are you still interested in this topic?
18:23:55 <samueldmq> after all this :-)
18:23:59 <knikolla> dstanek: yes, if you have a spec for me which also filters the service providers
18:24:03 <samueldmq> (all this motivation)
18:24:18 <knikolla> dstanek: i'm ok with doing it the some other way, if the current spec is not the right way
18:24:24 <rodrigods> at least any work that has been merged in this front should be reverted
18:24:34 <dstanek> knikolla: it sounds more like a new spec has to be created for this work
18:24:38 <lbragstad> so - it sounds like instead of improving the current filter the general consensus is to move service providers to their own api
18:24:44 <lbragstad> dstanek ++
18:24:53 <lbragstad> or we can try to rework the existing spec
18:25:09 <rodrigods> if removed from catalog
18:25:23 <rodrigods> filtering it is just matter of adding a domain_id field
18:25:31 <rodrigods> just like we did for roles
18:25:41 <nisha_> o/
18:26:06 <knikolla> i can do the implementation, for the spec we should have a longer discussion.
18:26:14 <knikolla> for now lets give the floor to the ksc gate
18:26:44 <dstanek> knikolla: ok, if you can start to drive that discussion in #openstack-keystone using what was said here as the base
18:26:57 <dstanek> you can give our a spec based off of those discussions
18:27:09 <knikolla> dstanek: sounds good.
18:27:31 <dstanek> #action knikolla to start driving discussions for a service provider api
18:27:35 <dstanek> #topic keystoneclient gate is busted
18:27:42 <dstanek> #link https://review.openstack.org/#/q/project:openstack/python-keystoneclient
18:27:45 * rodrigods did a bit of investigation
18:27:48 <dstanek> any volunteers to look at it?
18:27:59 <dstanek> rodrigods: what did you find out?
18:28:10 <rodrigods> sometimes the tokens are not authorized
18:28:28 <stevemar_droid> It started around 3 days ago
18:28:30 <bknudson> lots of unauthorized
18:28:51 <dstanek> have you been able to find clues as to why?
18:29:08 <bknudson> I like how the test output has the request ID : req-3b10a7e2-abe2-4e46-9809-d56456e21a79 !
18:29:23 <rodrigods> for example: http://paste.openstack.org/show/582301/
18:29:28 <raildo> I wondering if it's the same issue on the v3-only gates
18:29:31 <stevemar_droid> Nice, didn't know that merged... bknudson
18:29:53 <rodrigods> ksc functional tests uses the devstack user
18:29:57 <bknudson> then of course the keystone log is useless.
18:30:00 <ayoung> could it be an artifact of Fernet and things happening too fast?
18:30:04 <rodrigods> so it should be authorized
18:30:07 <bknudson> http://logs.openstack.org/69/369469/1/check/gate-keystoneclient-dsvm-functional-ubuntu-xenial/da5db08/logs/apache/keystone.txt.gz#_2016-09-20_11_57_17_784
18:30:08 <stevemar_droid> Raildo, probably not. The devstack one looks glance related
18:30:39 <stevemar_droid> ayoung, fernet isn't merged yet
18:30:51 <lbragstad> afaik the only fernet related patches were the consistent handling of datetimes
18:30:52 <dstanek> "Invalid user token" - what causes that?
18:31:08 <bknudson> it looks like it's saying there's no token in the request.
18:31:09 <rodrigods> the error is also reproducible in my local devstack
18:31:12 <ayoung> revocation.  expired
18:31:36 <dstanek> rodrigods: oh, cool. that makes it much easier to actually debug.
18:31:44 <samueldmq> dstanek: +=
18:31:46 <samueldmq> ++
18:32:00 <samueldmq> just put LOGs everywhere and narrow it down
18:32:21 <bknudson> dstanek: The "Invalid user token" was a different request.
18:32:39 <lbragstad> we modified the token expiration to always round down - https://review.openstack.org/#/c/368244/2/keystone/token/provider.py,unified
18:32:52 <lbragstad> but that shouldn't have any impact on this
18:32:57 <bknudson> there's 3 logs for the req-3b10a7e2-abe2-4e46-9809-d56456e21a79 request
18:33:28 <dstanek> bknudson: yeah, i was that. i don't remember seeing that in my logs, but with 100k lines per request i may have just missed it
18:33:52 <dstanek> rodrigods: ok, are you going to continue on this bug?
18:33:55 <bknudson> 100k lines per request!
18:34:07 <dstanek> bknudson: i may be rounding down :-P
18:34:07 <rodrigods> yes, but i might be preempted soon
18:34:23 <rodrigods> so more volunteers can help a lot
18:34:39 <dstanek> rodrigods: ok, when you feel like that time is coming if you help my get my devstack in this state i can help pick it up
18:34:46 <rodrigods> ok
18:34:50 <rodrigods> dstanek, sounds good
18:35:06 <bknudson> keystone still needs better logging.
18:35:28 <dstanek> #action rodrigods to continue debugging the ksc gate issue
18:35:36 <dstanek> bknudson: are you volunteering?
18:35:45 <bknudson> It's been on my plate for a long time.
18:36:11 <dstanek> bknudson: i'd love to review that!
18:36:17 <dstanek> ... moving on
18:36:24 <dstanek> #topic identity v3 job for devstack (non-voting) broken
18:36:39 <dstanek> was mentioned last meeting
18:36:41 <dstanek> the job is: gate-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-nv
18:36:43 <dstanek> any update on this?
18:36:47 <samueldmq> raildo: ^
18:36:51 <dstanek> Looks like someone posted https://review.openstack.org/#/c/369675/ to partially fix it
18:36:59 <raildo> so about this issue, I investigated and talk with jamielennox earlier, we saw that glance could not find the switf endpoint using keystone v3.
18:37:12 <raildo> as you can see here: http://paste.openstack.org/show/582302/
18:37:43 <rodrigods> is the call using ?nocatalog for some reason?
18:37:46 <raildo> in addition, this commit had changed this code: https://github.com/openstack/glance_store/commit/fb77cb73c5daa9f78dbf13d9c943c91f92ba0298 not sure how this change impact this problem.
18:38:07 <rodrigods> ^ just throwing out guesses
18:38:36 <bknudson> https://review.openstack.org/#/c/369675/ passes v3
18:39:08 * ayoung suggests getting rid of glance
18:39:09 <bknudson> that's a change in devstack
18:39:17 <raildo> finally I have a patch https://review.openstack.org/#/c/324100/6 to add keystoneauth sessions support on glance, so this patch may fix this v2-v3 issues on glance.
18:39:25 <ayoung> raildo, Nice
18:40:16 <raildo> but we have to go deeper on this glance-swift issue...
18:40:43 <raildo> since, this jobs didn't changed anything about that
18:40:54 <notmorgan> have a breif thing for the end of the meeting dstanek
18:41:00 <notmorgan> like ~2m if tht is ok
18:41:08 <dstanek> raildo: is this something you are going to continue to work through?
18:41:12 <dstanek> notmorgan: shore
18:41:51 <raildo> dstanek, I'll continue working on the keystoneauth support on glance, and on this glance-swift issue
18:41:58 <bknudson> if https://review.openstack.org/#/c/369675/ is merged is that going to cause problems getting a better fix in place?
18:42:08 <bknudson> because it looks like https://review.openstack.org/#/c/369675/ gets it working again.
18:43:31 <raildo> bknudson, I think we have to fix it when we solve this bug: https://bugs.launchpad.net/glance-store/+bug/1620999
18:43:33 <openstack> Launchpad bug 1620999 in glance_store "swift driver ignores user_domain_name and project_domain_name settings" [High,Triaged]
18:45:05 <dstanek> raildo: please ask if you need help
18:45:15 <dstanek> ... moving along
18:45:27 <dstanek> #topic Cannot list flavors using a v3 token
18:45:30 <dstanek> Nova team is asking for help with a bug
18:45:33 <dstanek> #link https://bugs.launchpad.net/nova/+bug/1593573
18:45:35 <openstack> Launchpad bug 1593573 in OpenStack Compute (nova) "flavor image listing failed while calling Nova API with token from http://[host-ip]/identity/v3 " [Undecided,Incomplete] - Assigned to viswesuwara nathan (viswesn)
18:45:35 <raildo> dstanek, sure, I think jamielennox will work with me on it
18:45:46 <dstanek> raildo: great
18:46:02 <dstanek> does anyone have any bandwith to help with this one?
18:46:50 <shaleh> dstanek: stevemar posted on it
18:46:56 <shaleh> it looks to be working now?
18:47:11 <dstanek> shaleh: yes, he's also looking for help on it :-)
18:48:02 <dstanek> ok, sounds like a no
18:48:10 <lbragstad> i can poke at it
18:48:11 <shaleh> dstanek: I mean he posted on the bug itself. It appears to be ok now.
18:48:25 <shaleh> it may just need another validation.
18:48:35 <lbragstad> i'll see if I can recreate it on a fresh devstack
18:48:43 <shaleh> lbragstad: ++
18:48:50 <dstanek> shaleh: that would be great if it now just works!
18:49:25 <dstanek> lbragstad: thx, maybe there's not much to do here. you can also reach out to the nova crew and see if they are still seeing the issue
18:49:40 <dstanek> #action lbragstad to look into helping on https://bugs.launchpad.net/nova/+bug/1593573
18:49:41 <openstack> Launchpad bug 1593573 in OpenStack Compute (nova) "flavor image listing failed while calling Nova API with token from http://[host-ip]/identity/v3 " [Undecided,Incomplete] - Assigned to viswesuwara nathan (viswesn)
18:49:52 <lbragstad> dstanek agreed, I'll see if they are still seeing and updated the meeting agenda with the action item
18:50:10 <dstanek> ok notmorgan
18:50:12 <dstanek> #topic a brief topic from notmorgan
18:50:34 <notmorgan> o/
18:50:36 <notmorgan> so
18:50:56 <notmorgan> keystone, keystonemiddlwarew, keystoneauth, pycadf need some security love
18:51:07 <notmorgan> we need to get a pblic threat analysis done on them
18:51:23 <notmorgan> a couple of these projects are not covered by the VMT
18:51:32 <notmorgan> notably, keystonemiddleware and keystoneauth
18:51:46 <notmorgan> (KSC needs it too, but less important since it[s ust the client software)
18:51:57 <dstanek> how do we get them covered?
18:52:14 <notmorgan> you need to go through the process to get them covered
18:52:24 <shaleh> VMT?
18:52:32 <notmorgan> with starts with a threat analysis that is accepted by the ossg
18:52:34 <lbragstad> vulnerability maangement team?
18:52:37 <notmorgan> shaleh: vuln. management team
18:52:44 <shaleh> ah
18:52:46 <shaleh> thx
18:52:51 <dstanek> notmorgan: is there a link for the process?
18:52:58 <notmorgan> dstanek: looking for it sec.
18:53:44 <notmorgan> #link https://governance.openstack.org/reference/tags/vulnerability_managed.html
18:53:49 <notmorgan> see the Tag application process
18:53:52 <notmorgan> subsection
18:54:06 <notmorgan> and requirements
18:54:28 <notmorgan> number 5 for the requirements is what we need
18:54:35 <notmorgan> keystone and ksc are covered atm
18:54:38 <bknudson> is this just because we broken authtoken out of keystoneclient?
18:54:48 <bknudson> and auth out of keystoneclient?
18:54:51 <notmorgan> ksm was never covered after the breakout
18:54:53 <notmorgan> same with ksa
18:55:11 <notmorgan> an oversight, but it is where we are today
18:55:13 <dstanek> notmorgan: how do we get a third party audit
18:55:14 <dstanek> ?
18:55:33 <notmorgan> dstanek: someone (rax, RH, etc) can volunteer to have a security audit
18:55:49 <bknudson> maybe something to get done during the summit?
18:55:55 <notmorgan> or a group that does it normally (some company/individual that is capable)
18:56:13 <notmorgan> this should be something not done at the summit but as a general task
18:56:26 <notmorgan> a TA is not usually summit timeline type thing
18:56:26 <dstanek> ok, running out of time....
18:56:33 <notmorgan> but in short
18:56:53 <dstanek> i'll take the task of figuring out our nexts steps here and working with stevemar_droid to make it happen
18:56:55 <notmorgan> keystone is covered, but we (the VMT) are going to start requiring refreshes of threat analysis / security review long term
18:57:04 <notmorgan> so we should lead here as keystone
18:57:14 <notmorgan> and get all our repos covered *and* evaluated
18:57:15 <notmorgan> :)
18:57:26 <notmorgan> especially ksa and ksm
18:57:29 <dstanek> notmorgan: is #openstack-security a good resource for questions i have on the docs?
18:57:49 <notmorgan> yes. also you can ask fungi, tristanc, myself, gmurphy
18:57:54 <notmorgan> (the VMT)
18:58:02 <notmorgan> but openstack-security is where i'd start
18:58:14 <dstanek> #action dstanek to take the task of figuring out our nexts steps here and working with stevemar_droid to make it happen
18:58:25 * fungi is thrilled to see this starting
18:58:31 <dstanek> 2 mins.....
18:58:33 <notmorgan> you might want to make tht action more descriptive ;)
18:58:38 <lbragstad> dstanek... makin' it happen
18:58:44 <dstanek> #topic open discussion
18:58:46 <notmorgan> because you're making "what" happen
18:58:56 <notmorgan> fungi: ;)
19:00:01 <dstanek> #action dstanek to be project manager for getting identity team repos under VMT
19:00:07 <notmorgan> there we go
19:00:12 <lbragstad> lol
19:00:14 * dstanek will make it rain
19:00:21 <gagehugo> \o/
19:00:26 <notmorgan> dstanek: i... uh
19:00:41 * notmorgan goes back to lurking under a rock
19:00:45 <dstanek> that's time
19:00:46 <lbragstad> 'um yeah - we're gonna have to have you come in on Saturday'
19:00:47 <dstanek> #endmeeting