| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-03-27 | |||
| 01:05:05 | mrhillsman | and OS_TOKEN as an option | |
| 01:05:32 | mrhillsman | and then - if i understand right - gophercloud needs to do the same essentially | |
| 01:05:39 | adriant | mrhillsman: so easy fix in the provide then | |
| 01:05:45 | adriant | provider* | |
| 01:05:49 | mrhillsman | for the provider yeah | |
| 01:06:09 | mrhillsman | looks like | |
| 01:06:43 | adriant | and that shouldn't need a change in gophercloud | |
| 01:07:02 | adriant | although we do want to add better clouds.yaml support there too | |
| 01:07:28 | mrhillsman | https://github.com/gophercloud/gophercloud/blob/master/auth_options.go | |
| 01:07:46 | mrhillsman | well, gophercloud will need to change | |
| 01:11:03 | adriant | although on the auth front... I have to apologise in advance because I'm probably going to end up adding a lot of extra complexity once https://review.openstack.org/#/c/553670 is merged and implemented | |
| 01:11:10 | adriant | mordred: ^ don't hate me too much :P | |
| 01:11:54 | adriant | but we need a much much better way of doing multi-method auth across all of OpenStack | |
| 08:44:50 | openstackgerrit | Romain Acciari proposed openstack-infra/shade master: create_subnet: Add filter on tenant_id if specified https://review.openstack.org/556782 | |
| 12:57:35 | openstackgerrit | Romain Acciari proposed openstack-infra/shade master: create_subnet: Add filter on tenant_id if specified https://review.openstack.org/556782 | |
| 15:00:35 | openstackgerrit | Merged openstack/openstacksdk master: add lower-constraints job https://review.openstack.org/556173 | |
| 21:41:46 | openstackgerrit | Hongbin Lu proposed openstack/python-openstackclient master: Disallow setting default on internal network https://review.openstack.org/539303 | |
| 21:41:58 | openstackgerrit | Hongbin Lu proposed openstack/python-openstackclient master: Add option '--mtu' to network create/set https://review.openstack.org/540530 | |
| #openstack-sdks - 2018-03-28 | |||
| 03:44:39 | openstackgerrit | Logan V proposed openstack/os-client-config master: Add Limestone Networks vendor info https://review.openstack.org/557139 | |
| 04:17:13 | mrhillsman | adriant see - https://github.com/gophercloud/utils/pull/26 | |
| 04:17:25 | mrhillsman | generally quick response :) | |
| 04:18:10 | mrhillsman | you may be able to help push it through by reviewing/trying it even though jtopjian may not merge it until after jrperritt review | |
| 04:25:59 | adriant | mrhillsman: looks good, code (despite not entirely understanding go) makes sense. | |
| 04:26:27 | mrhillsman | ++ | |
| 04:28:08 | adriant | mrhillsman: and did you file a bug to terraform for the OS_TOKEN value? | |
| 04:28:31 | mrhillsman | i did not | |
| 04:28:45 | adriant | it might also be worth asking terraform/gophercloud peeps why gophercloud and terraform both differently handle environment variables. | |
| 04:28:48 | mrhillsman | jtopjian maintains that as well | |
| 04:29:48 | mrhillsman | unfortunately i do not know go well enough to know | |
| 04:29:58 | adriant | mrhillsman: want me to submit that bug and potentially ask at the same time? | |
| 04:30:06 | mrhillsman | i just started working on learning it about a month ago | |
| 04:30:24 | mrhillsman | yeah, i think you should and reference the issue and pr | |
| 04:30:29 | adriant | kk | |
| 04:30:35 | mrhillsman | thx adriant | |
| 05:31:56 | adriant | mrhillsman: https://github.com/terraform-providers/terraform-provider-openstack/issues/271 | |
| 05:35:42 | adriant | mordred, dtroyer: what exactly is the precedence between: domain_id vs user_domain_id, and project_domain_id ? And the same with domain_name vs user_domain_name, and project_domain_name ? | |
| 05:36:46 | adriant | I'd assume (and probably incorrectly) that domain_id comes first in our tools and then if one of the other two is set, they take precedence? | |
| 05:38:08 | adriant | mordred: does os-client-config even use OS_DOMAIN_ID and OS_DOMAIN_NAME or the user/project specific ones? I may take a gander at the code | |
| 05:38:11 | mrhillsman | cool, thanks for leading the charge on this adriant | |
| 05:38:36 | adriant | mrhillsman: np | |
| 05:38:58 | adriant | mrhillsman: with MFA slowly becoming a thing in openstack token auth in these tools will be VERY important | |
| 05:39:03 | adriant | so it needs to work | |
| 05:39:19 | adriant | because screw entering your password + MFA things for every commands | |
| 05:39:23 | adriant | that way madness lies | |
| 05:40:09 | adriant | I want a nice easy way to auth in the CLI, save me auth'd token somewhere, and then use that, and ideally have that experience consistent. | |
| 05:40:31 | mrhillsman | willing to bet quite a few folks are going to be happy as a result | |
| 08:10:30 | openstackgerrit | Chen Hanxiao proposed openstack/python-openstackclient master: Add --image-property parameter in 'server create' https://review.openstack.org/535664 | |
| 09:12:52 | openstackgerrit | Chris Dent proposed openstack/api-wg master: Add guidance on needing cache-control headers https://review.openstack.org/550468 | |
| 09:22:52 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/553257 | |
| 10:02:31 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/553257 | |
| 10:37:02 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/553257 | |
| 13:55:58 | mordred | adriant: the user and project versions | |
| 13:56:30 | mordred | adriant: OS_DOMAIN_ID and OS_DOMAIN_NAME _can_ be used, but they actually commuicate different information than OS_PROJECT_DOMAIN_NAME and OS_USER_DOMAIN_NAME | |
| 13:56:57 | mordred | adriant: OS_DOMAIN_ID and OS_DOMAIN_NAME (or, rather, the keystoneauth parameters domain_name and domain_id) are used to create a domain-scoped token | |
| 13:57:54 | mordred | adriant: so, domain_name is not a way to set domain for both user and project - it has a whole other meaning | |
| 13:58:28 | mordred | adriant: I *think* somewhere (it might be python-openstackclient) there was an addition of default_domain_name - that could be used to set domain name once for both user and project | |
| 14:00:29 | mordred | adriant, mrhillsman: also - token auth is not the answer for api access for MFA clouds ... I'd actually argue that any time anyone (who is not already an openstack service) directly uses token auth something else has fundamentally broken | |
| 14:01:00 | mordred | adriant: the answer for API access for MFA is the new App Credential support that landed in Queens | |
| 14:01:12 | mordred | THAT SAID - obviously token auth should work - and if it doesn't we should fix it | |
| 14:59:20 | openstackgerrit | Sami Makki proposed openstack/python-openstackclient master: Fix the `role implies list` command. https://review.openstack.org/557359 | |
| 15:25:05 | EmilienM | dtroyer: do you think it would be possible to cut a tag on osc (based on latest patch that landed: https://review.openstack.org/#/c/553374/)? It's currently blocking TripleO to move forward in Rocky | |
| 18:39:57 | openstackgerrit | Merged openstack/keystoneauth master: Be more helpful when version discovery fails https://review.openstack.org/554044 | |
| 18:56:37 | dtroyer | mordred: having your +1 on https://review.openstack.org/557479 (DevStack, one more SDK rename) might be nice | |
| 18:57:01 | dtroyer | it's why osc's -tips jobs are failing | |
| 19:05:19 | mordred | dtroyer: oh poo. sorry - I thought I'd gotten them all | |
| 21:22:27 | adriant | mordred: ty! That makes more sense, if not also being confusing... | |
| 21:24:14 | mordred | adriant: I would have liked them better if they had been called "realm" I think | |
| 21:24:27 | mordred | adriant: but yeah | |
| 21:24:32 | adriant | domains are already projects, but.. the painful and confusing fact that you can scope to a domain, and a project that is a domain... | |
| 21:24:36 | adriant | is evil | |
| 21:24:43 | adriant | EVIL | |
| 21:25:24 | adriant | and as it turns out by giving yourself a role assignment on the same domain/project with both scopes breaks keystone :P | |
| 21:25:38 | adriant | you now have a role assignment you can't remove! | |
| 21:27:01 | mordred | yay! | |
| 21:27:11 | adriant | and mordred: regarding tokens being the answer to MFA. I disagree that appcreds are the answer. When you're using the CLI you don't really want to use app creds. For services, yes, and then you wouldn't do MFA. | |
| 21:27:32 | adriant | but for using your own account and needing to do stuff... having to provide a password+totp every time is a nope | |
| 21:28:04 | adriant | so basically with my own CLI use, I do it like horizon does. Auth first, store token, use APIs. | |
| 21:28:21 | adriant | and MFA in horizon will do the same | |
| 21:28:57 | adriant | you front load the MFA, and then once you have a token, everything just works. | |
| 21:29:23 | mordred | adriant: what happens when your token expires? | |
| 21:29:29 | adriant | I get a new one | |
| 21:29:45 | adriant | horizon does the same :P | |
| 21:29:48 | adriant | it logs me out | |
| 21:29:48 | mordred | nod | |
| 21:29:54 | mordred | well - yah - but horizon is different :) | |
| 21:30:26 | adriant | but using a command line utility is not different than using horizon really | |
| 21:30:27 | mordred | it's possible that I have a warped view of cloud interactions as well | |
| 21:30:50 | adriant | you have a token based session, but in the case of the cli, it's one token per command | |
| 21:31:06 | adriant | that's a lot of tokens | |
| 21:31:10 | mordred | adriant: my typical usage locally is either an ansible playbook, or python loaded in a repl | |
| 21:32:07 | mordred | so I guess I usually tend to behave more like an automated service than like an interactive user ... | |
| 21:32:26 | adriant | yeah, and I use my silly interpreter thing, but off the cli | |
| 21:32:32 | mordred | in any case - you make good points, so I will stop telling people they're wrong when they use token directly :) | |
| 21:33:32 | adriant | basically one of the things I'll end up doing as part of the MFA work in keystone is an eventual follow up to the openstackclient that adds support for catching and handling the auth-receipts. | |
| 21:33:44 | adriant | either into an interactive set of prompts to ask for MFA details | |
| 21:34:00 | adriant | or at least just a good error output of what methods were missing | |
| 21:34:25 | adriant | with a potential extra command added to the openstack cli that authenticates you, and sets/unsets the right values needed for token auth for future commands | |
| 21:34:31 | EmilienM | would it be possible to have a release of osc once https://review.openstack.org/557479 is merged? | |
| 21:36:01 | adriant | mordred: so MFA related interactions with the openstackcli consist of: "openstack authenticate" followed by an interactive MFA prompt or two, and then following commands work off token auth. | |
| 21:36:31 | adriant | maybe, we need to work out what makes sense once the auth-receipt stuff is implemented in keystone and keystoneauth | |