| openstackgerrit | Merged openstack/python-openstackclient master: Remove token_endpoint auth type https://review.opendev.org/677795 | 00:02 |
|---|---|---|
| *** enriquetaso has quit IRC | 00:47 | |
| *** slaweq has joined #openstack-sdks | 01:11 | |
| *** slaweq has quit IRC | 01:15 | |
| *** ricolin has joined #openstack-sdks | 01:48 | |
| openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336 | 02:03 |
| *** ricolin has quit IRC | 02:04 | |
| *** ricolin has joined #openstack-sdks | 02:05 | |
| *** slaweq has joined #openstack-sdks | 02:11 | |
| *** slaweq has quit IRC | 02:16 | |
| openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336 | 02:31 |
| *** ricolin has quit IRC | 02:32 | |
| *** ricolin has joined #openstack-sdks | 02:32 | |
| *** openstackgerrit has quit IRC | 02:37 | |
| *** ricolin has quit IRC | 03:21 | |
| *** gkadam has joined #openstack-sdks | 03:50 | |
| *** gkadam has quit IRC | 03:50 | |
| *** adriant has quit IRC | 04:05 | |
| *** adriant has joined #openstack-sdks | 04:05 | |
| *** slaweq has joined #openstack-sdks | 04:11 | |
| *** slaweq has quit IRC | 04:16 | |
| *** dave-mccowan has quit IRC | 04:41 | |
| *** openstackgerrit has joined #openstack-sdks | 05:02 | |
| openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Bump min osc-lib to 1.14.0 https://review.opendev.org/679182 | 05:02 |
| *** Luzi has joined #openstack-sdks | 05:05 | |
| openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Clean up app initialization and config https://review.opendev.org/678146 | 05:06 |
| *** adriant has quit IRC | 05:10 | |
| *** adriant has joined #openstack-sdks | 05:11 | |
| *** factor has joined #openstack-sdks | 05:51 | |
| *** slaweq has joined #openstack-sdks | 06:11 | |
| *** slaweq has quit IRC | 06:16 | |
| *** ricolin has joined #openstack-sdks | 06:38 | |
| *** slaweq has joined #openstack-sdks | 06:58 | |
| *** gtema has joined #openstack-sdks | 07:17 | |
| *** tosky has joined #openstack-sdks | 07:23 | |
| *** slaweq has quit IRC | 07:27 | |
| *** slaweq has joined #openstack-sdks | 07:31 | |
| *** jpena|off is now known as jpena | 07:40 | |
| *** jpich has joined #openstack-sdks | 07:42 | |
| openstackgerrit | Takashi Kajinami proposed openstack/python-openstackclient master: Add parent project filter for listing projects https://review.opendev.org/677103 | 07:55 |
| openstackgerrit | Takashi Kajinami proposed openstack/python-openstackclient master: Add parent project filter for listing projects https://review.opendev.org/677103 | 07:56 |
| openstackgerrit | yanpuqing proposed openstack/openstacksdk master: Modify the 'auth_type' value to correct https://review.opendev.org/677940 | 07:56 |
| *** ralonsoh has joined #openstack-sdks | 08:04 | |
| *** e0ne has joined #openstack-sdks | 08:11 | |
| *** cdent has joined #openstack-sdks | 08:18 | |
| *** e0ne has quit IRC | 08:20 | |
| *** ITD27M01 has joined #openstack-sdks | 08:30 | |
| *** e0ne has joined #openstack-sdks | 08:34 | |
| *** e0ne has quit IRC | 08:59 | |
| *** gtema has quit IRC | 09:09 | |
| *** gtema has joined #openstack-sdks | 09:26 | |
| *** e0ne has joined #openstack-sdks | 09:27 | |
| *** e0ne has quit IRC | 09:27 | |
| *** gtema has quit IRC | 09:29 | |
| *** gtema has joined #openstack-sdks | 09:33 | |
| ITD27M01 | gtema: Hello! Could you advise on unscoped authentication. | 09:57 |
| ITD27M01 | I would like to get a list of the current user's projects by calling the: connection function.identity.user_projects(user=user_id) On new versions of the SDK it works okay, but on older version (0.17.2) I get the error: EmptyCatalog: The service catalog is empty. Is there some workaround for this bug in older versions? | 09:57 |
| ITD27M01 | The clouds.yaml is https://gist.github.com/ITD27M01/1182f93cf583c682102f3c7459fe6af7 | 09:58 |
| ITD27M01 | For openstacksdk==0.35.0 it works fine: https://gist.github.com/ITD27M01/15a7bb415be8327da563c0ee4c080679 | 09:58 |
| ITD27M01 | But for older version (0.17.2): https://gist.github.com/ITD27M01/acd9a0a0f8be3a9b78094f88254a8d2a | 09:58 |
| gtema | interesting. Was not seeing this. | 09:59 |
| gtema | are you stuck with an old version? | 10:00 |
| gtema | can you please also show the trace itself? | 10:01 |
| *** Kl4us1912 has joined #openstack-sdks | 10:01 | |
| ITD27M01 | gtema: I am stuck with an older version shipped with RHEL 7 rpms, the full traceback: https://gist.github.com/ITD27M01/07632e02a736cbacbb37a63dc58f039d | 10:12 |
| Kl4us1912 | can openstacksdk get a Connection.get_project_by_id method (similar to get_user and get_user_by_id). | 10:17 |
| Kl4us1912 | use case is querying one's own project without having the list projects permission | 10:17 |
| Kl4us1912 | i implemented a workaround by copying and slightly modifying get_user_by_id | 10:19 |
| gtema | itd27m01: actually you should use not the unscoped, but domain scoped token. Then it is expected, that service catalog is properly populated | 10:19 |
| ITD27M01 | gtema: How I can change my clouds.yaml for this? | 10:20 |
| gtema | you remove project_name/id and set domain_id/name=user_domain_id/name (so really both) | 10:21 |
| *** e0ne has joined #openstack-sdks | 10:21 | |
| gtema | for me it is defining user_domain_name AND domain_name with same values | 10:21 |
| *** dtantsur|afk is now known as dtantsur | 10:24 | |
| ITD27M01 | gtema: With domain_name + user_domain_name I get the 401 Error. But only user_domain_name works. Is it policy caveat? | 10:25 |
| gtema | probably yes | 10:25 |
| gtema | it's a funny case how you configure, so that libs get domain scoped token. And normally it is absence of project and presence of domain data | 10:26 |
| gtema | user_domain_name is used kind of for authorization agains cloud at all, but domain - to get a domain token | 10:27 |
| *** e0ne has quit IRC | 10:27 | |
| gtema | if you get 401 maybe you are missing privs. But then the question why it works with newer SDK | 10:27 |
| gtema | there were tons of changes, so figuring out what is different will be a challenge | 10:28 |
| gtema | can you trace newer SDK to understand which token is retrieved? I do not believe you can get list of projects with unscoped token | 10:30 |
| ITD27M01 | gtema: The purpose of my code is to provide to users the list of their projects. If I understand this correctly the domain scoped token only available for admins but unscoped token available for everyone authenticated. | 10:31 |
| gtema | yes | 10:31 |
| ITD27M01 | gtema: I see that service_catalog is empty for newer SDK too. But the method connection.identity.user_projects(user=user_id) works | 10:32 |
| gtema | can you compare the endpoints for requests? | 10:33 |
| gtema | or maybe the problem is not the SDK, but keysoneauth1? | 10:33 |
| gtema | if you stuck with older versions it might be a problem | 10:33 |
| gtema | in this case you might try hardcoding endpoint (for single region cloud should be normally not a problem) | 10:34 |
| ITD27M01 | gtema: In virtualenv the keystoneauth1 is the same | 10:34 |
| ITD27M01 | gtema: In the long term I want to build rpm for new releases of openstacksdk. Perhaps there is already such a repository? | 10:35 |
| gtema | eeh, this is a problem for everyone. I myself build RPMs for our cloud in OpensuseBuild | 10:36 |
| gtema | but you can look for RDO packages | 10:36 |
| ITD27M01 | gtema: For stein the 0.27.0 is available I will check it | 10:39 |
| ITD27M01 | gtema: BTW by tracing the call I need to find the source of the identity url? | 10:40 |
| gtema | if nothing works you can try doing conn.identity.get('YOUR_KEYSTONE_URL/v3/user_id/projects') | 10:40 |
| gtema | you can see this in the project_scoped token response | 10:40 |
| gtema | it's only that this https://docs.openstack.org/api-ref/identity/v3/?expanded=list-projects-for-user-detail#list-projects-for-user API need to be allowed for the user | 10:41 |
| gtema | alternatively /v3/auth/projects | 10:42 |
| gtema | this last might be available with unscoped token | 10:43 |
| ITD27M01 | gtema: conn.identity.get('{}/v3/user_id/projects'.format(conn.auth['auth_url'])) ? | 10:45 |
| gtema | almost - {}/v3/users/REQUESTED_USER_ID/projects | 10:46 |
| gtema | or really conn.identity.get('users/{}/projects') | 10:48 |
| gtema | res = conn.identity.get('users/%s/projects' % conn.current_user_id) | 10:52 |
| ITD27M01 | gtema: projects = connection.identity.get('{auth_url}/v3/users/{user_id}/projects'.format(auth_url=str(connection.auth['auth_url']), user_id=str(user_id))) - this works for me. But without auth_url this return the same catalog is empty | 10:55 |
| ITD27M01 | gtema: Thank you | 10:55 |
| gtema | and if you connect as default project? | 10:55 |
| ITD27M01 | gtema: Hm, what is default project? The project defined in clouds? | 10:56 |
| gtema | yeah, in your domain there is root project | 10:57 |
| gtema | i will try something in 10 minutes | 10:57 |
| *** e0ne has joined #openstack-sdks | 11:00 | |
| *** gtema has quit IRC | 11:01 | |
| *** gtema has joined #openstack-sdks | 11:04 | |
| *** gtema_ has joined #openstack-sdks | 11:11 | |
| ITD27M01 | gtema: I am checking now and found that simple call (connection.identity.user_projects(user=user_id)) works in at least 0.28.0. In 0.27.0 it does not work yet | 11:14 |
| gtema_ | well, if this works - cool. I can't actually connect to the my cloud without specifying project or domain | 11:14 |
| ITD27M01 | gtema: Ok, thank you | 11:18 |
| gtema_ | welcome | 11:18 |
| *** dave-mccowan has joined #openstack-sdks | 11:18 | |
| *** e0ne has quit IRC | 11:20 | |
| gtema_ | btw: conn.session.get('{auth_url}/auth/projects'.format(auth_url=str(conn.auth['auth_url']))) might be a 'cleaner' solution | 11:21 |
| gtema_ | or including /v3 - depending what is your case | 11:22 |
| *** e0ne has joined #openstack-sdks | 11:23 | |
| *** e0ne has quit IRC | 11:32 | |
| *** jpena is now known as jpena|lunch | 11:35 | |
| *** e0ne has joined #openstack-sdks | 11:40 | |
| *** gtema_ has quit IRC | 11:42 | |
| *** gtema_ has joined #openstack-sdks | 11:43 | |
| *** cdent has quit IRC | 11:47 | |
| *** gtema_ has quit IRC | 11:49 | |
| *** gtema_ has joined #openstack-sdks | 11:53 | |
| *** gtema_ has quit IRC | 11:54 | |
| *** gtema_ has joined #openstack-sdks | 11:56 | |
| *** cdent has joined #openstack-sdks | 12:00 | |
| *** gtema_ has quit IRC | 12:09 | |
| *** e0ne has quit IRC | 12:11 | |
| *** gtema_ has joined #openstack-sdks | 12:26 | |
| *** cdent has quit IRC | 12:35 | |
| *** gtema has quit IRC | 12:40 | |
| *** jpena|lunch is now known as jpena | 12:41 | |
| *** Kl4us1912 has quit IRC | 12:44 | |
| *** Luzi has quit IRC | 12:44 | |
| *** cdent has joined #openstack-sdks | 12:45 | |
| ITD27M01 | gtema: I got it! https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/config/cloud_region.py#L466 | 12:53 |
| ITD27M01 | gtema: The auth_url is used for identity service in the case of unscoped token | 12:54 |
| gtema_ | aah, yeah | 12:54 |
| gtema_ | cool | 12:54 |
| ITD27M01 | gtema: https://opendev.org/openstack/openstacksdk/commit/72504d7f5b4be4a49a0e380b36a5c208ca11611d | 12:54 |
| ITD27M01 | this change | 12:54 |
| gtema_ | cool | 12:55 |
| *** enriquetaso has joined #openstack-sdks | 13:00 | |
| *** mriedem has joined #openstack-sdks | 13:07 | |
| *** zbr has quit IRC | 13:08 | |
| *** zbr has joined #openstack-sdks | 13:16 | |
| *** e0ne has joined #openstack-sdks | 13:40 | |
| *** e0ne has quit IRC | 13:43 | |
| *** efried is now known as efried_afk | 13:47 | |
| *** dave-mccowan has quit IRC | 13:54 | |
| *** dave-mccowan has joined #openstack-sdks | 13:54 | |
| *** mordred has quit IRC | 13:57 | |
| *** mordred has joined #openstack-sdks | 13:59 | |
| *** e0ne has joined #openstack-sdks | 14:22 | |
| *** Kl4us1912 has joined #openstack-sdks | 14:31 | |
| *** ITD27M01 has quit IRC | 14:55 | |
| *** efried_afk is now known as efried | 15:13 | |
| *** e0ne has quit IRC | 15:14 | |
| * elmiko waits anxiously | 15:59 | |
| elmiko | API SIG office hours now starting, grab yer popcorn! | 16:00 |
| openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336 | 16:00 |
| edleafe | I was waiting for you to type something :) | 16:00 |
| gtema_ | oh, yeah. It's again happy hour | 16:00 |
| elmiko | haha, i kinda felt so after about 10 seconds | 16:01 |
| elmiko | this hour brought to you by our undying love for edleafe =) | 16:01 |
| gtema_ | :) | 16:01 |
| edleafe | Oh, that's rich! | 16:01 |
| elmiko | haha | 16:02 |
| elmiko | is dtantsur around? | 16:05 |
| dtantsur | who? | 16:05 |
| elmiko | i kinda wnat to talk about the suggestions that came up on the ml | 16:05 |
| elmiko | like, should we spend some time over the next week or two to triage all the todos and reviews? | 16:05 |
| dtantsur | the only reason we haven't done it already is that nobody has time for it | 16:05 |
| elmiko | with the goal being to clean up things that we won't get to, or have shifted scope significantly | 16:05 |
| elmiko | ack | 16:06 |
| elmiko | i'm gonna take an action to make some progress there | 16:06 |
| dtantsur | I'm open to an hour of a call to try tackle it | 16:06 |
| dtantsur | I think a general "let's do it" won't help :) | 16:06 |
| elmiko | how about this, i will start by going through the open reviews and adding my thoughts about them to each | 16:06 |
| elmiko | maybe next week during the hour we can go through and just make some decisions about keeping them open, closing, or w/e | 16:07 |
| dtantsur | ++ | 16:07 |
| elmiko | ok, cool | 16:07 |
| elmiko | gtema_: i am happy to include you in any of this if you would like? | 16:07 |
| gtema_ | sure | 16:07 |
| dtantsur | of course he would :) | 16:07 |
| edleafe | They aren't so much "ToDos" as they are "We know there's a gap here" | 16:08 |
| gtema_ | hehe, dtantsur - you own me a review | 16:08 |
| elmiko | edleafe: ++ | 16:08 |
| dtantsur | really? you owe me a beer! | 16:08 |
| elmiko | i'm not sure what to do about the todos | 16:08 |
| gtema_ | really? | 16:08 |
| dtantsur | (I'm in DUS starting next week, so do your math!) | 16:08 |
| gtema_ | I am not in DUS, was there already 2 times last week and not willing to go again - too crowded | 16:08 |
| elmiko | i wonder if we could replace the todos with some specific language about there not being any guidance yet? is that any better than just a "todo" | 16:09 |
| gtema_ | but I am on DOST in Sept in Berlin. Are you there? | 16:09 |
| dtantsur | gtema_: in in Dusseldorf the whole September probably | 16:09 |
| dtantsur | anybody going to OpenInfra Nordics? | 16:09 |
| gtema_ | beh | 16:09 |
| gtema_ | beh was not to Nordics | 16:09 |
| dtantsur | I may end up here mid-September, depending on various circumstances | 16:10 |
| gtema_ | I'm not - only "Deutsche OpenStack Tage" | 16:10 |
| dtantsur | but my primary goal is to find a flat in DUS asap | 16:10 |
| * dtantsur is presenting on OpenInfra Nordics | 16:10 | |
| elmiko | ooh, nice dtantsur ! | 16:10 |
| gtema_ | coool | 16:10 |
| *** jpena is now known as jpena|off | 16:11 | |
| dtantsur | elmiko: I suggest we file a bug per each TODO and then follow the same process | 16:11 |
| dtantsur | fix it OR close and remove the todo | 16:12 |
| elmiko | i feel like that is where we are stuck though, the "fix it or forget it" stage | 16:12 |
| elmiko | but, i like the idea of making some bugs to track this better | 16:12 |
| elmiko | well, maybe not better, but just not in the docs themselves | 16:12 |
| dtantsur | yeah | 16:13 |
| gtema_ | ++ | 16:13 |
| elmiko | so, it's a long holiday weekend here in the states, but i will make some actions next week when i return | 16:14 |
| gtema_ | Guys, what do you think about API header “Accept: “? It does not make any sense from my POV and due to some patch/API Gateways in front some of the requests to Swift in my cloud are failing. | 16:15 |
| efried | merge enormous doc patches, even though they're known to be incomplete, as long as they're at least largely technically accurate. open bugs for known gaps therein. | 16:15 |
| dtantsur | gtema_: in what context? in some contexts it does make sense | 16:15 |
| dtantsur | efried: ++ that's what we're discussing | 16:16 |
| gtema_ | i.e. HEAD request | 16:16 |
| elmiko | efried: my concern here is removing the "TODO" language from the docs and migrating that into bugs | 16:16 |
| gtema_ | currently in SDK we enforce "Accept: " for head requests and for create object | 16:16 |
| efried | I like the idea of keeping TODOs in docs, because they're more likely to be noticed by people consuming the docs, and more noticed is more likely to be acted upon. | 16:16 |
| elmiko | efried: ahh, i see though, you are saying we should push through some of these long standing doc patchs? | 16:16 |
| efried | yes elmiko, this ^ | 16:17 |
| efried | They're stagnant because they're so huge that nobody wants to review them. | 16:17 |
| elmiko | my only problem with that notion is that they have been there for a long time and no one has acted on them | 16:17 |
| dtantsur | I'm not convinced anybody will ever fix TODOs that we don't fix | 16:17 |
| elmiko | the todos that is | 16:17 |
| elmiko | dtantsur: ++ | 16:17 |
| efried | that doesn't mean we should get rid of them | 16:17 |
| efried | that would be like denying that the gaps exist. | 16:17 |
| dtantsur | gtema_: sending Accept without expecting a body is certainly weird | 16:17 |
| efried | If nobody cares about the gaps, then indeed nobody will close them. But that doesn't mean they don't exist. | 16:18 |
| elmiko | i would prefer changing the language from "TODO" to something more reflective of our actual position though. | 16:18 |
| dtantsur | yeah, maybe we should change the syntax to something more user-friendly and saying "The API SIG doesn't currently have a guidance on ..." | 16:18 |
| elmiko | right | 16:18 |
| elmiko | at least let folks know that we have been unable to agree on, or generate guidance for those todos | 16:18 |
| dtantsur | a raw TODO in text may give an impression that we're working on it | 16:19 |
| dtantsur | while we're not working :) | 16:19 |
| elmiko | "todo" sounds like we might actually get around to it | 16:19 |
| elmiko | dtantsur: yes! | 16:19 |
| dtantsur | elmiko: are you reading my thoughts??? | 16:19 |
| elmiko | hahaha | 16:19 |
| gtema_ | dtantsur: that's what we do. But it is something more general, that from the API pov there are no real guidance | 16:19 |
| * elmiko concentrates | 16:19 | |
| efried | Consider a new | 16:19 |
| efried | .. help-wanted:: | 16:19 |
| efried | role | 16:19 |
| elmiko | that's a nice thought efried | 16:19 |
| dtantsur | that would be ideal | 16:19 |
| efried | stephenfin could work that up for us in all his spare time. | 16:19 |
| edleafe | elmiko: "todo" sounds like there is a plan to actually get around to it :) | 16:20 |
| gtema_ | agree | 16:20 |
| elmiko | edleafe: exactly, i want to be more transparent | 16:20 |
| elmiko | efried: i would be happy with a "help wanted" plus changing the todo language to something more honest | 16:20 |
| elmiko | well, more reflective of our actual intentions | 16:21 |
| dtantsur | and maybe some rough ideas on what a guidelines could look like | 16:21 |
| efried | I didn't want to get into this on the ML, but I don't like the idea that "if nobody is asking it must not be important". | 16:21 |
| stephenfin | efried: | 16:21 |
| stephenfin | .. admonition:: Help wanted | 16:21 |
| dtantsur | "We don't know for sure, but something in spirit of RFC XYZ" | 16:21 |
| stephenfin | 16:21 | |
| stephenfin | Stuff. | 16:21 |
| dtantsur | yeah | 16:21 |
| stephenfin | QED | 16:21 |
| elmiko | efried: ++, that's a good thought to capture | 16:21 |
| efried | stephenfin: cool, I had a feeling there might be something existing that would work. | 16:21 |
| elmiko | they _are_ important, but we have failed as a sig to arrive at any guidance on those topics | 16:22 |
| dtantsur | tripleo-docs uses admonitions quite actively, we can check how they do it | 16:22 |
| elmiko | dtantsur: ++ | 16:22 |
| efried | All too often people just give up because it's too hard or time consuming or soul-sucking to continue complaining about stuff that's been TODO f'rever. | 16:22 |
| dtantsur | if we had one person per each big project.. cough-cough | 16:22 |
| * efried suddenly has somewhere else to be | 16:23 | |
| dtantsur | :D | 16:23 |
| elmiko | haha | 16:23 |
| efried | It's just that we're all stretched so thin | 16:23 |
| dtantsur | indeed | 16:23 |
| elmiko | yyup | 16:23 |
| efried | unfortunately docs always end up being a thing that suffers, falls off the bottom. | 16:23 |
| dtantsur | yep. and dev docs is the least liked kind of docs | 16:23 |
| elmiko | i feel like even migrating from TODO to "we could use help here but have no guidance currently" is at least more reflective of where we are at | 16:23 |
| edleafe | So like elmiko said, let's be transparent about that | 16:24 |
| dtantsur | very much agreed | 16:24 |
| gtema_ | ++ | 16:24 |
| efried | so anyway, the path of least resistance but biggest effect IMO is to keep the TODOs (with help-wanted admonition makeover if desired) and keep them in front of people's faces (i.e. keep them in the docs). | 16:24 |
| elmiko | cool, i have _some_ time (he said sheepishly), i'll take the lead on geting something moving | 16:24 |
| dtantsur | elmiko++ | 16:25 |
| elmiko | efried: ack, we won't take them out but i would really like to make them more explicit | 16:25 |
| efried | we are all in violent agreement | 16:25 |
| elmiko | we can argue about the details on review ;) | 16:25 |
| dtantsur | oh we can :) | 16:25 |
| efried | also, consider merging the massive-doc-patches as is and refacing the TODOs in subsequent patches. | 16:25 |
| elmiko | haha | 16:25 |
| * dtantsur unpacks his nitpicker | 16:25 | |
| dtantsur | efried: also true. especially with the version discovery monster. | 16:26 |
| gtema_ | oj, the nitpicker of dtantsur is a killer bomb ;-) | 16:26 |
| efried | because there's a mental barrier to re-reviewing a 1KLOC patch. | 16:26 |
| elmiko | efried: yes, i will make notes about this when i triage next week. if those patches are in good enough shape to merge i will weigh that heavily in my comments. | 16:26 |
| efried | regardless of how small the inter-patch delta is. | 16:26 |
| elmiko | efried: ++ | 16:26 |
| *** jpich has quit IRC | 16:26 | |
| efried | especially with docs, as long as the patch moves the ball forward and doesn't introduce actual inaccuracies, we should be able to be much less perfectionist about merging | 16:27 |
| efried | it's not like we're going to introduce a security regression or something. | 16:27 |
| elmiko | yeah | 16:27 |
| efried | break CERN's deployment. | 16:27 |
| elmiko | i think we've just been really nitpicky about getting the details correct | 16:28 |
| elmiko | and that version discovery beast is tough to wrangle | 16:28 |
| efried | no joke | 16:28 |
| elmiko | especially when we stay true to our processes and ask for input from the community | 16:28 |
| elmiko | efried: so that's a question i have though. we have clear guides about how we will merge changes, i don't think it's a good idea to break them /but/ we do open ourselves up to drive by -1's when we do this and that throws the whole process off. any suggestions? | 16:29 |
| efried | clear guides written for different times; we should have the temerity to alter those processes. | 16:30 |
| elmiko | fair | 16:30 |
| dtantsur | ++ | 16:31 |
| efried | A number of teams are, out of necessity, moving to single-core approvals. Not saying thats' a good idea here necessarily, just that it's a thing. | 16:31 |
| elmiko | appreciate all the feedback, it is helpful | 16:31 |
| dtantsur | and the version discovery one doesn't have -1's | 16:31 |
| elmiko | dtantsur: ++ | 16:31 |
| dtantsur | so strictly speaking we can approve it | 16:31 |
| elmiko | cool, maybe we just do that | 16:31 |
| elmiko | give it one more read through to make sure there are not glaring errors | 16:32 |
| efried | Yeah, for something like this, if it's clear it's been thoroughly reviewed by people with at least some understanding of the content, it's reasonable to proxy their +1 as a +2 when there's a dearth of cores available. | 16:32 |
| efried | IMHO | 16:32 |
| elmiko | ++ | 16:32 |
| efried | IIRC I went through one or more of those enormous patches and +1ed. | 16:32 |
| efried | I consider myself at least somewhat up on version discovery. | 16:32 |
| efried | and changes since my +1 have been minimal, so feel free to carry those forward. | 16:33 |
| elmiko | ack, thanks | 16:33 |
| elmiko | is it time for cake and punch? | 16:33 |
| gtema_ | I was missing in the version discovery rules on what is open and what requires AUTH. This got lost in some restructuring | 16:34 |
| elmiko | gtema_: definitely add comments if you can figure out where it was | 16:34 |
| gtema_ | did it already | 16:34 |
| gtema_ | long time ago | 16:34 |
| gtema_ | but that is the point - there are way to many to see the overview | 16:34 |
| elmiko | ok, cool. i will inevitably come across them ;) | 16:34 |
| elmiko | yeah, i'm gonna carve out like half a day for going reviewing these | 16:35 |
| dtantsur | I've seen gtema_'s comments, just never got to fixing them | 16:35 |
| elmiko | ok, maybe i can help | 16:35 |
| dtantsur | and again, I'd prefer to fix in a follow-up | 16:35 |
| elmiko | ++ | 16:35 |
| elmiko | if there are easy fixes though, i will try to just add them | 16:36 |
| gtema_ | cool | 16:36 |
| gtema_ | dtantsur: what do you think about https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/resource.py#L1331 | 16:42 |
| gtema_ | can we change it to "Accept: *"? | 16:42 |
| gtema_ | empty value is somehow not RFC-nice | 16:43 |
| dtantsur | gtema_: I wonder why we send *anything* if we don't expect a body | 16:46 |
| dtantsur | HEAD + Accept doesn't make sense to me | 16:46 |
| gtema_ | well, some APIs might return a body | 16:46 |
| dtantsur | to HEAD?? Oo | 16:46 |
| gtema_ | or, no | 16:47 |
| gtema_ | looked to the wrong section | 16:47 |
| gtema_ | I would suggest either remove it completely, or set a "*" | 16:47 |
| gtema_ | not an empty value | 16:47 |
| edleafe | A HEAD with a body is, well, a whole person | 16:48 |
| gtema_ | yupp | 16:48 |
| elmiko | lol | 16:48 |
| dtantsur | :D | 16:49 |
| dtantsur | I'd remove it | 16:49 |
| gtema_ | ok, will do. | 16:49 |
| dtantsur | and see if mordred complains | 16:49 |
| gtema_ | and now PUT, which might return body, but contain no body in request (swift create object) | 16:49 |
| dtantsur | Accept is related to returned body, right? | 16:50 |
| elmiko | dtantsur: the ultimate test ;) | 16:50 |
| gtema_ | yes | 16:50 |
| dtantsur | so if you expect that a body might be returned, you should be sending Accept | 16:50 |
| dtantsur | (although the exactly value depends on the call) | 16:50 |
| gtema_ | yeah, but not the "Accept: ", at least "Accept: *" or "Accept: application/json" | 16:50 |
| dtantsur | true | 16:50 |
| dtantsur | probably the default should be Accept:* or no accept | 16:50 |
| gtema_ | this empty value is what breaks it for me | 16:51 |
| dtantsur | then everything except for swift should use Accept: application/json | 16:51 |
| timburke | fwiw, requests adds an "Accept: */*" header by default. if i had to guess, i'd say the empty was trying to prevent that, but i don't know why | 16:51 |
| dtantsur | weird | 16:51 |
| gtema_ | my small test was not confirming that - after removing this empty there was nothing at all | 16:52 |
| timburke | if you really want to drop the header entirely, you could try {'Accept': None} | 16:52 |
| dtantsur | I'm not sure why we would want that | 16:52 |
| dtantsur | I would expect that no header is equivalent to Accept:*/* | 16:52 |
| gtema_ | yeah | 16:53 |
| gtema_ | this is also how I interpret RFC | 16:53 |
| timburke | i know that i've done that for Accept-Encoding before, where swiftclient will freak out a bit if requests goes and decompresses object data as it's getting downloaded | 16:53 |
| dtantsur | gtema_: propose a fix and see if anybody complains | 16:53 |
| gtema_ | cool | 16:53 |
| edleafe | "Accept: None" should mean "don't return *any* body in the response" | 16:53 |
| dtantsur | timburke: but it's swiftclient specific, right? not openstacksdk? | 16:53 |
| gtema_ | exactly SDK | 16:53 |
| elmiko | i don't want to break up the accept discussion too much, but before we end the office hour i /do/ want to thank edleafe one more time. he has been a pillar of this community and i personally have learned a great deal from him. thank you again Ed =) | 16:54 |
| gtema_ | yeah, thanks Ed | 16:54 |
| edleafe | I am going to miss hanging out with all of you. Even elmiko! | 16:55 |
| elmiko | hehehe <3 | 16:55 |
| dtantsur | thanks you edleafe! | 16:55 |
| timburke | i'm not sure what you guys do when downloading object data ;-) i know swiftclient wants to do some checksumming, which'll require the raw (compressed, if it was stored compressed) stream | 16:55 |
| dtantsur | good question | 16:55 |
| gtema_ | there is hell amount of logic | 16:56 |
| gtema_ | at least for uploading | 16:57 |
| gtema_ | for downloading we also set "Accept: bytes" | 16:58 |
| gtema_ | but we do not do download checksumming | 17:01 |
| elmiko | i'm heading out for the weekend, take care all o/ | 17:01 |
| *** e0ne has joined #openstack-sdks | 17:02 | |
| gtema_ | yeah, EOD for me as well. See ya tomorrow | 17:02 |
| timburke | gtema_, curious! good thing swift doesn't do anything with that. we'd 400 it for container listings, complaining "Invalid Accept header" | 17:02 |
| * dtantsur leaves as well | 17:03 | |
| *** dtantsur is now known as dtantsur|afk | 17:03 | |
| gtema_ | timburke: thanks for hint. Will try to check that tomorrow | 17:03 |
| *** cdent has quit IRC | 17:03 | |
| *** e0ne has quit IRC | 17:04 | |
| *** gtema_ has quit IRC | 17:04 | |
| *** e0ne has joined #openstack-sdks | 17:04 | |
| *** e0ne has quit IRC | 17:04 | |
| *** gtema has joined #openstack-sdks | 17:05 | |
| *** gtema has quit IRC | 17:09 | |
| *** enriquetaso has quit IRC | 17:21 | |
| *** e0ne has joined #openstack-sdks | 17:35 | |
| *** e0ne has quit IRC | 17:35 | |
| *** ralonsoh has quit IRC | 17:43 | |
| *** ricolin has quit IRC | 17:55 | |
| *** e0ne has joined #openstack-sdks | 18:29 | |
| *** Kl4us1912 has quit IRC | 18:30 | |
| *** e0ne has quit IRC | 18:32 | |
| *** e0ne has joined #openstack-sdks | 18:55 | |
| *** enriquetaso has joined #openstack-sdks | 19:01 | |
| *** e0ne has quit IRC | 19:01 | |
| *** e0ne has joined #openstack-sdks | 19:03 | |
| *** slaweq has quit IRC | 19:04 | |
| *** e0ne has quit IRC | 19:04 | |
| *** e0ne has joined #openstack-sdks | 19:05 | |
| *** e0ne has quit IRC | 19:05 | |
| *** slaweq has joined #openstack-sdks | 19:11 | |
| *** slaweq has quit IRC | 19:15 | |
| *** enriquetaso has quit IRC | 19:21 | |
| *** enriquetaso has joined #openstack-sdks | 19:21 | |
| *** enriquetaso has quit IRC | 19:44 | |
| *** slaweq has joined #openstack-sdks | 19:59 | |
| *** slaweq has quit IRC | 20:04 | |
| *** slaweq has joined #openstack-sdks | 20:10 | |
| *** slaweq has quit IRC | 20:16 | |
| *** factor has quit IRC | 20:42 | |
| *** factor has joined #openstack-sdks | 20:42 | |
| *** icarusfactor has joined #openstack-sdks | 20:53 | |
| *** factor has quit IRC | 20:54 | |
| *** gtema has joined #openstack-sdks | 21:05 | |
| *** gtema has quit IRC | 21:10 | |
| *** slaweq has joined #openstack-sdks | 21:10 | |
| *** slaweq has quit IRC | 21:15 | |
| *** brtknr has quit IRC | 21:22 | |
| *** brtknr has joined #openstack-sdks | 21:23 | |
| *** slaweq has joined #openstack-sdks | 22:11 | |
| *** brtknr has quit IRC | 22:11 | |
| *** slaweq has quit IRC | 22:15 | |
| *** tosky has quit IRC | 22:29 | |
| openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336 | 23:24 |
| openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336 | 23:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!