| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-04 | |||
| 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 | |
| 14:31:37 | efried | let me know if you want me to do any of the paperwork, happy to. | |
| 14:32:07 | mordred | remote: https://review.opendev.org/663343 Release 0.30.0 of openstacksdk | |
| 14:32:30 | gtema | this month we have too much releases ;-) | |
| 14:34:47 | gtema | mordred: was asking your earlier today - what is our plan to do with _normalize_server thing? This is the "only" thing remaining for the resource layer of compute | |
| 14:36:29 | efried | mordred: Have you considered putting openstacksdk on an independent release cycle? | |
| 14:38:29 | mordred | gtema: yeah - I'm not 100% sure what my original intent in that comment was ... but the original intent was to get the resource updated so that we don't need the normalize method anymore | |
| 14:38:39 | mordred | I'm not sure what the original_name thing was about though | |
| 14:39:22 | gtema | yeah, I would also gladly move to "no normalize", but since Ansible is using it we get immediately couple of renamings | |
| 14:39:42 | gtema | i.e. accessIPv4 vs access_ipv4 | |
| 14:39:56 | gtema | availability_zone vs az | |
| 14:41:09 | mordred | yah. we'd need to make sure the resource objects are at least returning the names the cloud layer is currently - since that's the one things we know about are consuming and is more of an api we've committed to | |
| 14:41:34 | mordred | of course, maybe we just have it do both things? | |
| 14:41:47 | gtema | ok, thatn I will rework normalize to take everything as is in the resource and add some stuff with older names | |
| 14:42:54 | gtema | does it sound good? But then still this "strict" mode | |
| 14:45:36 | mordred | actually - what if we do this ... | |
| 14:45:49 | mordred | what if we rework the resource to have the same results as normalize in strict mode | |
| 14:46:07 | gtema | hmm | |
| 14:46:16 | gtema | lot of stuff goes under properties | |