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