| *** markvoelker has quit IRC | 02:54 | |
| *** markvoelker has joined #openstack-interop | 04:55 | |
| *** markvoelker has quit IRC | 05:30 | |
| *** markvoelker has joined #openstack-interop | 06:26 | |
| *** georgk has joined #openstack-interop | 06:57 | |
| *** markvoelker has quit IRC | 07:00 | |
| *** pcaruana has joined #openstack-interop | 07:13 | |
| *** nikhil has quit IRC | 07:34 | |
| *** markvoelker has joined #openstack-interop | 07:57 | |
| *** pcaruana has quit IRC | 08:27 | |
| *** markvoelker has quit IRC | 08:30 | |
| *** pcaruana has joined #openstack-interop | 08:31 | |
| *** markvoelker has joined #openstack-interop | 09:28 | |
| *** markvoelker has quit IRC | 10:01 | |
| -openstackstatus- NOTICE: The CI system will be offline starting at 11:00 UTC (in just under an hour) for Zuul v3 rollout: http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html | 10:08 | |
| *** MarkBaker has joined #openstack-interop | 10:43 | |
| *** markvoelker has joined #openstack-interop | 10:58 | |
| *** mrhillsman has quit IRC | 11:03 | |
| *** MarkBaker has quit IRC | 11:04 | |
| *** mrhillsman has joined #openstack-interop | 11:05 | |
| *** markvoelker has quit IRC | 11:30 | |
| *** tobberydberg__ has joined #openstack-interop | 11:51 | |
| *** tobberydberg__ has quit IRC | 11:55 | |
| *** MarkBaker has joined #openstack-interop | 12:06 | |
| *** markvoelker has joined #openstack-interop | 12:18 | |
| -openstackstatus- NOTICE: Due to unrelated emergencies, the Zuul v3 rollout has not started yet; stay tuned for further updates | 13:05 | |
| *** zhipeng has joined #openstack-interop | 13:52 | |
| *** zhipeng has quit IRC | 14:04 | |
| *** zhipeng has joined #openstack-interop | 14:04 | |
| *** georgk has quit IRC | 14:36 | |
| *** georgk has joined #openstack-interop | 14:56 | |
| *** MarkBaker has quit IRC | 15:05 | |
| *** galstrom_zzz is now known as galstrom | 15:13 | |
| *** zhipeng has quit IRC | 15:19 | |
| *** zhipeng has joined #openstack-interop | 15:19 | |
| *** Rockyg has joined #openstack-interop | 15:56 | |
| *** zhipeng has quit IRC | 15:57 | |
| *** pcaruana has quit IRC | 15:59 | |
| Rockyg | hey! | 17:01 |
|---|---|---|
| *** lbragstad has joined #openstack-interop | 17:01 | |
| markvoelker | lbragstad: So, basically... | 17:01 |
| eglute | o/ | 17:01 |
| markvoelker | tempest.api.identity.v3.test_projects.IdentityV3ProjectsTest.test_list_projects_returns_only_authorized_projects is a test we've included in the interop guidelines in the past | 17:02 |
| markvoelker | However it got a flag thrown on it because it requires two user accounts | 17:02 |
| markvoelker | There was some discussion about maybe finding some tests for the "identity-v3-list-projects" capability that don't require two accounts and don't require admin credentials | 17:03 |
| markvoelker | Or refactoring the existing test | 17:03 |
| markvoelker | But I think luzc wasn't sure if there's been any forward motion on that. | 17:03 |
| lbragstad | it appears the second account is needed to ensure keystone doesn't leak information it shouldn't be | 17:04 |
| eglute | lbragstad is there a way to separate those two test cases? | 17:05 |
| markvoelker | Yep. I think (memory hazy, been a while since I looked at this) the discussion was maybe we need a test that just tests "can I get a list of projects" and "can I NOT get a list of other projects" was a separate thing. | 17:06 |
| markvoelker | luzC might be more current on this but I think she's not around at the moment | 17:06 |
| lbragstad | ok - this is probably a dumb question | 17:07 |
| lbragstad | is there a requirement that we can't standup a dummy user on a dummy project to ensure the other test user doesn't get the dummy project in the respone? | 17:07 |
| lbragstad | response*? | 17:07 |
| Rockyg | what about trying to get list of admin projects? That should also be a no go for a non-admin user | 17:08 |
| markvoelker | Well, think of it from the point of view of an end user who wants to verify that a given cloud (let's say, a public cloud) actually is interoperable as it claims. | 17:08 |
| markvoelker | In that case I can't necessarily set up a "dummy user" without incurring additional cost | 17:09 |
| lbragstad | what about when we test interop for instances? | 17:09 |
| markvoelker | Or in a private cloud case (say, where identity is tied to an LDAP server somewhere) I may not be allowed to create an alternate identity | 17:09 |
| * markvoelker has to run to a meeting momentarily, but eglute and rockyg may be able to continue this discussion | 17:10 | |
| lbragstad | markvoelker: thanks for the context | 17:10 |
| eglute | thanks markvoelker | 17:10 |
| eglute | lbragstad i think there is no question about extra testing, just that for interop purposes, we need the tests be tied to one user | 17:11 |
| lbragstad | can the tests be tied to a single account? | 17:12 |
| lbragstad | or project? | 17:12 |
| eglute | so how hard would it be to separate the two test cases into two separate tests? or perhaps there is a test already that tests the same? | 17:12 |
| eglute | single account single user.. | 17:12 |
| eglute | though, if it is same account/project might work. except for ldap example | 17:13 |
| lbragstad | yeah- in that case, the test needs to accept input from whoever is running it and assume things are setup | 17:13 |
| eglute | lbragstad correct | 17:14 |
| Rockyg | Yup. | 17:14 |
| *** nikhil has joined #openstack-interop | 17:14 | |
| lbragstad | i don't see a way to get around that if you want to ensure keystone is filtering sensitive information | 17:14 |
| lbragstad | i have another dumb question | 17:15 |
| eglute | we like all questions here! | 17:15 |
| lbragstad | when these tests are run, is only a username and password required? | 17:15 |
| Rockyg | no question is dumb except the one unasked | 17:15 |
| eglute | lbragstad i believe so, let me see | 17:15 |
| Rockyg | I suspect account might also be part of the equation. | 17:16 |
| Rockyg | but couldn't a user create multiple projects on a single acct, single vm? | 17:16 |
| lbragstad | i guess that depends on what you consider an account | 17:16 |
| lbragstad | is an account a instance or a project that owns resource that a user is billed for? | 17:17 |
| * lbragstad usually associates the term "account" to the later | 17:17 | |
| Rockyg | good question. it might depend on the cloud config | 17:17 |
| Rockyg | But, if the latter, couldn't ther be nested projects? | 17:18 |
| eglute | hm, i am trying to find docs for refstack setup | 17:18 |
| lbragstad | there can be nested projects | 17:18 |
| lbragstad | but - you can also have a domain (or "top-level" project) that acts similarly | 17:18 |
| Rockyg | yes. Then singlue user can create dummy user(s) in their own account and test for isolation in sub projects | 17:19 |
| eglute | lbragstad this is what ppl run to submit results to us: https://github.com/openstack/refstack-client | 17:19 |
| eglute | https://docs.openstack.org/tempest/latest/configuration.html#pre-provisioned-credentials | 17:19 |
| eglute | so one account and one user? | 17:20 |
| Rockyg | yeah. The domain user *should* be what is used for "single user, single account" but I don't think that concept is in interop tests yet. | 17:20 |
| lbragstad | https://github.com/openstack/refstack-client/blob/master/refstack_client/scripts/prep_cloud.py#L223-L244 | 17:20 |
| lbragstad | it looks like the ability exists https://github.com/openstack/refstack-client/blob/master/refstack_client/scripts/prep_cloud.py#L241-L244 | 17:21 |
| eglute | yes, it is not about the ability | 17:21 |
| eglute | it is about the requirement that only one user + account be used for interop | 17:21 |
| lbragstad | i'd imagine that is going to limit what you can include for interop tests | 17:22 |
| eglute | lbragstad it does! | 17:22 |
| lbragstad | because it won't have the necessary environment to guarantee a certain level of security | 17:22 |
| Rockyg | So, the user, though can create users within their own account, though. That should not be an extra cost to an account | 17:22 |
| eglute | lbragstad interop is not testing security, not right now anyways | 17:22 |
| Rockyg | sucks, doesn't it? | 17:23 |
| eglute | https://github.com/openstack/interop/blob/master/working_materials/interop_test_spec.rst | 17:23 |
| Rockyg | this would also be a great forum discussion... | 17:23 |
| lbragstad | so - another question that will help me understand this | 17:24 |
| eglute | go ahead! | 17:24 |
| lbragstad | why does interop want to include https://github.com/openstack/tempest/blob/master/tempest/api/identity/v3/test_projects.py#L26 as a required test? | 17:24 |
| eglute | we want to test "identity-v3-list-projects" | 17:25 |
| eglute | https://github.com/openstack/interop/blob/master/2017.09.json#L1070-L1093 | 17:25 |
| eglute | so, we need a test that would test that capability | 17:25 |
| eglute | if there is another test that is testing that, it would be great | 17:26 |
| lbragstad | ok - so do you want to test GET /v3/projects or GET /v3/auth/projects ? | 17:27 |
| lbragstad | \https://developer.openstack.org/api-ref/identity/v3/index.html#authentication-and-token-management | 17:27 |
| lbragstad | or https://developer.openstack.org/api-ref/identity/v3/index.html#projects | 17:27 |
| eglute | probably just get projects | 17:28 |
| eglute | "List projects a user belongs to" | 17:28 |
| eglute | so "get projects" is probably it | 17:29 |
| lbragstad | if that's the case, then GET /v3/auth/projects will do that | 17:29 |
| lbragstad | which returns the list of project I, as a user, have a role assignment on | 17:29 |
| eglute | cool.. and tehre is a different tempest test for it correct? | 17:29 |
| Rockyg | cool! | 17:29 |
| lbragstad | checking | 17:32 |
| eglute | thank you lbragstad | 17:32 |
| lbragstad | yeah - the test that you were looking at uses a different URL https://github.com/openstack/tempest/blob/4f5e426d10452db85925d02f35074932aae115db/tempest/lib/services/identity/v3/users_client.py#L64-L77 | 17:34 |
| lbragstad | specifically - https://github.com/openstack/tempest/blob/4f5e426d10452db85925d02f35074932aae115db/tempest/lib/services/identity/v3/users_client.py#L71 | 17:34 |
| lbragstad | it doesn't look like a test exists for that | 17:34 |
| Rockyg | I've gotta run to work, but it looks like we will get a usable solution this round or next. I love it when we all move forward through a little discussion! | 17:34 |
| Rockyg | looks like we just need to write the test, then. | 17:34 |
| lbragstad | yeah - looks like it | 17:34 |
| eglute | lbragstad thanks for looking. Do you think a new test is a possibility? | 17:35 |
| lbragstad | eglute: yeah - probably, might be worth checking with the tempest folks but i assume it would live in either https://github.com/openstack/tempest/blob/master/tempest/api/identity/v3/test_projects.py or https://github.com/openstack/tempest/blob/master/tempest/api/identity/v3/test_tokens.py since it's technically an authentication API | 17:36 |
| eglute | thanks lbragstad. This new test is on our wish list :) | 17:37 |
| lbragstad | eglute: no problem | 17:38 |
| eglute | I need to run as well. I will update our keystone patch in a bit with the above discussion. If you find a volunteer to write this new test, let us know! | 17:39 |
| *** MarkBaker has joined #openstack-interop | 17:55 | |
| *** georgk has quit IRC | 18:27 | |
| *** Rockyg has quit IRC | 18:46 | |
| *** MarkBaker has quit IRC | 19:09 | |
| *** MarkBaker has joined #openstack-interop | 20:37 | |
| *** MarkBaker has quit IRC | 21:05 | |
| *** galstrom is now known as galstrom_zzz | 22:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!