| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2023-08-28 | |||
| 14:27:15 | chris218 | Hey so I'm using openstacksdk to manage servers through objects that persist for long time in my app, should I create Connection with openstack.connect() on demand when I want to interact with Openstack or can I save it as an attribute and close in for example __del__? | |
| 14:40:08 | opendevreview | SongSuheon proposed openstack/openstacksdk master: Implement heat 'stack event list' https://review.opendev.org/c/openstack/openstacksdk/+/892836 | |
| 15:07:38 | rladntjr4 | Hello! i want to contribute python-openstackcli. i have a few question. Is this the right place to ask questions? | |
| 15:16:22 | opendevreview | Merged openstack/openstacksdk master: identity: Add support for domain config https://review.opendev.org/c/openstack/openstacksdk/+/891681 | |
| 15:18:53 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: block storage: Add query string params for many APIs https://review.opendev.org/c/openstack/openstacksdk/+/892974 | |
| 15:19:39 | opendevreview | Stephen Finucane proposed openstack/python-openstackclient master: volume: Migrate 'volume group snapshot' commands to SDK https://review.opendev.org/c/openstack/python-openstackclient/+/892975 | |
| 15:22:15 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: [DNM] Experiment with OpenAPI schema https://review.opendev.org/c/openstack/openstacksdk/+/892161 | |
| 15:23:57 | gtema | stephenfin: I have updated openapi experiment with few more calls and few random server actions to show how it can be looking like | |
| 15:24:29 | stephenfin | ack, it's on my list to look at before EOD else tomorrow morning | |
| 15:24:35 | stephenfin | rladntjr4: it is | |
| 15:24:51 | stephenfin | just be aware that delays can be slow | |
| 15:25:29 | gtema | thanks stephenfin. I think it is now more then experiment and looks really reasonable in my eyes | |
| 15:28:05 | stephenfin | chris218: tbh, I don't think we have any guidance on that. However, many of the OpenStack services create a session once on start up and then generate a new client each time they need one | |
| 15:28:44 | stephenfin | My gut would suggest opening on demand would likely be more reliable and take you less off the beaten track that saving it and opening/closing manually | |
| 15:28:56 | stephenfin | but maybe gtema has more ideas | |
| 15:30:30 | gtema | well, I think it depends on the "how long". In principle it is ok to keep session open and I have an app that runs in the container with a session pretty much endless, but I do not manage servers this way. | |
| 15:30:59 | gtema | another example would be Zuul which also keeps the session and does activity pretty much permanently with no issues | |
| 15:31:18 | gtema | so I would rather first try to open session on demand and keep it open forever | |
| 15:32:16 | gtema | if you start facing issues - closing session should be also not a problem, but remember every re-connection is causing a new API call to the Keystone (auth_token), so there is additional "overhead" in that | |
| 15:33:45 | gtema | stephenfin - any urgent change to be included in the release? I am going to update release change once stack_export merges and it can be released today/tomorrow | |
| 15:34:05 | chris218 | so if I understand it correctly session != connection, right? so how can I create session with openstacksdk? | |
| 15:34:10 | stephenfin | for sdk? https://review.opendev.org/c/openstack/openstacksdk/+/892974 would be nice | |
| 15:34:45 | gtema | chris218: in principle it is equal, technically not, but highlevel it is | |
| 15:34:46 | stephenfin | oh, maybe also https://review.opendev.org/c/openstack/openstacksdk/+/889984 so I can continue with that work | |
| 15:35:17 | gtema | rojer | |
| 15:42:31 | rladntjr4 | i found some happen in 'server list -c ' command. The code contains a case that handles lowercase, but it does not work. | |
| 15:42:42 | rladntjr4 | so i fix it. https://review.opendev.org/c/openstack/python-openstackclient/+/892830 | |
| 15:43:01 | rladntjr4 | i wonder if this is the way you want. | |
| 15:44:20 | rladntjr4 | i think only 'server list -c ' support this features. | |
| 15:51:43 | opendevreview | kim woo seok proposed openstack/openstacksdk master: Implement stack export in openstacksdk https://review.opendev.org/c/openstack/openstacksdk/+/891249 | |
| 16:05:09 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: [WIP] Add OpenAPI invokation interface https://review.opendev.org/c/openstack/openstacksdk/+/892161 | |
| 16:09:50 | opendevreview | Artem Goncharov proposed openstack/openstacksdk master: [WIP] Add OpenAPI invocation interface https://review.opendev.org/c/openstack/openstacksdk/+/892161 | |
| 16:48:23 | andrewbogott_ | Before I start writing patches, I would like someone to read https://storyboard.openstack.org/#!/story/2010784 and confirm or deny that the problem I'm describing is an actual problem. I think in theory I'm supposed to ping gtema with this question but so far haven't had any luck with that so I'd appreciate comments from basically anyone else. | |
| 16:48:46 | andrewbogott_ | The short version of that task is: adopting clouds.yaml as the source of auth truth breaks a whole lot of admin-account-based workflows | |
| 17:06:45 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: docs: Add missing docs for identity resources https://review.opendev.org/c/openstack/openstacksdk/+/891682 | |
| 17:06:46 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: docs: Add missing docs for compute resources https://review.opendev.org/c/openstack/openstacksdk/+/891683 | |
| 17:06:46 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: docs: Add missing docs for block storage resources https://review.opendev.org/c/openstack/openstacksdk/+/891684 | |
| 17:06:47 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: compute: Add missing docstrings https://review.opendev.org/c/openstack/openstacksdk/+/891685 | |
| 17:06:47 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: block storage: Add missing docstrings https://review.opendev.org/c/openstack/openstacksdk/+/891686 | |
| 17:06:48 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: baremetal: Add missing docstrings https://review.opendev.org/c/openstack/openstacksdk/+/891687 | |
| 17:06:48 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: docs: Document various warnings https://review.opendev.org/c/openstack/openstacksdk/+/891688 | |
| 17:06:49 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: docs: Add exception documentation https://review.opendev.org/c/openstack/openstacksdk/+/891689 | |
| 17:06:50 | opendevreview | Stephen Finucane proposed openstack/openstacksdk master: WIP: tox: Add coverage docs builder https://review.opendev.org/c/openstack/openstacksdk/+/891690 | |
| 17:08:23 | stephenfin | gtema: It would be good to get those doc patches in also, but they're not urgent | |
| 17:08:34 | stephenfin | they are, however, quite useful | |
| 17:08:46 | stephenfin | ...if I do say so myself :) | |
| 17:08:50 | stephenfin | andrewbogott_: looking | |
| 17:08:56 | andrewbogott_ | thank you! | |
| 17:10:13 | stephenfin | Okay, so suggestion is that environment variables should trump cloud variables. This is complicated because of how much the options can potentially layer over each other | |
| 17:10:28 | andrewbogott_ | Can you give me an example? | |
| 17:10:36 | andrewbogott_ | (Or, maybe better to discuss on the task) | |
| 17:12:54 | andrewbogott_ | mostly I want the --os-<whatever> args to trump, but maybe in code that's the same thing as the env variables | |
| 17:13:04 | stephenfin | auth types would be the first thing that jumps to mind because it's been a source of bugs | |
| 17:13:29 | andrewbogott_ | I'm not sure I know what 'auth types' means | |
| 17:14:07 | stephenfin | ah, the 'auth_types' setting in cloud.conf / 'OS_AUTH_TYPE' envvar lets us determine which keystone authentication type to use | |
| 17:14:07 | andrewbogott_ | you mean like admin/public/internal? | |
| 17:14:22 | stephenfin | v3password, v3token, v3applicationcredential etc. | |
| 17:14:28 | andrewbogott_ | oh, I see | |
| 17:14:33 | stephenfin | Setting 'clouds.$cloud.auth_type' completely changes what we look for in 'clouds.$cloud.auth' | |
| 17:15:36 | stephenfin | iirc if it's 'auth_type=v3applicationcredential' but a user sets 'OS_PASSWORD', then we try passing passwords also | |
| 17:16:06 | andrewbogott_ | huh... that seems wrong to me but probably you've already had that conversation :) | |
| 17:16:31 | stephenfin | It is. Unfortunately keystoneauth is a rats nest :) | |
| 17:16:57 | andrewbogott_ | That I know from experience | |
| 17:17:27 | opendevreview | SongSuheon proposed openstack/openstacksdk master: Implement heat 'stack event list' https://review.opendev.org/c/openstack/openstacksdk/+/892836 | |
| 17:17:29 | stephenfin | however, that's kind of tangential to what you're asking | |
| 17:17:36 | andrewbogott_ | So what instead of saying 'env variables trump clouds variables' we say 'select env variables trump clouds variables' | |
| 17:17:53 | andrewbogott_ | and start with project/domain being part of that select | |
| 17:19:45 | andrewbogott_ | Sorry, that was confusing, I'll try again: What if the task is "Allow CLI and env to override the project specified in clouds.yaml"? That would fix /my/ workflows I think. | |
| 17:20:26 | andrewbogott_ | hm. The fact that the same variable OS_PROJECT is used for auth and also used to affect what the command does seems broken either way :( | |
| 17:21:03 | stephenfin | what do you mean? | |
| 17:22:29 | stephenfin | btw, the commands that allow you to specify '--project' rely on server-side support. OSC is merely exposing that. I would guess that those will not be usable by users with standard project-scoped tokens in the future but I can't say for sure | |
| 17:22:46 | andrewbogott_ | Eh, I guess that isn't really right, if you don't have auth in a project you shouldn't be able to do things there anyway. | |
| 17:23:09 | stephenfin | '--os-project' is the keystone thing | |
| 17:24:11 | andrewbogott_ | sorry, had to answer the phone and got confused :) | |
| 17:24:46 | opendevreview | SongSuheon proposed openstack/openstacksdk master: Implement heat 'stack event list' https://review.opendev.org/c/openstack/openstacksdk/+/892836 | |
| 17:24:52 | stephenfin | I have no issues with allowing overriding of clouds.yaml config with CLI args and env vars | |
| 17:24:54 | andrewbogott_ | But yeah, I realize that the --project thing is only selectively implemented for some commands. | |
| 17:25:14 | andrewbogott_ | stephenfin: ok then :) I will try to write a patch, and see how lost I get. | |
| 17:25:29 | andrewbogott_ | Do you think the change should be for /all/ CLI args and env vars, or only for a limited list? | |
| 17:25:35 | stephenfin | I would just ask that we provide a mechanism to disable the env var aspect or set the env var prefix to something other than 'OS_' (if that doesn't exist already) | |
| 17:26:04 | andrewbogott_ | hm... | |
| 17:26:17 | andrewbogott_ | a mechanism other than "Don't set that in your env if you don't want it in your env"? | |
| 17:26:48 | gtema | I was thinking quite some time about that. I think what should always win is "--os-XX" argument. | |
| 17:26:59 | gtema | I would personally even kill the whole env part as such | |
| 17:27:13 | gtema | this is simply terrible stuff from my pov (OS_CLOUD is the only exception) | |
| 17:27:27 | stephenfin | Yes, I know it's ridiculous _but_ we've had bugs in some k8s components because of this (Gophercloud already behaves the way you're suggesting) | |
| 17:27:45 | andrewbogott_ | Yeah, I agree that ideally clouds.yaml is a full substitute for ready-made env files. But that might not be a simple migration path. | |
| 17:28:48 | andrewbogott_ | Some days you're the guy wishing that there weren't existing silly workflows, and some days you're the guy complaining about your existing silly workflow being broken. I guess today I'm the second guy :( | |
| 17:30:25 | gtema | heh, maybe. I the guy not using ENVs in OpenStack context at all and happy | |
| 17:30:58 | andrewbogott_ | that sounds nice | |
| 17:32:02 | stephenfin | okay, no rational attached but here's on example https://github.com/kubernetes/cloud-provider-openstack/pull/733/files | |
| 17:32:21 | stephenfin | See the `EnvPrefix` attribute in `pkg/cloudprovider/providers/openstack/openstack.go` | |
| 17:33:13 | stephenfin | gtema: Alas, I am afraid we are stuck with environment variables for the long-term. TripleO still deploys rc files everywhere, and internally I note all our QE and many field engineers still use them | |
| 17:33:47 | gtema | I know, it is just my opinion that it should have not been existing | |
| 17:34:00 | stephenfin | on that we can agree | |
| 17:34:20 | stephenfin | the mistakes of (project) youth | |
| 17:34:20 | gtema | but wrt CPO - another param to disable/enable ENVs sounds even more crazy | |
| 17:35:02 | gtema | lets see whether the new OSC (;-) can get this addressed | |
| 17:35:35 | andrewbogott_ | Thank you for your thoughts! I will work on a strawman/minimal patch (assuming that's even possible) and then we can see if we want to get more ambitious. | |
| 18:07:45 | opendevreview | Suyeon Cha proposed openstack/openstacksdk master: reset_state, force_delete for Share, ShareSnapshot https://review.opendev.org/c/openstack/openstacksdk/+/888311 | |