18:02:53 <stevemar> #startmeeting keystone
18:02:54 <ayoung> now xek is a nickname I can get behind
18:02:54 <openstack> Meeting started Tue Mar 15 18:02:53 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:57 <openstack> The meeting name has been set to 'keystone'
18:02:59 <shaleh> stevebaker: geoffarnold is not coming back in a while. He went of to a IoT startup
18:03:11 <stevemar> shaleh: coolio
18:03:15 <stevemar> i'll trim it
18:03:27 <stevemar> agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:03:38 <stevemar> #topic Keystone RC status
18:03:45 <stevemar> #link https://launchpad.net/keystone/+milestone/mitaka-rc1
18:04:04 <ayoung> love the number of non-core stepping up to fix bugs
18:04:13 <morgan> just do cleanup on the ping notices at the start of the cycle
18:04:19 <morgan> easiest way to do cleanup
18:04:25 <stevemar> i went ahead and marked a few bugs with rc1 target dates
18:04:31 <stevemar> i find that easier than the tags
18:04:50 <stevemar> i don't think any are show-stoppers, but a few would be nice to fix by end of week, then we can cut RC1
18:06:06 <stevemar> most are in progress, and can be viewed here: https://review.openstack.org/#/dashboard/?foreach=&title=Keystone+Office+Hours&patches+that+don%27t+have+negative+feedback+and+close+a+bug=project%3A%22%5Eopenstack%2F%40keystone%40%22+%2Dproject%3Aopenstack%2Fpuppet%2Dkeystone+is%3Aopen+label%3AVerified%2B1+%2Dlabel%3ACode%2DReview%3C%3D%2B2%2Cself+%2Dlabel%3ACode%2DReview%3C%3D%2D1+%2Dlabel%3AVerified%2D1+%2Dlabel%3AWo
18:06:07 <stevemar> rkflow%2D1+AND+%28message%3A%22Closes%2D%22+OR+message%3A%22closes%2D%22%29&bug+related+patches+that+don%27t+have+negative+feedback=project%3A%22%5Eopenstack%2F%40keystone%40%22+%2Dproject%3Aopenstack%2Fpuppet%2Dkeystone+is%3Aopen+label%3AVerified%2B1+%2Dlabel%3ACode%2DReview%3C%3D%2B2%2Cself+%2Dlabel%3ACode%2DReview%3C%3D%2D1+%2Dlabel%3AVerified%2D1+%2Dlabel%3AWorkflow%2D1+AND+%28message%3A%22Closes%2D%22+OR+messag
18:06:07 <stevemar> e%3A%22Partial%2D%22+OR+message%3A%22Related%2D%22+OR+message%3A%22closes%2D%22+OR+message%3A%22partial%2D%22+OR+message%3A%22related%2D%22%29&bug+related+patches+that+need+love=project%3A%22%5Eopenstack%2F%40keystone%40%22+%2Dproject%3Aopenstack%2Fpuppet%2Dkeystone+is%3Aopen+%2Dlabel%3ACode%2DReview%3C%3D%2B2%2Cself+label%3ACode%2DReview%3C%3D%2D1+AND+%28message%3A%22Closes%2D%22+OR+message%3A%22Partial%2D%22+OR+me
18:06:08 <stevemar> ssage%3A%22Related%2D%22+OR+message%3A%22closes%2D%22+OR+message%3A%22partial%2D%22+OR+message%3A%22related%2D%22%29
18:06:10 <bknudson> wow!
18:06:11 <stevemar> well that didn't work
18:06:17 <dstanek> whoa
18:06:22 <morgan> stevemar: yeah that wont work.
18:06:28 <samueldmq> I am copying and pasting the bits together
18:06:30 <morgan> need a url shortener or something
18:06:30 <samueldmq> wait
18:06:35 <samueldmq> :-)
18:06:39 <stevemar> https://goo.gl/d7yp6B
18:06:42 <stevemar> there we go
18:06:43 <samueldmq> stevemar: ++
18:06:45 <rodrigods> haha
18:07:06 <stevemar> saving it as a bookmark doesn't quite help :P
18:07:36 <gyee> stevemar, would love to see this one added to the list, https://bugs.launchpad.net/keystone/+bug/1557238
18:07:36 <openstack> Launchpad bug 1557238 in OpenStack Identity (keystone) "mapping yield no valid identity result in HTTP 500 error" [High,New]
18:07:38 <shaleh> I have been beating up on the "need love" section. The dates are all fairly recent.
18:07:46 <stevemar> gyee: yep, that is a must fix
18:07:58 <gyee> stevemar, I am working on a fix
18:08:11 <stevemar> would also be nice to see bug 1526462 and bug 1555830 fixed too
18:08:11 <openstack> bug 1526462 in OpenStack Identity (keystone) "Need support for OpenDirectory in LDAP driver" [Medium,In progress] https://launchpad.net/bugs/1526462 - Assigned to Andrey Grebennikov (agrebennikov)
18:08:12 <openstack> bug 1555830 in python-openstackclient "'service provider show' returns a service provider when queried with wrong sp_id" [Medium,In progress] https://launchpad.net/bugs/1555830 - Assigned to Steve Martinelli (stevemar)
18:08:34 <stevemar> i'll be poking people for reviews and fixes this week
18:08:38 <stevemar> looking forward to cutting rc1
18:08:56 <stevemar> any questions about rc1? any super important stuff we're not including?
18:09:18 <shaleh> if Jamie will drop his request password in CLI review and Boris drops his two reviews all of the "need love" are now current as of 2016
18:09:25 <bknudson> the gate's not broken so I think we're doing good
18:09:32 <shaleh> bknudson: ++
18:09:37 <stevemar> bknudson: your bar is low
18:09:45 <samueldmq> stevemar: when do you want to cut it?
18:09:55 <stevemar> samueldmq: any time before friday evening :P
18:10:11 <topol> bknudson is soooo snarky :-)
18:10:17 <stevemar> we could always cut rc2 next week
18:10:30 <samueldmq> stevemar: ++
18:10:44 <stevemar> i think this week is march break for folks, so we might get impacted a bit
18:10:48 <gyee> easy as cutting cheese
18:10:54 <morgan> shaleh: password in cli?
18:11:00 <bknudson> march break must be a canada thing
18:11:12 <stevemar> bknudson: damn canucks
18:11:21 <bknudson> it's march madness here
18:11:25 <shaleh> morgan: yes, his patch which added the password prompt which you and I poo'ed on.
18:11:35 <shaleh> morgan: it was never abandoned.
18:11:36 <stevemar> shaleh: that's not keystone server side though
18:11:36 <jamielennox> is that still open?
18:11:37 <morgan> shaleh: oh the one i hit with a -2? ;)
18:11:48 <shaleh> jamielennox: yes
18:12:11 <ayoung> spring break here.  Which is dumb as it is technically still winter
18:12:13 <shaleh> stevemar: it is on your list :-)
18:12:18 <stevemar> shaleh: :O
18:12:35 <stevemar> shaleh: must impact several projects then, doh
18:13:11 <stevemar> anywho i'll be trying to close these out, help is appreciated :)
18:13:27 <stevemar> next topic
18:13:32 <stevemar> #topic Devstack keystone deploy
18:13:36 <stevemar> bknudson: your're up
18:13:44 <stevemar> bknudson: this work has been freaking awesome
18:13:58 <bknudson> so I proposed a change to devstack to run keystone under uwsgi while apache proxies using mod_proxy_uwsgi
18:14:07 <bknudson> we've got several deploy options now.
18:14:16 <topol> bknudson that is very cool
18:14:19 <bknudson> which I'd like to whittle down once we've seen that things are stable
18:14:30 <bknudson> we'll get rid of eventlet in N
18:14:37 <stevemar> we've got eventlet / apache / uwsgi / uwsgi_apache
18:14:40 <gyee> bknudson, we have separate log files under uwsgi or that configurable?
18:14:56 <bknudson> devstack has separate log file under uwsgi
18:15:12 <bknudson> logging is almost infinitely configurable so you could set up syslog if you want
18:15:18 <gyee> like /var/log/apache2
18:15:34 <bknudson> ideally we'll eventually get to 1 server
18:15:36 <gyee> or now I have to look for stuff in say /var/log/uwsgi or something
18:15:42 <stevemar> this is great because we can show operators that keystone can is tested and can be deployed many ways, and it's safe to remove eventlet
18:15:49 <shaleh> bknudson: has that devstack change landed or do we still need to pull it?
18:15:59 <edmondsw> I'd really like to see this go in: https://bugs.launchpad.net/keystone/+bug/1553216
18:15:59 <openstack> Launchpad bug 1553216 in OpenStack Identity (keystone) "keystone-manage bootstrap does not work for non-SQL identity drivers" [Medium,In progress] - Assigned to Kristi Nikolla (knikolla)
18:15:59 <stevemar> shaleh: most are landed
18:16:00 <bknudson> shaleh: the devstack change has not landed
18:16:12 <ayoung> under uwsgi is there any SAML  support?  Can we test Federation in devstack?
18:16:14 <bknudson> so comments now are welcome
18:16:26 <stevemar> shaleh and others: https://review.openstack.org/#/c/291817/
18:16:32 <bknudson> ayoung: under uwsgi there would not be SAML support
18:16:35 <morgan> ayoung: you would still use apache
18:16:43 <bknudson> ayoung: but mod_proxy_uwsgi should work
18:16:48 <morgan> ayoung: for saml, uwsgi replaces eventlet/mod_wsgi
18:16:54 <jamielennox> bknudson: why would there be no saml support?
18:16:57 <morgan> ayoung: what bknudson said
18:17:04 <stevemar> ayoung: not when deployed only under uwsgi (which is a crummy stand alone web server anyway)
18:17:12 <bknudson> jamielennox: you need some kind of plugin to accept the saml. uwsgi doesn't have it
18:17:17 <ayoung> stevemar, I just want the testability
18:17:33 <morgan> nginx also could do saml now [it has a shib module]
18:17:34 <stevemar> ayoung: it should be testable under the uwsgi_apache configuration
18:17:41 <shaleh> ayoung: try his patches and report success/fail :-)
18:17:42 <ayoung> stevemar, fair enough
18:17:43 <morgan> and uwsgi is natively supported by nginx
18:17:43 <jamielennox> bknudson: yes, but mod_proxy_uwsgi should forward envs to the uwsgi application
18:18:06 <bknudson> jamielennox: right (I thought you were asking about uwsgi http)
18:18:16 <jamielennox> bknudson: i have confirmed this as far as doing SetEnvs in the apache config, but i don't have a real test yet
18:18:19 <bknudson> we've got a uwsgi http deployment too
18:18:50 <jamielennox> oh, i just assumed we were talking behind apache because of $subject
18:18:56 <bknudson> anyway, the plan would be to get rid of the uwsgi http deployment and do the proxy instead of that one
18:19:05 <stevemar> yep
18:19:19 <stevemar> nice work on that stuff bknudson
18:19:20 <bknudson> and maybe we can even convince other api servers to work this way
18:19:29 <stevemar> it provides me with the ammo i need to remove eventlet
18:19:38 <shaleh> bknudson: once we show it works....
18:19:51 <bknudson> we've been running the uwsgi test for a while now and it seems stable
18:19:55 <jamielennox> it's a good solution for the mod_wsgi virtualenv problem
18:20:06 <jamielennox> for the people stuck on eventlet
18:20:13 <bknudson> so I'll add a job for uwsgi-proxy once it's merged in devstack
18:20:24 <shaleh> this is good work bknudson. I have been wanting to find time for this since I started hacking on keystone.
18:20:38 <stevemar> bknudson: want to remove the regular uwsgi job?
18:20:39 <gyee> shaleh, works as somebody running it in production :-)
18:20:48 <bknudson> shaleh: take a look at the reviews and see if it's what you're were planning on
18:20:53 <shaleh> gyee: yeah, or at least closer to it.
18:21:08 <bknudson> stevemar: the regular uwsgi should go away once we've got uwsgi-proxy
18:21:11 <shaleh> bknudson: shall do.
18:21:21 <stevemar> bknudson: alrighty
18:21:29 <jamielennox> bknudson: so a problem i'm found is that the ubuntu 14.04 uwsg_proxy is really old and won't work with the one from pip
18:21:41 <bknudson> jamielennox: really? worked for me.
18:21:45 <stevemar> so if you're interested look up bknudson's reviews
18:21:56 <bknudson> jamielennox: I noticed it was old and didn't support unix socket :(
18:21:58 <stevemar> jamielennox: i pulled it down and it worked for me on 14.04
18:22:08 <jamielennox> stevemar: intsalling from pip or apt?
18:22:26 <jamielennox> apt has some 1.x version, and apache is too old for the unix socket thing
18:22:28 <bknudson> uwsgi_proxy is from apt, uwsgi is from pip
18:22:33 <stevemar> jamielennox: whatever bknudson's patch doe
18:22:33 <stevemar> s
18:22:50 <jamielennox> damn, i got super strange errors for that which i attributed to the difference
18:23:10 <jamielennox> mine is running via emperor, rather than directly but that shouldn't matter
18:23:14 <bknudson> unix socket would be ideal but we can live with localhost until the distro is newer
18:23:29 <morgan> bknudson: 14.04 supports the socket doesn't it?
18:23:30 <bknudson> emperor seemed like overkill
18:23:46 <morgan> oh wait uwsgi_proxy is weird.
18:23:50 <bknudson> morgan: I assume the socket connection has been there since the beginning
18:23:56 <gyee> if you are doing proxying, why would you want to run on anything other than localhost?
18:24:03 <jamielennox> bknudson: for devstack it is because you want things in screen, for ~prod emperor seems right
18:24:10 <morgan> gyee: unix domain socket = better than localhost
18:24:17 <morgan> for uwsgi/uwsgi_proxy
18:24:23 <stevemar> getting a bit off topic, if you're having trouble with the patch we can talk about it in -keystone
18:25:02 <stevemar> #topic Keystone Client Functional tests -- samueldmq
18:25:11 <stevemar> samueldmq: sir
18:25:42 <tsymanczyk> \o
18:25:43 <samueldmq> hi
18:25:55 <samueldmq> so, goal is to implement functional tests in ksclient
18:26:10 <samueldmq> later on, this will serve to improve our backward compatibility for client libraries
18:26:18 <samueldmq> #link https://review.openstack.org/#/c/226157/
18:26:47 <samueldmq> we've got the base stuff merged, which basically instatiates the ksclient instances based on os-cloud-config
18:26:48 <stevemar> looks like your changes are here: https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:client-functional-tests
18:27:01 <samueldmq> which looks for clouds.yaml and envvars
18:27:04 <bknudson> are these tests in gate already?
18:27:13 <samueldmq> stevemar: yes, the changes we have now are in that topi
18:27:24 <samueldmq> bknudson: yes, we do have a gate job for functioanl ksclient tests
18:27:26 <stevemar> bknudson: there is a functional test job that does the existing tempest tests
18:27:48 <samueldmq> e.g look at patch 293048
18:27:54 <samueldmq> and see gate-keystoneclient-dsvm-functional
18:28:04 <stevemar> the job does a dsvm setup
18:28:13 <stevemar> samueldmq: the tests are run as admin right?
18:28:37 <samueldmq> stevemar: afaik yes, that's the creds put in clouds.yaml
18:28:53 <rodrigods> samueldmq, stevemar the job itself gets the env vars
18:28:55 <bknudson> here's an example running the new tests -- http://logs.openstack.org/06/289306/7/check/gate-keystoneclient-dsvm-functional/b86148a/console.html#_2016-03-14_18_16_59_747
18:29:21 <samueldmq> bknudson: ++
18:29:21 <rodrigods> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/tests/functional/hooks/post_test_hook.sh#L33
18:29:24 <stevemar> so the benefit of this is testing real CRUD requests and responses
18:29:25 <rodrigods> admin admin :)
18:29:37 <samueldmq> rodrigods: nice, I haven't checked that yet
18:29:38 <stevemar> and making sure the managers and client actually work properly
18:29:56 <samueldmq> stevemar: yes, from a client perspective VS testing the http api itself
18:30:03 <rodrigods> stevemar, it is easier to test there
18:30:09 <rodrigods> than having a devstack plugin and so on
18:30:26 <stevemar> so this tests against the same setup every time
18:30:27 <rodrigods> that's how i see it besides the client + API testing
18:30:29 <samueldmq> stevemar: and also as I noted above, there is an ongoing effort for having backwards compat for libraries and clients
18:30:37 <stevemar> yep
18:30:43 <samueldmq> in which case it's super useful
18:31:10 <samueldmq> and anyone can run it by just providing a clouds.yaml or envvars
18:31:22 <shaleh> samueldmq: so this is run via tempest?
18:31:27 <rodrigods> shaleh, no
18:31:28 <stevemar> shaleh: nope
18:31:43 <bknudson> I guess it's not too important to support different deployments if it's for verifying that the client API works.
18:31:48 <stevemar> tempest is read-only and black box
18:31:57 <stevemar> bknudson: that's what i'm beginning to wonder
18:32:18 <samueldmq> shaleh: and tempest has its own client, and its goal is to test the http api
18:32:20 <stevemar> bknudson: cause on the server side, i always imagined different jobs setting up different keystone configurations and running functional tests there
18:32:23 <samueldmq> stevemar: ours is to test the client
18:32:41 <rodrigods> stevemar, ++
18:32:43 <samueldmq> bknudson: maybe, but we also allow for other to run the tests
18:32:48 <dstanek> stevemar: exactly. that's where the value is on the server
18:33:09 <stevemar> dstanek: but if we already have a suite of tests in ksc, why not add tests there
18:33:10 <raildo> stevemar: like setting different tokens types :)
18:33:12 <stevemar> anyway, details
18:33:22 <bknudson> good to have though. The unit tests are fine but they can only mock the server response and we've made mistakes there
18:33:32 <rodrigods> ++
18:33:33 <stevemar> bknudson: for sure
18:33:40 <samueldmq> hmm, so the question is, what does this buy us?
18:33:49 <samueldmq> do real tests in the client, not just mocking
18:33:57 <stevemar> samueldmq: testing without mock
18:34:01 <dstanek> stevemar: we could do that. the only thing i care about on the server side is the profiles
18:34:09 <samueldmq> yes what bknudson said
18:34:23 <stevemar> dstanek: profiles == different configurations?
18:34:49 <shaleh> so does this mean a review of current unit tests to consider which are truly unit and which should really be functional?
18:34:52 <bknudson> functional tests in keystone we will want to be able to run against any config
18:34:56 <dstanek> stevemar: we initially made the decision to not write our functional tests using ksc so that we don't tie ourselves to it
18:34:59 <dstanek> stevemar: yes
18:35:08 <navidp> stevemar,
18:35:29 <stevemar> navidp:
18:35:31 <stevemar> :)
18:35:34 <samueldmq> we could still ahve functional tests in keystone
18:35:34 <navidp> stevemar, about this https://review.openstack.org/#/c/226157/ I am getting tempest error because it is not using ksa, is there a way to make tempest to use it or get a ksa release.
18:35:39 <samueldmq> to test against the real HTTP API
18:35:50 <samueldmq> the client tests are for testing the client, not really into HTTP API details
18:36:14 <stevemar> dstanek: fair enough
18:36:16 <navidp> stevemar, the modifications i need is in this patch : https://review.openstack.org/#/c/289472/
18:36:34 <dstanek> stevemar: i don't know if that's completely valid, but that's what we decided
18:36:56 <stevemar> navidp: mind if i circle back to you in 25 minutes? i don't want to derail the meeting
18:37:05 <samueldmq> navidp: looks like it's better to discuss off-topic in #keystone or in the open-discussion topic taht will come later on ?
18:37:09 <stevemar> dstanek: i imagine we will talk about this at length at the summit
18:37:11 <samueldmq> navidp: yes, what stevemar said, thank you
18:37:15 <navidp> stevemar, ok thanks
18:37:28 <stevemar> next topic
18:37:35 <stevemar> #topic Revert change that removed the default domain creation -- stevemar
18:37:42 <navidp> stevemar, sorry
18:37:46 <stevemar> navidp: np!
18:38:03 <stevemar> i don't know about others, but i've seen quite a few questions surrounding this topic
18:38:14 <stevemar> quite a few == 3 in one week
18:38:26 <stevemar> where folks are asking "wheres my default domain"
18:38:49 <dstanek> stevemar: doesn't it get created on demand if it doesn't exist?
18:38:50 <stevemar> i guess they are installing and using the ADMIN token, and going right to the user create portion
18:38:51 <bknudson> we never guaranteed there'd be a default domain
18:39:10 <stevemar> bknudson: it's a major change in behavior though -- guaranteed or not
18:39:34 <stevemar> dstanek: not entirely...
18:39:50 <gyee> dstanek, will create it when migrating v2 data
18:39:52 <stevemar> dstanek: we made a change to include it in user/project show/list
18:40:30 <bknudson> it seems like all people use openstack for is deploying it
18:40:39 <stevemar> lol
18:40:40 <ayoung> so the error is that we are not creating it on demand in user create?
18:40:51 <stevemar> ayoung: or project create
18:41:03 <bknudson> currently it's only v2 operations that create on demand
18:41:06 <stevemar> ayoung: we used to create it after the first migration ran
18:41:15 <bknudson> I figured it was only backwards tools that would be affected
18:41:29 <ayoung> Ony in v2 operations....
18:41:42 <bknudson> would be easy enough to create on demand for v3 ops, too. Although unfortunate.
18:41:56 <bknudson> we could put out a deprecation message when created on demand
18:42:08 <gyee> bknudon, how?
18:42:13 <stevemar> bknudson: now you're thinking
18:42:22 <gyee> are we going to create every missing domain on v3 operations?
18:42:33 <stevemar> gyee: if we end up creating it, issue the message?
18:42:34 <bknudson> no, only the default domain (it's in the config file)
18:42:37 <ayoung> gyee, no, only if it matches the default in the config file
18:42:46 <jamielennox> where would you put that message?
18:42:54 <bknudson> the message goes to the keystone log
18:42:55 <jamielennox> if you do it once in the admin log it will get lost
18:43:01 <jamielennox> and you can't do it to the user
18:43:07 <ayoung> means we will never be able to delete the default domain.
18:43:15 <ayoung> It will just get recreated
18:43:20 <bknudson> this is for deploy so hopefully they're checking the keystone log at the end of their deploy
18:43:21 <gyee> that's dangerous
18:43:52 <gyee> for v3 APIs, user or project creation requires a domain_id
18:44:03 <gyee> and if domain doesn't exist, they have to create it
18:44:12 <gyee> why make the exception for default domain?
18:44:14 <stevemar> i'm okay with no making a decision here, we can always wait til next week, maybe we just need better docs
18:44:45 <bknudson> gyee: the exception is for backwards-compat until we can convince people to not rely on default domain existing
18:45:06 <samueldmq> stevemar: maybe
18:45:16 <samueldmq> stevemar: if they want to sue v3, then create the domain
18:45:23 <gyee> exactly
18:45:30 <samueldmq> default domain is only for v2 compatibility, as far as I understand it
18:45:35 <stevemar> samueldmq: yep, then deploy instructions should be updated as such
18:45:36 <gyee> v3 is a major version bump, not meant for backward compatibility
18:45:43 <rodrigods> it is used for more stuff
18:45:57 <samueldmq> stevemar: 100% agree we should check the docs
18:45:58 <stevemar> samueldmq: either create the default domain with ADMIN_TOKEN, or as part of bootstrap
18:46:18 <samueldmq> stevemar: if you're going to use v3 (and we wnat you to)
18:46:45 <stevemar> anywho, next topic
18:46:51 <stevemar> #topic parent_id representation in Liberty vs Mitaka - rodrigods
18:47:02 <stevemar> my topic can wait, whats up rodrigods
18:47:06 <rodrigods> o/
18:47:15 <rodrigods> ok... so in Liberty (and Kilo), the absence of parent was presented by parent_id = None, today it is represented by the domain_id (since the "root" is a project acting as domain)
18:47:35 <rodrigods> so... this means that *probably*, the nested quota code is broken in Cinder
18:47:47 <rodrigods> see https://review.openstack.org/#/c/285541/
18:48:05 <samueldmq> I though henrynash had worked with cinder to fix that
18:48:31 <samueldmq> rodrigods: is that the issue that previous top-lvel projects had parent_id = None and now they point to their domain (which is also a project)?
18:48:31 <rodrigods> anyway... Cinder was just an example
18:48:37 <stevemar> rodrigods: did cinder have full support for nested quotas in liberty?
18:48:46 <rodrigods> samueldmq, yes
18:48:52 <raildo> stevemar: yes
18:49:32 <stevemar> guess we need to compare the parent_id to the domain_id then?
18:49:39 <rodrigods> I can write a config in tempest to skip the tests in the stable tests
18:50:03 <rodrigods> just want your opinion if this is ok, in a API stability point of view
18:50:18 <samueldmq> henrynash told me Cinder had fixed that
18:50:26 <dstanek> rodrigods: so this was a backward incompatible change?
18:50:31 <rodrigods> dstanek, yes
18:50:34 <samueldmq> at least that was a pre-requisite to merge reseller-1
18:50:37 <stevemar> henrynash is away this week, should be back tomorrow
18:50:39 <samueldmq> because gate was failing
18:50:56 <samueldmq> stevemar: yes, but reseller-1 couldn't merge without fixing it, anyways need to check with him
18:50:56 <ayoung> raildo, you said this might  impact Quota, right?
18:51:09 <dstanek> do we need to roll it back?
18:51:18 <ayoung> and we're going to get a test which shows that or not
18:51:27 <raildo> ayoung: yes, I'm not sure that will impact, I need to test it.
18:51:37 <ayoung> Let's gate on that
18:51:39 <rodrigods> you can try to run https://review.openstack.org/#/c/285640/
18:51:48 <rodrigods> you need to setup everything in devstack first
18:51:58 <ayoung> if Cinder is OK with the change, we accept the new behavior. If Cinder breaks, we work with them to deal with it?
18:51:58 <samueldmq> dstanek: that was a question I had ... if changing the content of an API was acceptable
18:52:01 <rodrigods> didn't do that here yet, but since henrynash has fixed it
18:52:09 <raildo> probably this patch it is what samueldmq are saying: https://review.openstack.org/#/c/286775/
18:52:10 <rodrigods> we should be fine
18:52:32 <samueldmq> raildo: yes I think that's it
18:52:43 <rodrigods> but yes, the API in Mitaka incompatible with Liberty/Kilo
18:52:54 <dstanek> samueldmq: that's the thing. it may seem like just changing the value of a key, but we are changing the semantics of what the keys mean (at least that's what i get from the problem description)
18:53:19 <stevemar> dstanek: that's how i understand it
18:53:29 <ayoung> dstanek, the question is if we ever documented it
18:53:42 <ayoung> and, if we did, what did we commit to supporting
18:53:45 <samueldmq> dstanek: stevemar: I had that question when reviewing reseller-1, and I got convinced that this was acceptable somehow
18:53:53 <samueldmq> maybe we need to circle-back and re-analyze it
18:54:02 <samueldmq> we need henrynash on this I think
18:54:07 <ayoung> in this case, I would say that HMT is early enough that we can accept some wiggle room here
18:54:13 <stevemar> ayoung: yep
18:54:26 <stevemar> samueldmq: i think we're okay here, like ayoung said it's early
18:54:44 <rodrigods> great
18:55:02 <stevemar> #topic open discussion
18:55:06 <samueldmq> stevemar: okay, just saying it sounded weird to me too, to change the return (the body) of an API
18:55:07 <dstanek> is HMT declared to be experimental?
18:55:09 <ayoung> raildo, can you own not only the test, but confirming with all quota folks that the issue is real or not?
18:55:17 <rodrigods> dstanek, it is not
18:55:28 <rodrigods> was not too
18:55:33 <raildo> ayoung: sure, I'll do this, asap
18:55:34 <ayoung> stevemar, so, the Rabbit MQ deployment setup sucks.
18:55:41 <ayoung> This is not strictly a Keystone issue
18:55:52 <stevemar> ayoung: what's so sucky about it?
18:55:56 <ayoung> but, it does mean that, say, audit events could be faked
18:56:14 <stevemar> mfisch also didn't like rabbit
18:56:24 <ayoung> stevemar, its not rabbit so much as what we don't do
18:56:33 <ayoung> everything runs as a single user, single password
18:56:47 <dstanek> rodrigods: should it be so that we can make breaking changes like this?
18:57:05 <ayoung> Its not really our problem to solve, except maybe to look into how we could fix things from the Keystone side
18:57:34 <rodrigods> dstanek, never was marked as experimental, but we never had HMT tests in tempest so...
18:57:38 <stevemar> ayoung: i'm not following you completely... but it doesn't sound good
18:57:46 <ayoung> there are config options for changing things, like where to publish notifications
18:57:51 <rodrigods> dstanek, i mean, never had any tests to alarm this
18:57:55 <rodrigods> in gate
18:58:09 <ayoung> stevemar, so, it is not good, but it is a deployers problem.
18:58:22 <dstanek> rodrigods: sure, but what i'm saying is that since this is an experimental feature, we should label it as experimental
18:58:50 <ayoung> I have not run devstack in a while, but if what I am seeing is that everyone is following devstack's approach, then messaging is a very insecure
18:58:52 <bknudson> hard to be experimental when you change the project response
18:59:20 <ayoung> stevemar, here's the crux
18:59:33 <stevemar> ayoung: you are probably seeing what everyone else is, so yeah, probably insecure
18:59:37 <ayoung> we really need to be able to identify all of the readers and writers in an openstack deployment
18:59:39 <stevemar> you can change the topic very easily
18:59:44 <ayoung> and this is an identity problem
18:59:50 <gyee> ayoung, we never said devstack is secured :-)
18:59:52 <ayoung> which is basically a keystone bailywick
19:00:09 <stevemar> <1 minute to go
19:00:18 <stevemar> damn
19:00:19 <bknudson> tokens for messages, too
19:00:21 <stevemar> #endmeeting