Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-03-28
22:52:02 dtroyer EmilienM: looks like it merged, I need to get some things going yet, will request the release tomorrow, it's queued up and ready to fire
22:52:20 EmilienM woot
22:52:25 EmilienM dtroyer: thank you, i'll help a lot
22:52:31 EmilienM it'll help a lot I mean
22:56:45 dtroyer my apologies for this taking so long… my time for OSC is down to $FAR_TOO_LITTLE
23:01:19 EmilienM no worries :)
#openstack-sdks - 2018-03-29
01:15:42 openstackgerrit Merged openstack/osc-lib master: add lower-constraints job https://review.openstack.org/556059
04:03:54 openstackgerrit Logan V proposed openstack/os-client-config master: Add Limestone Networks vendor info https://review.openstack.org/557139
04:23:16 openstackgerrit Merged openstack/python-openstackclient master: Fix additional output encoding issues https://review.openstack.org/554698
07:46:08 openstackgerrit Sami Makki proposed openstack/python-openstackclient master: Fix the `role implies list` command. https://review.openstack.org/557359
13:21:04 openstackgerrit Merged openstack/python-openstackclient master: add lower-constraints job https://review.openstack.org/556172
13:23:21 openstackgerrit Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/553257
13:24:10 jpich dtroyer: Hi! I'm told RDO needs tagged releases to be able to consume backports on stable branches so I took the liberty to post a couple of release patches for osc and cliff. Hopefully that's ok, I'm not sure if that helps or if it's just as much work on your side - please let me know if there's something I could do differently! Thank you.
13:24:39 jpich dhellmann: I see you're the release liaison for OSC so this may be relevant ^, just fyi and fmi too on the preferred way to handle things! :)
13:55:21 dtroyer jpich: I am planning an OSC release today anyway, just now getting back to check if the reviews I was waiting on passed...
13:55:41 dtroyer \o/
13:56:30 dtroyer Oh, yes, I missed you were talking about stable, I'll look at that next. thanks
13:57:05 jpich Awesome!! And no problems, good luck with all the releasing :)
13:57:43 dtroyer thanks, we're way overdue.
14:22:44 dtroyer EmilienM:  osc 3.15.0 on its way https://review.openstack.org/557716 \o/ finally
14:24:57 dtroyer jpich: +! on both pike releases… there was an SDK compat issue in stable/queens so OSC 3.14.1 is in the queue too
14:40:53 EmilienM dtroyer: thanks a lot!
14:42:19 jpich dtroyer: Awesome, thank you!
14:42:59 dtroyer I just found a backport of the —mtu option to queens, will merge that before the 3.14.1 release
14:50:44 dtantsur cdent: hey! our meeting is in 1:10, right? /me has summer time now
14:51:28 cdent dtantsur: yeah, that's right. I'm disoriented too
14:51:48 dtantsur cool! my calendar shows it correctly, but it was incorrect for another meeting, soooo... :)
15:49:24 openstackgerrit Merged openstack/python-openstackclient master: Update help text for encryption provider https://review.openstack.org/545459
15:53:03 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Run normalize_keys on config for session codepath https://review.openstack.org/547159
16:00:27 elmiko cdent: around?
16:00:41 cdent sigh, this is going to happen every week
16:01:01 elmiko lol, only till the fall =)
16:05:21 cdent no, it's because of tc office hours being right before api-sig, and they move in sync
16:05:25 cdent elmiko: ^
16:05:35 elmiko ahhh
16:06:21 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove the need for OpenStackConfig in CloudRegion https://review.openstack.org/547488
16:08:14 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add image_format for VEXXHOST profile https://review.openstack.org/557748
16:08:40 openstackgerrit Monty Taylor proposed openstack/os-client-config master: Replace guts with openstack.config https://review.openstack.org/549307
16:11:49 mordred SamYaple, Shrews, rods, slaweq: if you have a sec, I'd like to land 547159, 547488, 556089 and 555710 and then cut an sdk release
16:17:21 SamYaple mordred: 547488 is in merge conflict
16:22:47 mordred bother
16:46:29 openstackgerrit Monty Taylor proposed openstack/api-wg master: Update parameter names in microversion sdk spec https://review.openstack.org/557773
16:46:47 mordred dtantsur, elmiko, cdent, edleafe: ^^ there's one
16:47:33 elmiko mordred: wow, quick draw mcmordred!
16:48:02 dtantsur mordred: to be honest, I hate it
16:48:28 dtantsur I guess you were not in the room in Dublin when I was ranting about "micro"?
16:48:38 openstackgerrit Merged openstack/api-wg master: Add guideline on exposing microversions in SDKs https://review.openstack.org/532814
16:48:53 dtantsur tl;dr "micro" only makes any sense to 3-6 people involved in API SIG, and absolutely no sense to everyone else
16:50:18 mordred dtantsur: that's fair - but we have two completely different types of versions with completely different semantics
16:50:24 mordred dtantsur: I mean, I don't like the name either
16:50:53 dtantsur mordred: similarly to what we discussed today, I would like the major version to be taken from the "just version"
16:51:08 dtantsur it would be different if we did not include the major version in the microversion
16:51:21 dtantsur (see it already makes little sense - a major version is contained in a micro!)
16:51:47 mordred dtantsur: so - unfortunately, we have services that didn't implement microversions (yet) and include minor versions in their api versions
16:52:03 dtantsur oh
16:52:04 mordred glance 2.8, for instance
16:52:05 dtantsur my
16:52:07 dtantsur god
16:52:09 dtantsur ...
16:52:13 mordred dtantsur: welcome to my personal hell :)
16:52:27 dtantsur mordred: I started glance in rust-openstack, it's my hell as well now..
16:52:34 mordred :)
16:53:01 mordred dtantsur: so if we re-use, then people might erroneously think they can say get_image(api_version=2.8) - which they actually can't do
16:53:27 mordred dtantsur: yah
16:53:28 dtantsur mordred: can we then invent a better name for microversions?
16:53:39 mordred dtantsur: fine by me
16:53:44 mordred dtantsur: "per api call version"
16:54:14 dtantsur maybe we should call it "revision"? like, avoid "version" completely?
16:54:33 mordred I mean - it's actually "endpoint_version" and "call_version" - as one is used to find the endpoint in the keystone catalog and one is used to impact specific behavior on the endpoint found in the catalog
16:55:05 mordred but I don't think either of those words are good words
16:57:13 dtantsur still slightly better than "microversion" IMO
16:57:25 dtantsur anyway, I left a -1 for now with the goal of giving it some thought over the weekend
16:57:50 mordred dtantsur: fwiw, I've contended for a while that microversions aren't actually any different from regular versions from an end-user perspective, they're just an alternate versioning mechanism. the main difference is that the python-*client libraries all make using catalog version discovery basically impossible, so adding microversions was a way to add version discovery that could be used by the broken
16:57:52 mordred python-*client libraries
16:58:03 mordred when what we should have done is just fixed the client libraries and made them stop being broken
16:58:49 dtantsur yep, we should have..
16:59:00 dtantsur everytime I look at ironicclient I want to just rewrite it
16:59:06 mordred dtantsur: just delete it
16:59:10 mordred dtantsur: shift to openstacksdk
16:59:14 dtantsur lol
16:59:27 dtantsur well, it may be the eventual course of our actions
16:59:34 mordred dtantsur: ++
16:59:39 dtantsur but the problem is: people don't want to dedicate much time to these clients
16:59:46 dtantsur they're kind of secondary
17:00:26 mordred yah. exactly. this is why just using the sdk - or direct rest calls - is better - we don't have the collective resources to maintain all of python-*client
17:01:57 mordred dtantsur: but yeah - let's ponder the naming over the weekend and chat next week more (also, sorry I wasn't in the room in dublin)
17:05:53 JudeC Hey guys, we noticed an issue when using the python-openstackclient to view limits. If Cinder isn't enabled the limits command will fail reporting that it is unable to find an endpoint for Cinder.
17:06:27 JudeC I was considering proposing a "compute limits show" command to get around this issue.
17:07:22 JudeC Unless someone else has a better suggestion for us.
17:16:02 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Run normalize_keys on config for session codepath https://review.openstack.org/547159
17:16:03 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove the need for OpenStackConfig in CloudRegion https://review.openstack.org/547488
17:16:12 mordred SamYaple: thanks. fixed the merge conflict
17:16:58 edleafe mordred: yeah, nothing "micro" about them for users. They are full versions.
17:22:19 openstackgerrit Merged openstack/openstacksdk master: Add support for trunk ports and subports https://review.openstack.org/556089
17:24:20 cdent elmiko, dtantsur|afk , edleafe https://etherpad.openstack.org/p/api-sig-newsletter please and thank you
17:29:13 edleafe cdent: the microversion history stuff isn't really a guideline, thoguh
17:29:15 edleafe though
17:29:33 edleafe not even a "sort of a guideline"
17:31:06 dtroyer JudeC: the command needs to check for the presence of the volume service-type in the service catalog similar to how it already does for netowrk
17:31:10 cdent it's an appendix

Earlier   Later