| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-04 | |||
| 14:20:23 | gtema | the proxy is not able to discover supported microversion | |
| 14:21:11 | mordred | gtema: version discovery should be able to handle project_id at the end of endpoint | |
| 14:21:51 | gtema | well, in the small script it is not working properly | |
| 14:22:44 | gtema | wait a sec, posting | |
| 14:24:03 | gtema | mordred: http://paste.openstack.org/show/752487/ | |
| 14:24:43 | mordred | oh - you have a broken compute endpoint. it's requiring auth for version discovery | |
| 14:25:04 | mordred | see that first GET with the 401 | |
| 14:25:20 | gtema | oh, indeed | |
| 14:26:05 | mordred | I think we've got it written down somewhere that people should not auth-protect service version discovery - I don't remember where though | |
| 14:26:50 | efried | I remember this ^ but not sure if it's written | |
| 14:26:55 | gtema | hmm, ok then. Will start alerting internally on all available channels | |
| 14:27:08 | efried | It's written in IRC :) | |
| 14:27:12 | mordred | efried: :) | |
| 14:27:16 | gtema | life is great ;-/ | |
| 14:28:21 | mordred | gtema: let me know if I can be helpful in corroborating that this should not be auth-protected. | |
| 14:28:30 | mordred | s/should/must/ | |
| 14:29:40 | gtema | we probably should add it into https://opendev.org/openstack/api-sig/src/branch/master/guidelines/microversion_specification.rst | |
| 14:31:05 | mordred | gtema: yah. it's possible it's mentioned in https://review.opendev.org/#/c/459405/ - looking | |
| 14:31:18 | efried | ++. I was looking for it in the keystoneauth docs, but that's the consuming side, so probably not the right place anyway. | |
| 14:32:33 | mordred | https://review.opendev.org/#/c/459405/ | |
| 14:32:52 | mordred | https://review.opendev.org/#/c/459710/17/guidelines/discoverability.rst@93 | |
| 14:33:38 | gtema | hmm, 'it is recommended' is confusing. It is definitely not working at all otherwise | |
| 14:35:18 | efried | it's possible to make it work, I suppose. "strongly recommended"? ;P | |
| 14:35:32 | gtema | :D | |
| 14:36:02 | gtema | as a consumer I doubt you will make it work. If we bake it in - sure | |
| 14:37:08 | mordred | yeah - we should probably change that to be stronger | |
| 14:38:01 | mordred | it's unpossible to make it work with the official openstack libraries or any of the tools. obviously you could make it work with direct REST calls ... | |
| 14:38:12 | gtema | I guess it is either stricktly required, or possible otherwise (not as of now) | |
| 14:38:24 | gtema | so yeah - exactly what I mean | |
| 14:38:27 | mordred | ++ | |
| 14:39:03 | mordred | it's also not a thing we can update keystoneauth to handle reasonably - it would take basically a full rewrite IIRC | |
| 14:39:50 | gtema | ok. Sad, means cloud is still cloudy, but that is how it is | |
| 14:40:10 | mordred | :( - sorry about that | |
| 14:41:01 | gtema | another question for the same topic. Some stuff require 'min' version. Do we have something to pick the proper version out of it (not sticking for this min if current is better)? | |
| 14:41:03 | mordred | we should really add a tempest test and get refstack to require that it works properly | |
| 14:41:16 | gtema | that is a cool idea | |
| 14:41:46 | efried | ++ | |
| 14:43:09 | mordred | gtema: dtantsur added some stuff to the resource layer for specifying microversions needed for things - | |
| 14:43:12 | mordred | there's also https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/server.py#L421 | |
| 14:43:18 | mordred | how we're doing it for live migrations | |
| 14:44:01 | mordred | there should probably be some sort of helper pattern extracted from that, because that's super manual | |
| 14:44:06 | gtema | the question is basically coming from: /servers/.../createImage returns image_id only after 2.45. And do not want to simply say - use 2.45 here. I would like to treat microver as a "num" | |
| 14:44:27 | gtema | to get the newest | |
| 14:46:02 | mordred | I think what the current resource microversion stuff is saying is "This resource knows how to handle microversions as new as 2.45" - because just doing latest could mean semantic changes that the resource can't handle | |
| 14:47:15 | mordred | then, in the code, if we wanted to make image_id part of our API all the time, we might need to make an extra call if the cloud is older than 2.45, yeah? | |
| 14:47:30 | gtema | yeah, for server-group it is slightly more complicated - until 2.63 there is attr 'policies' | |
| 14:47:57 | gtema | after 2.64 it is 'policy' and a single only | |
| 14:48:05 | mordred | *awesome* | |
| 14:48:43 | mordred | can there be more than one policy in the list until 2.63? or is it a list that happened to only ever have one policy in it? | |
| 14:48:50 | gtema | so I need to somehow check - do we support max something older - than do one cool thing. If we support something newer than 2.64 - do other cool thing | |
| 14:49:03 | gtema | nope, should not be | |
| 14:49:14 | gtema | stated in docs - list with strictly one entity | |
| 14:49:41 | mordred | so - we could conceivably support both in all cases and just map it differently depending on what we get back from the remote side | |
| 14:50:11 | mordred | so have server_group.policy and server_group.polices - or we could just pick one and map in that direction regardless of server-side | |
| 14:50:28 | gtema | yes, but depending on what is the max supported version I need to hack "create" | |
| 14:50:37 | mordred | but yeah - this is where everything gets tricky :) | |
| 14:50:57 | gtema | and if with following microvers new features will come - it will become even better | |
| 14:51:07 | mordred | yah | |
| 14:51:11 | gtema | (will add) | |
| 14:51:45 | gtema | so we need really to treat microvers as numbers | |
| 14:53:58 | efried | does microversion_parse help here? | |
| 14:54:32 | gtema | efried: which one? | |
| 14:54:43 | efried | treating microversions as numbers | |
| 14:55:09 | efried | I'm probably not following closely enough to be useful here, sorry. | |
| 14:55:33 | efried | "treat microversions as numbers" => has to be a tuple, not a float, of course. Else 1.23 < 1.4 | |
| 14:55:48 | efried | ksa has a crap-ton of code dealing with this. | |
| 14:56:04 | gtema | really? have not seen so far | |
| 14:56:12 | gtema | need to admit was not even looking deeply | |
| 14:56:58 | gtema | aha discover.normalize_version_number returns tuple | |
| 15:00:33 | mordred | yah. there's also some methods in discover for comparing versions | |
| 15:00:57 | gtema | cool, thks | |
| 15:07:33 | AJaeger | openstackclient cores, please review https://review.opendev.org/#/c/661947/3 and https://review.opendev.org/#/c/661974/ to update your docs Sphinx to pass checks again | |
| 15:21:48 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer for next compute methods https://review.opendev.org/663064 | |
| 15:21:53 | openstackgerrit | Merged openstack/openstackclient master: Update sphinx dependency for python 2.7 https://review.opendev.org/661947 | |
| 15:21:54 | openstackgerrit | Merged openstack/openstackclient master: Switch to openstackdocstheme https://review.opendev.org/661974 | |
| 15:22:29 | mordred | AJaeger: done! | |
| 15:22:33 | AJaeger | thanks, mordred ! | |
| 15:24:14 | openstackgerrit | Andreas Jaeger proposed openstack/openstackclient master: Dropping the py35 testing https://review.opendev.org/654658 | |
| 15:24:16 | AJaeger | mordred: one more, please ^ | |
| 15:35:58 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer in cloud for SecurityGroups of server https://review.opendev.org/662998 | |
| 15:42:03 | gtema | mordred: is it ok from your pov not to check presence of both 'ephemeral' and 'OS-FLV-EXT-DATA:ephemeral' for flavors in func tests? | |
| 15:42:11 | gtema | in resource we have ephemeral=OS-FLV-EXT-DATA:ephemeral | |
| 15:42:24 | gtema | but func test expects both | |
| 15:42:50 | gtema | for https://review.opendev.org/#/c/650903/ | |
| 20:07:16 | openstackgerrit | Michael McCune proposed openstack/keystoneauth master: add a handler for unknown HTTP errors https://review.opendev.org/663132 | |
| #openstack-sdks - 2019-06-05 | |||
| 03:25:47 | openstackgerrit | Merged openstack/python-openstackclient master: Compute: Add description support for server https://review.opendev.org/568549 | |
| 07:12:18 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer in cloud for SecurityGroups of server https://review.opendev.org/662998 | |
| 07:50:10 | openstackgerrit | Merged openstack/openstacksdk master: Make factory for a CloudRegion from CONF objects https://review.opendev.org/643601 | |
| 08:05:04 | openstackgerrit | Merged openstack/openstacksdk master: Support Proxy-specific region_name https://review.opendev.org/662865 | |
| 08:08:27 | openstackgerrit | Merged openstack/openstacksdk master: Get rid of unused _OpenStackCloudMixin.get_region https://review.opendev.org/663038 | |
| 09:55:48 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer for next compute methods https://review.opendev.org/663064 | |
| 10:05:05 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.opendev.org/650903 | |
| 11:20:45 | gtema | mordred: what was you planning to to with server normalization? I can't really get your TODO in cloud._compute._list_servers | |
| 11:22:19 | gtema | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_compute.py#L361 | |
| 14:28:59 | mordred | efried: \o/ patch landed | |
| 14:29:14 | efried | mordred: Yes, I am thoroughly excited. Can we get a release? | |
| 14:29:48 | mordred | we can - let me check the queue and see if there's anything else we should land real quick - but I think the next thing up is gtema's stack which is a whole new thing | |
| 14:29:56 | efried | cool | |
| 14:30:35 | mordred | nope. queue is clear - release forthcoming | |
| 14:31:29 | efried | sweet | |