| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2021-01-13 | |||
| 10:04:15 | stephenfin | Oh yeah, that's mixin is pretty widely spread | |
| 10:06:06 | stephenfin | Could split the query and body parameters part of the mixin into a new e.g. TagBodyMixin and have the existing TagMixin subclass that and add the methods. You could then use TagBodyMixin here | |
| 10:06:22 | stephenfin | We could audit existing uses of TagMixin to make sure they all make sense | |
| 10:06:29 | stephenfin | later, that is | |
| 10:06:43 | gtema | except of image others seem to implement tagging properly | |
| 10:07:04 | stephenfin | Yeah, I know nova does that properly | |
| 10:07:07 | stephenfin | at least | |
| 10:07:14 | gtema | network also | |
| 10:08:06 | stephenfin | Would a separate subclass work so? TagBodyMixin isn't a great name. Maybe MinimalTagMixin or something better again | |
| 10:08:50 | gtema | you propose separate query params and attributes from methods? | |
| 10:09:19 | openstackgerrit | Stephen Finucane proposed openstack/openstacksdk master: Demonstrate separate tag mixin https://review.opendev.org/c/openstack/openstacksdk/+/770565 | |
| 10:09:23 | stephenfin | yeah, like that ^ | |
| 10:10:11 | stephenfin | tbc I still don't like the name 'MinimalTagMixin' but I can't think of anything better right now, but you get the idea | |
| 10:10:36 | gtema | I would say in that case it is easier to manually use query params and attribute without really using mixin | |
| 10:10:49 | stephenfin | That's fair. It doesn't really give us a lot | |
| 10:17:14 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Add query parameters to listing heat stacks https://review.opendev.org/c/openstack/openstacksdk/+/769484 | |
| 10:35:02 | stephenfin | gtema: Do we add release notes for this kind of change? | |
| 10:35:22 | gtema | not really | |
| 10:35:37 | stephenfin | ack, +2 so | |
| 10:35:41 | stephenfin | and +W | |
| 10:35:45 | gtema | thks | |
| 10:39:43 | gtema | what should we do with hypervisor patch and planned (2.88) changes? | |
| 10:40:05 | stephenfin | well they're no longer planned - they're now merged | |
| 10:40:15 | gtema | okay | |
| 10:40:38 | stephenfin | so we could merge this as-is and then do a follow-up for 2.88 | |
| 10:40:40 | stephenfin | or fix now | |
| 10:40:42 | stephenfin | whatever suits you | |
| 10:41:11 | gtema | idea was to prepare SDK to finilaze OSC for hypervisors | |
| 10:41:25 | gtema | so I think we can then spend some more time making SDK proper | |
| 10:41:55 | gtema | I do not really like dropped functions | |
| 10:42:32 | gtema | and uptime handling becomes really terrbile | |
| 10:44:21 | gtema | I think we need to orient on 2.88 and drop things from OSC that are not there anymore | |
| 10:45:21 | gtema | so complete disk and memory info about hypervisor disappears, right? | |
| 10:45:35 | stephenfin | yes, all that info is gone | |
| 10:45:46 | gtema | but we show it in OSC now | |
| 10:46:15 | gtema | I would really just drop them from SDK/OSC not to have this mess | |
| 10:46:15 | stephenfin | yeah, we'll just have to drop those fields | |
| 10:46:21 | stephenfin | that's fine by me | |
| 10:46:27 | stephenfin | it's bad info | |
| 10:46:34 | gtema | yupp | |
| 10:47:24 | gtema | statistics go away also? | |
| 10:47:35 | stephenfin | yes, for the same reason (bad info) | |
| 10:47:40 | gtema | ok | |
| 10:47:52 | gtema | dropping code is fun from that perspective | |
| 10:50:38 | gtema | how do we want to treat uptime: fetch automatically if under 2.88 or leave it optionally to user? | |
| 10:51:28 | stephenfin | I think leave it optional | |
| 10:51:37 | gtema | ok, agree | |
| 11:19:39 | openstackgerrit | Stephen Finucane proposed openstack/os-client-config stable/train: Uncap jsonschema https://review.opendev.org/c/openstack/os-client-config/+/770598 | |
| 11:19:56 | stephenfin | dtantsur: gtema: yet another pip 20.3 fix there ^ | |
| 11:20:14 | gtema | done | |
| 11:20:20 | stephenfin | thanks | |
| 11:20:36 | stephenfin | we can recheck https://review.opendev.org/c/openstack/openstacksdk/+/767526 once that merges | |
| 11:20:41 | gtema | yes | |
| 11:22:24 | openstackgerrit | Stephen Finucane proposed openstack/os-client-config stable/stein: Uncap jsonschema https://review.opendev.org/c/openstack/os-client-config/+/770599 | |
| 11:32:41 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Complete compute.hypervisor functions https://review.opendev.org/c/openstack/openstacksdk/+/763202 | |
| 11:48:10 | openstackgerrit | Takashi Kajinami proposed openstack/python-openstackclient master: Volume type: Update is_public attribute https://review.opendev.org/c/openstack/python-openstackclient/+/768800 | |
| 11:50:21 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Complete compute.hypervisor functions https://review.opendev.org/c/openstack/openstacksdk/+/763202 | |
| 13:18:20 | openstackgerrit | Jakob Meng proposed openstack/ansible-collections-openstack master: Fix volume_info result for SDK < 0.19 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/770267 | |
| 15:00:04 | gtema | dtantsur, stephenfin, slaweq, what do you think of dropping support for compute networking from SDK now. I am reworking cloud layer networking functions and nova there is disturbing a lot | |
| 15:00:46 | dtantsur | has it been dropped from nova already? | |
| 15:00:49 | gtema | we passed Ussuri (where Nova dropped support for it) | |
| 15:00:56 | dtantsur | ahh | |
| 15:01:24 | dtantsur | so it affects Train and older (potentially)? | |
| 15:01:38 | gtema | seems to be so | |
| 15:01:53 | gtema | I am not sure somebody was recently using it in cloud layer at all | |
| 15:02:01 | gtema | "These will fail with a 404 starting from microversion 2.36. They were removed in the 21.0.0 (Ussuri) release." | |
| 15:04:33 | gtema | mordred, not sure whether you are here, if yes - ^^ | |
| 15:06:10 | mordred | I'm pretty sure we still use nova-network calls for rackspace | |
| 15:06:29 | mordred | I mean - it's not actually calls ... but the server network info dict is the nova version iirc | |
| 15:06:29 | gtema | really? Oh that's sad | |
| 15:07:09 | mordred | but yeah - I'm not sure who out there might still be running an older cloud, but the theory at least was that things should still work | |
| 15:07:11 | mordred | THAT SAID | |
| 15:07:34 | gtema | that's around 1500 loc, that nobody else is really using | |
| 15:08:07 | mordred | yeah - there's a bunch in here that's essentially in support of rackspace that I kept wanting to come up with a plan for dealing with better | |
| 15:08:35 | gtema | perhaps we can move it similarly to what I do for my cloud with profile? | |
| 15:08:45 | mordred | it made more sense when there were two clouds and one of them was rackspace | |
| 15:08:53 | slaweq | gtema: I'm ok with that, I think nova already removed all of that | |
| 15:08:59 | mordred | yeah - that's sort of what I was thinking | |
| 15:09:08 | mordred | make a rackspace plugin essentially | |
| 15:09:30 | mordred | except - doing the work for that would be tricky - especially because of the cloud-layer fallback logic | |
| 15:09:39 | gtema | mordred: https://github.com/opentelekomcloud/python-otcextensions/blob/master/otcextensions/sdk/__init__.py that's kind of initialization hack that I do | |
| 15:10:03 | gtema | when the package is present and in clouds.yaml there is profile: otc - it get's injected and override some things | |
| 15:10:05 | mordred | it might be more work to engiineer a good plugin layer that can handle the current use cases than to just maintian the existing code | |
| 15:10:44 | mordred | yeah. trickiest part is not breaking the opendev nodepool while doing the work :) | |
| 15:12:02 | gtema | at least according to https://graphite.opendev.org/ nova/os-floating-ip seem to be the only used stuff | |
| 15:12:17 | gtema | networking comes from network | |
| 15:12:32 | gtema | (whether it all reliable source of truth) | |
| 15:12:47 | mordred | oh - you're mostly talking about the actual network calls, like list networks, list routers, etc? | |
| 15:13:10 | gtema | pretty much everything in cloud | |
| 15:13:35 | mordred | the nova-network related paths in cloud layer that are important are the things in meta - like get_server_external_ipv4 and the things its calls | |
| 15:13:51 | gtema | disturbing thing is that normally we would invoke network.find_subnet, but currently we mostly go through complete list | |
| 15:13:56 | mordred | I don't think any of that actually calls nova net endpoints | |
| 15:14:47 | mordred | yah - we do full lists so that the caching works better and it's not a thundering herd in nodepool | |
| 15:15:21 | mordred | one thread calling list subnets once and caching it and 1000 threads doing a lookup in the list rather than 1000 threads doing find_subnet | |
| 15:16:09 | gtema | ugh | |
| 15:16:36 | mordred | which for some of the thigns (liek servers) it could totally work to just move into the nodepool openstack driver - but for the stuff in meta it's called behind the scenes - so it's hard to defer the batching logic to nodepool | |
| 15:16:49 | mordred | yeah. sorry - this is the area where the most complex use cases lurk | |
| 15:17:10 | gtema | which meta exactly you mean? | |
| 15:17:18 | mordred | basically anything that touches openstack.cloud.meta is a potential nightmare to change | |
| 15:17:28 | gtema | ah, yes | |