Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2021-01-13
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
15:18:36 gtema okay. Then it is clear that we can't drop it without leaving backup for Rack (nodepool)
15:18:43 mordred that said - it almost certainly _should_ get reworked - it's carrying too much complexity on its shoulders. but - it's carrying too much complexity on its shoulders so reworking it without major breakages will be "fun"
15:18:45 gtema makes my night complex
15:19:19 gtema yeah, I liked US beers
15:23:13 mordred remember when we could sit down an have a beer in the same room?
15:23:38 gtema puh, when can this happen again
15:25:41 mordred you can visit new orleans and we can have beers outside - but then you might not be allowed back in germany
15:25:54 gtema yupp ;-)
15:26:40 gtema listing functions in cloud layer already return empty lists for nova case
15:49:38 gtema I doubt "filters" in calls like get_subnet where name_or_id is always present are making any sense
15:50:14 gtema am I missing something?
15:51:46 openstackgerrit Lee Yarwood proposed openstack/openstacksdk stable/train: Fix aggregate functional test for id restriction https://review.opendev.org/c/openstack/openstacksdk/+/767526
15:52:07 mordred filters can additionally filter - for cases where the only thing that's passed to name_or_id is name?

Earlier   Later