| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-04 | |||
| 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 | |
| 14:46:19 | mordred | those are the "interface" | |
| 14:46:32 | mordred | well - we can have the resources handle _more_ things than normalize did | |
| 14:47:14 | gtema | but still there would be rename then in the resource layer - backward incompat | |
| 14:48:17 | gtema | having adminPass in resource layer is not something we want | |
| 14:50:19 | mordred | yah - lemme give a quick concrete example | |
| 14:50:23 | mordred | and see what you think | |
| 14:50:28 | gtema | ok | |
| 14:51:16 | mordred | (also, it just occurred to me - maybe we should have a CreatedServer resource object which is a subclass of Server but also has adminPass - and is just returned from create_server | |
| 14:51:46 | mordred | because that adminPass is important in that moment, but you're right- it's kind of wrong for it to be there normally | |
| 14:53:45 | gtema | well, adminPass is just one example, hostId, config_drive vs has_config_drive, all accessIPvX | |
| 14:54:25 | gtema | and then all the complex names like OS-EXT-SRV-ATTR:hypervisor_hostname | |
| 14:54:31 | mordred | here's the first stab I did here: https://review.opendev.org/#/c/630912 | |
| 14:57:47 | gtema | yeah, looks interesting. Where "Computed"-ones are calculated? | |
| 14:58:17 | mordred | in the constructor | |
| 14:58:43 | mordred | (get_supplemental_addresses) | |
| 14:59:24 | mordred | but the idea being basically we do everything we can with normal resource attribute mappings - and for the things now in normalize that we just cant' do in resource attributes directly, we can always do in a constructor or something | |
| 14:59:27 | gtema | ok, so overload it constructor also to invoke it? | |
| 14:59:31 | mordred | (server is by far the most complicated example here) | |
| 14:59:59 | gtema | ok, got it. Will play around | |
| 15:00:22 | mordred | cool - I'll also review the ones you've got already | |
| 15:00:32 | gtema | cool, thks | |
| 15:00:43 | mordred | gtema: end goal is for the cloud layer to return the same resource objects that the non-cloud layer returns | |
| 15:00:54 | mordred | so that they're essentially interchangable | |
| 15:01:15 | gtema | yeah | |
| 15:01:20 | mordred | oh - another thing (unrelated, but related to stuff you've been hacking on) | |
| 15:03:17 | mordred | the whole "filter client side vs filter server side" - it seems there are 3 different combinations that people might want | |
| 15:03:33 | mordred | 1) only filter client side (nodepool wants this) | |
| 15:03:58 | mordred | 2) filter server side as much as possible then filter anything else client side (what most people want I think) | |
| 15:04:40 | mordred | 3) only filter server side and thrown an error if someone tries to filter on something that can only be filtered client-side (some people in the past have indicated they want this) | |
| 15:05:05 | mordred | should we have maybe more than one method so people can pick their behavior? or a standard behavior flag someone can pass? | |
| 15:05:06 | gtema | yeah, so 3 is what we have now out-of-box | |
| 15:05:15 | gtema | 2) is what I am implementing in this stack | |
| 15:05:33 | mordred | yah - but the cloud layer does 1 currently | |
| 15:05:40 | gtema | and for 1) nodepool should then simply do compute.servers() and filter results | |
| 15:05:53 | mordred | yeah - maybe that's the best idea | |
| 15:06:03 | gtema | yes, cloud is doing 1) now | |
| 15:06:15 | mordred | because honestly nodepool is probably the only consumer who actually wants that behavior | |
| 15:06:23 | gtema | yupp | |
| 15:06:38 | mordred | Shrews: ^^ thoughts from you? | |
| 15:08:24 | mordred | gtema: we could probably provide a helper method in sdk for "please list and then filter client side" that has its own name that we could have nodepool use, but that most people would not | |