| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 02:18:45 | adriant | when by default, it never is? | |
| 02:20:24 | adriant | when I do: conn.object_store.create_container("test_5", read_ACL="stuff") | |
| 02:20:43 | adriant | I'd expect that read_ACL to be set, but it isn't, because while it does get added to resource headers, it isn't dirty | |
| 02:22:05 | adriant | yeah... based on your own docs. this is wrong: https://github.com/openstack/openstacksdk/blob/master/openstack/resource.py#L876-L880 | |
| 02:22:31 | adriant | _synchronized should be false | |
| 02:24:27 | adriant | Was that new function meant to actually be existing? because wouldn't the ID only be present when it already exists? | |
| 02:46:28 | openstackgerrit | Adrian Turjak proposed openstack/openstacksdk master: Add support for object storage container policies https://review.opendev.org/699905 | |
| 02:46:28 | openstackgerrit | Adrian Turjak proposed openstack/openstacksdk master: Fix bug in object storage container creation setting metadata https://review.opendev.org/699904 | |
| 02:47:45 | adriant | mordred: ^ have some more swift fixes for the SDK :P | |
| 02:48:13 | adriant | I feel like I find the most bugs in the SDK when dealing with swift because I'm the only person who tries to do swift things with the SDK... | |
| 03:22:17 | adriant | mordred: I added comments on those patches, the tests are failing because there is no way for the resource fields to be marked as: "pull from body, but ignore for update" because name/count etc can't be updated | |
| 03:22:43 | adriant | but if they are dirty, the resource code will include them in the body | |
| 06:45:05 | openstackgerrit | wangfaxin proposed openstack/js-openstack-lib master: Update review community page https://review.opendev.org/699919 | |
| 08:52:54 | openstackgerrit | Bram Verschueren proposed openstack/python-openstackclient master: Fix faulthy state argument choice https://review.opendev.org/699931 | |
| 09:59:34 | openstackgerrit | Bence Romsics proposed openstack/python-openstackclient master: Add command: router add/remove route --route https://review.opendev.org/674325 | |
| 12:40:55 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 13:47:56 | elmiko | dtantsur: i'm thinking about cancelling the next 2 api sig office hours, do you have any feelings about the matter? | |
| 13:54:30 | stephenfin | mordred: I want to do some work on closing the gap between novaclient and openstackclient next year, and I'm thinking I'll use openstacksdk to do that which has many of its own gaps that need closing | |
| 13:54:51 | stephenfin | mordred: Would it be a huge ask for you to provide a sample patch for one of nova's microversioned APIs that I can use as a blueprint? | |
| 13:55:06 | stephenfin | You or someone else involved with openstacksdk (I only know of you :)) | |
| 13:55:32 | gtema | stephenfin - welcome on board. I'm currently working on "repairing" image support in the OSC | |
| 13:55:43 | gtema | and was thinking also to go next for compute | |
| 13:55:53 | gtema | so let's work on this together | |
| 13:56:11 | stephenfin | Great! | |
| 13:56:58 | gtema | I recently made a patch for managing server tags in OSC using SDK, and the next step might be to switch server set/unset operations to use only SDK | |
| 13:57:21 | gtema | with that we can slowly switch parts of the compute, which make it easier | |
| 13:57:32 | stephenfin | gtema: I assume you're doing these repairs using openstacksdk, or are you using glanceclient? | |
| 13:57:46 | gtema | I am replacing glanceclient with SDK | |
| 13:57:57 | stephenfin | Cool | |
| 13:58:08 | stephenfin | The main issue I saw when I started looking at this was that there weren't an clear patterns around for microversioned APIs | |
| 13:58:32 | gtema | I would say it should be considered case by case | |
| 13:58:37 | stephenfin | we use decorators in novaclient but there doesn't seem to be an equivalent pattern for sdk | |
| 13:59:16 | gtema | in the image there is nothing like that. In the tagging of servers there is some first brief example for that, but it doesn't really enforce those | |
| 13:59:39 | stephenfin | so it sounds like we need to invent one? :) | |
| 13:59:59 | stephenfin | that's what I was hoping to drag mordred in for | |
| 14:00:05 | gtema | not really invent support, but perhaps invent pattern how to use it properly | |
| 14:00:11 | stephenfin | yeah, exactly | |
| 14:00:27 | gtema | actually AFAIK in the ironic world this should have been used a lot already | |
| 14:00:33 | stephenfin | I mean, I could just copy-paste the patterns from novaclient, but those aren't necessarily going to align with how everyone else is doing it | |
| 14:00:54 | stephenfin | I looked at baremetal, yeah. Support seemed pretty barebones still, unfortunately :( | |
| 14:01:01 | gtema | in SDK we have option just to specify specific microversion on the request level | |
| 14:01:06 | stephenfin | and wasn't consistent | |
| 14:01:21 | gtema | so I would say let's look to concrete cases | |
| 14:02:56 | stephenfin | Something as simple as migrating this https://github.com/openstack/python-novaclient/blob/eb98178ea88c77881f7c763b068408f769956eb2/novaclient/v2/servers.py#L217-L234 | |
| 14:03:45 | stephenfin | as an examples of an API that accepts different things or otherwise behaves differently depending on the microversion | |
| 14:04:32 | stephenfin | I'll give it some more thought though. You have a specific Gerrit tag for your image service rework, gtema? | |
| 14:04:33 | gtema | ok, so do you "need" to specify microversion in order to lock the server with the reason? | |
| 14:04:45 | gtema | osc-first | |
| 14:04:48 | stephenfin | You do, yeah | |
| 14:04:58 | gtema | https://review.opendev.org/#/c/650374/ | |
| 14:05:13 | stephenfin | If you make the request without the version, nova will default to version 2.1 and the schema check will fail | |
| 14:05:24 | gtema | ok | |
| 14:06:29 | gtema | for that there is no support in SDK currently completely. So I would suggest to try to implement it there, that if reason is set - include microversion (is supported) | |
| 14:06:55 | gtema | I would say this should be transparent to OSC, but a different approach might be used | |
| 14:06:59 | stephenfin | That makes sense | |
| 14:07:23 | gtema | https://review.opendev.org/#/c/697674/ | |
| 14:07:45 | gtema | so currently lot's of nova stuff in OSC requires you to specify microversion already there | |
| 14:08:02 | gtema | both has pros and cons | |
| 14:08:22 | stephenfin | ah, so version checks are handled from the OSC side rather than the SDK side | |
| 14:08:30 | gtema | currently yes | |
| 14:08:36 | stephenfin | and the SDK will dumbly pass whatever it gets to nova | |
| 14:08:37 | stephenfin | cool | |
| 14:08:52 | stephenfin | definitely easier, but not as nice for people using SDK for other things | |
| 14:09:10 | gtema | it enforces "user" to know which mv it needs (bad), but ensures early that it is possible at all | |
| 14:10:00 | stephenfin | fwiw, novaclient defaults to using the latest version and enforces users know the _older_ mv if they want old behavior | |
| 14:10:11 | gtema | lemme browse through dtantsur's code in baremetal and check with him ideas | |
| 14:10:13 | stephenfin | the rationale being that people will usually want the new shiny | |
| 14:10:28 | stephenfin | but osc hasn't been against that historically and I'm not wading into that battle :) | |
| 14:10:34 | stephenfin | gtema: That'd be great | |
| 14:10:54 | stephenfin | once I've a blueprint to work against, closing the gaps should be fairly rote | |
| 14:10:58 | gtema | they always want new and shiny, but it might be not available, and that's what you need to check in a frendly manner | |
| 14:11:04 | stephenfin | given novaclient is pretty complete | |
| 14:11:46 | gtema | great. Our first concept with bringing individual clients/sdk/OSC in sync didn't went well (not widely accepted). But glad you are on boat | |
| 14:12:20 | stephenfin | sure am | |
| 14:12:23 | stephenfin | and on that note | |
| 14:12:35 | gtema | enjoy | |
| 16:01:55 | elmiko | API SIG office hour now under way! | |
| 16:02:11 | gtema | under "not existing" way? | |
| 16:02:26 | gtema | or pretty-silent way | |
| 16:02:29 | elmiko | lol | |
| 16:02:36 | elmiko | i gotta at least make the announcement | |
| 16:02:44 | gtema | yey | |
| 16:03:57 | sshnaidm | is there anybody for meeting? | |
| 16:04:16 | gtema | it's just a few of us ... | |
| 16:04:30 | sshnaidm | can anybody run the bot? I can't :( | |
| 16:04:32 | elmiko | i'm not sure about the /other/ meeting | |
| 16:04:53 | sshnaidm | #startmeeting | |
| 16:04:54 | openstack | sshnaidm: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | |
| 16:04:57 | sshnaidm | :) | |
| 16:05:03 | elmiko | you need to add api-sig | |
| 16:05:14 | gtema | #startmeeting api-sig | |
| 16:05:15 | openstack | Meeting started Thu Dec 19 16:05:14 2019 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:05:16 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:05:18 | openstack | The meeting name has been set to 'api_sig' | |
| 16:05:20 | elmiko | \o/ | |
| 16:05:32 | gtema | cool, I could do this | |
| 16:05:35 | sshnaidm | gtema, thanks | |
| 16:05:42 | sshnaidm | #chair sshnaidm | |
| 16:05:47 | elmiko | i think sshnaidm could as well, just missed the name | |
| 16:05:57 | gtema | #chair sshnaidm | |