| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-09 | |||
| 10:32:57 | swp20 | we have tested this change works. | |
| 10:33:48 | sean-k-mooney | well you can do it in you policy.json without the code change but that is not what the rule is for | |
| 10:34:29 | sean-k-mooney | that is for https://docs.openstack.org/api-ref/compute/?expanded=show-console-connection-information-detail#show-console-connection-information | |
| 10:36:11 | lyarwood | sean-k-mooney: the host there is the compute host right? | |
| 10:37:10 | sean-k-mooney | i think its the proxy | |
| 10:37:21 | sean-k-mooney | but it could be | |
| 10:45:13 | swp20 | sean-k-mooney: how can i do in policy.json? does the instance's own donnot has the permission? | |
| 10:49:26 | sean-k-mooney | this is what i would have used in the past https://docs.openstack.org/api-ref/compute/?expanded=get-vnc-console-os-getvncconsole-action-deprecated-detail#get-vnc-console-os-getvncconsole-action-deprecated | |
| 10:49:42 | sean-k-mooney | that will give you the console url and the auth token | |
| 10:51:21 | sean-k-mooney | the newer way woudl be to use https://docs.openstack.org/api-ref/compute/?expanded=create-console-detail#create-console | |
| 10:53:08 | swp20 | this is no what we want. | |
| 10:53:57 | sean-k-mooney | swp20: to override the policy in policy.json you just do "rule name":["rules"] | |
| 10:54:43 | sean-k-mooney | swp20: it is what you said your customer wanted the creaqte api will return a new auth token/url for the server console | |
| 10:56:36 | swp20 | we have two platform A and B, A platform want use the console token to visit the instance on B platform, we need the host and port with the api https://docs.openstack.org/api-ref/compute/?expanded=show-console-connection-information-detail,create-console-detail#show-console-connection-information | |
| 10:57:17 | sean-k-mooney | swp20: why does A not just use the create api on b to get the url and token | |
| 10:57:25 | sean-k-mooney | swp20: is A unwaware of the server uuid | |
| 10:57:50 | swp20 | yes, A is unware of the server uuid. | |
| 10:58:52 | sean-k-mooney | i see well given the console_token is not intended to be used by normal users as a handel to identify a server im not conviced we should make that change in code | |
| 10:58:58 | swp20 | or A use no admin account. | |
| 10:59:09 | sean-k-mooney | you can do it locally on your cloud though | |
| 10:59:21 | sean-k-mooney | A presumable owns the server | |
| 10:59:24 | sean-k-mooney | correct | |
| 11:00:31 | swp20 | with the new policy rule, dose the system_reader has the permission? | |
| 11:01:09 | sean-k-mooney | in the patch you added | |
| 11:02:20 | swp20 | not in the patch. i find the rule change to SYSTEM_READER after U. | |
| 11:02:21 | sean-k-mooney | no it does no tsupport the new project scopes and roles | |
| 11:02:23 | sean-k-mooney | check_str='is_admin:True or project_id:%(project_id)s', | |
| 11:03:25 | sean-k-mooney | system_reader will not allow the owner of the token to use that endpoint no | |
| 11:03:56 | swp20 | ack, thanks. | |
| 11:04:04 | sean-k-mooney | swp20: this api endpoint was only intended to help admins debug console issues | |
| 11:04:48 | swp20 | but maybe the user has the requirement. | |
| 11:05:39 | sean-k-mooney | how does A get the console token for the server on B | |
| 11:06:06 | sean-k-mooney | the console tokens expire and are only valid for a short period of time so they are not ment to be used to identify the server | |
| 11:07:04 | sean-k-mooney | the default token time to live is 10 minutes https://docs.openstack.org/nova/latest/configuration/config.html#consoleauth.token_ttl | |
| 11:07:09 | swp20 | and the doc has no desciption. | |
| 11:07:58 | swp20 | i will ask the client what's his scenes. | |
| 11:08:55 | swp20 | i rememered, they just want to visit the instance through host and port. | |
| 11:09:23 | sean-k-mooney | well a normal end user shoudl not know the host on which the instnace is running | |
| 11:09:37 | sean-k-mooney | unless its a private cloud that is a pretty big security risk | |
| 11:10:11 | swp20 | yeah, it's a really a private cloud.:') | |
| 11:11:08 | sean-k-mooney | the sample policy.json is rendered here https://docs.openstack.org/nova/latest/configuration/sample-policy.html | |
| 11:11:57 | sean-k-mooney | they just need to put that in /etc/nova/policy.json and uncomment #"os_compute_api:os-console-auth-tokens": "rule:system_reader_api" | |
| 11:12:03 | sean-k-mooney | then update the rule | |
| 11:12:11 | swp20 | got it, thanks. | |
| 11:13:55 | sean-k-mooney | just make sure you customer is aware of the console auth token ttl and the fact that in theory the tokens could be resused | |
| 11:14:06 | sean-k-mooney | its very unlikely but it can happen | |
| 11:14:29 | swp20 | yeah, right. | |
| 11:14:44 | sean-k-mooney | if they are storing the token in a db somewhere and expecting to be able to use it days later its going to break there usecase | |
| 11:16:17 | swp20 | ack | |
| 11:17:40 | swp20 | i'll abandon this patch and talk to my customer. | |
| 12:45:35 | opendevreview | Stephen Finucane proposed openstack/nova master: requirements: Add typing-paramiko https://review.opendev.org/c/openstack/nova/+/795533 | |
| 12:45:47 | stephenfin | gate is down - we need that (and the related requirements fix) to unblock it ^ | |
| 12:46:24 | stephenfin | s/down/broken/ | |
| 12:49:01 | opendevreview | Stephen Finucane proposed openstack/nova master: requirements: Add types-paramiko https://review.opendev.org/c/openstack/nova/+/795533 | |
| 13:03:19 | lyarwood | stephenfin: Why the Depends-On? | |
| 13:03:36 | stephenfin | because we need to get it in u-c before the requirements job will pass, no? | |
| 13:06:27 | lyarwood | stephenfin: ah does that actually fail if we don't have a uc for a given test-requirement? | |
| 13:06:36 | lyarwood | TIL | |
| 13:06:39 | stephenfin | I'm pretty sure it does, yeah | |
| 13:08:33 | amodi | lyarwood: hi, can u help out with the issue in https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/786979, when u can. i don't have a devstack env to debug | |
| 13:08:50 | lyarwood | stephenfin: requirements-check looks like it's failing in the nova change | |
| 13:09:18 | lyarwood | ERROR: Package 'types-paramiko' is used in test-requirements.txt but not in lower-constraints.txt | |
| 13:09:30 | stephenfin | drat, will fix | |
| 13:10:09 | gibi | stephenfin: what is the way to reproduce the issue? I run tox -e mypy -r locally but it passes on nova master | |
| 13:10:10 | lyarwood | amodi: looking | |
| 13:11:26 | stephenfin | gibi: that did the trick for me. Only odd thing for me is the use of Python 3.9 | |
| 13:11:30 | stephenfin | since it's F34 | |
| 13:11:50 | opendevreview | Stephen Finucane proposed openstack/nova master: requirements: Add types-paramiko https://review.opendev.org/c/openstack/nova/+/795533 | |
| 13:11:55 | stephenfin | lyarwood: ^ | |
| 13:11:57 | gibi | gibizer@riverbed:~/upstream/git/nova [master] [000] [15:09:30] | |
| 13:12:01 | gibi | $ source .tox/shared/bin/activate | |
| 13:12:03 | gibi | gibizer@riverbed:~/upstream/git/nova (shared)[master] [000] [15:11:46] | |
| 13:12:07 | gibi | $ python --version | |
| 13:12:09 | gibi | I use python 3.9 too | |
| 13:12:12 | gibi | Python 3.9.2 | |
| 13:12:14 | gibi | gibizer@riverbed:~/upstream/git/nova (shared)[master] [000] [15:11:48] | |
| 13:12:22 | stephenfin | odd | |
| 13:12:30 | stephenfin | here's the first failing job I saw https://review.opendev.org/c/openstack/nova/+/778547 | |
| 13:12:36 | stephenfin | look at the pep8 env | |
| 13:13:35 | sean-k-mooney | stephenfin: what is types-paramiko used for | |
| 13:13:42 | stephenfin | type hints for paramiko | |
| 13:13:51 | sean-k-mooney | which is what the ssh lib we use | |
| 13:13:56 | stephenfin | correct | |
| 13:14:13 | sean-k-mooney | hum its not really a test-requireemnt is it | |
| 13:14:27 | stephenfin | it is. mypy isn't a runtime dependency | |
| 13:14:27 | sean-k-mooney | oh for the mypy job? | |
| 13:14:33 | sean-k-mooney | ok | |
| 13:15:19 | sean-k-mooney | stephenfin: did you ever add mypy to pre-commit? | |
| 13:15:37 | stephenfin | not yet, no. Just haven't set aside the time to figure it out | |
| 13:15:46 | sean-k-mooney | no worries | |
| 13:16:19 | gibi | I cannot reproduce it with pep8 env either. but it seem my machine installs a bit older mypy than the gate job | |
| 13:19:10 | tosky | melwitt: I think there is a chicken-and-egg problem with the backports, you may either need to squash them (but maybe that would be too much) or set the failing legacy job in the first patch to non-vpting, to have it replaced with a native one with one of the newer patches | |
| 13:19:30 | gibi | stephenfin: OK it needs a new mypy version to | |
| 13:19:31 | gibi | o | |
| 13:19:40 | lyarwood | amodi: updated, can you build a devstack env and get this passing before you push another revision? | |
| 13:20:09 | gibi | stephenfin: it does not fail with mypy==0.812 but it fails with mypy==0.901 | |
| 13:20:51 | stephenfin | hmm, good spot. I saw the release date on types-paramiko was pretty recent so I figured that was it | |
| 13:20:59 | stephenfin | I'll see if I can figure out what changed | |
| 13:21:19 | lyarwood | so we could cap mypy to unblock the gate instead right? | |
| 13:21:20 | amodi | lyarwood: um, i havent deployed one in a long time and how would i deploy with these parameters, ill hv to figure out | |