| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-29 | |||
| 18:34:14 | openstackgerrit | Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025 | |
| 19:13:25 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488 | |
| 19:26:22 | openstackgerrit | Ed Leafe proposed openstack/api-wg master: Recommend the correct HTTP method for tags https://review.openstack.org/451536 | |
| 19:35:30 | dtroyer | frickler: /me catches up a bit | |
| 19:36:26 | dtroyer | The default compute API version is a bit of a mess because it may be set by OSC or by os-client-config. In either case it is '2' or '2.1'. This is equivalent to the Compute API itself that uses '2.1' if no microversion header is included in a request | |
| 19:36:54 | dtroyer | we accepted that behaviour because it meant OSC was backward-compatible | |
| 19:37:31 | dtroyer | as you've seen, specifying a microversion in —os-compute-api-version (or clouds.yaml) does work | |
| 19:37:44 | dtroyer | here's what I would like to do, need to get some feedback: | |
| 19:38:19 | dtroyer | change the meaning of version '2' to be '2.latest' without actually using the 'latest' text that the apiref warns is meant for testing. | |
| 19:38:52 | dtroyer | so while novaclient is available, we'd use novaclient.API_MAX_VERSION as the default for '2' | |
| 19:43:56 | frickler | dtroyer: sounds reasonable to me, seems like that would kind of ensure feature parity between osc and novaclient like for the volume status output | |
| 19:45:32 | frickler | dtroyer: also, using cloud.cfg with an explicit compute API version selected might in fact be a good enough workaround for me. I've been wanting to dump our openrc stuff in favor of that for some time now anyway | |
| 20:55:17 | openstackgerrit | Jim Rollenhagen proposed openstack/os-client-config master: Docs: add a note about rackspace API keys https://review.openstack.org/451563 | |
| 21:00:56 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/api-wg master: Clarify the meaning of BODY https://review.openstack.org/451568 | |
| 21:32:07 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Listener for Octavia (load balancing) https://review.openstack.org/451574 | |
| 22:18:31 | jamielennox | dtroyer: so the part i've always been stuck with is how to do negotiation | |
| 22:18:44 | jamielennox | it's pretty easy to add a header, and even do the discovery bit | |
| 22:19:03 | jamielennox | dtroyer: quieter here :) | |
| 22:19:23 | dtroyer | I'm just at discovery/negotiation | |
| 22:19:38 | jamielennox | dtroyer: the part i don't know how to do is the fallback for do X if something is available else do Y | |
| 22:19:46 | dtroyer | since for the moment novaclient is handling that. but the discovery they do is in the shell so OSC doesn't get it | |
| 22:19:51 | dtroyer | I think I'm glad for that | |
| 22:20:15 | jamielennox | i hate so much that they expose this stuff to the shell | |
| 22:20:18 | dtroyer | I think that is a higher-level problem. I see the version exception stuff going all the way up to OSC's command classes | |
| 22:21:02 | dtroyer | yeah, that was a good first-cut in novaclient, time to generalize cleanly :) | |
| 22:21:42 | jamielennox | dtroyer: so i'm keen to put that information into ksa, i just don't know how so if you come up with something at least we can discuss from there | |
| 22:21:44 | dtroyer | do you have an opinion on using a Version class like novaclient does? I did that in one of my other early attempts at this, not sure if that should go into ksa though | |
| 22:21:59 | jamielennox | will need to have another look at novaclient | |
| 22:22:51 | dtroyer | I'm going to work in osc I think for now until it becomes clearer. this is tightly tied into the plugin mechanism for osc | |
| 22:23:02 | jamielennox | dtroyer: do they do version class for microversions/ | |
| 22:23:12 | dtroyer | but the atomic bits can and shold go somewhere common | |
| 22:23:18 | dtroyer | yes | |
| 22:23:40 | dtroyer | nothing there is specific to microversions, it's just an x.y representation. I did x.y.z before… | |
| 22:24:22 | jamielennox | i have very simplistic versions of that in discover | |
| 22:24:54 | jamielennox | but i don't think there is any way to check a minimum there - because it never needed to | |
| 22:25:03 | jamielennox | so yea, i'd be happy to take that | |
| 22:25:15 | jamielennox | i think there is a version of that in one of the oslo libs already - but we can redirect that to ksa | |
| 22:27:54 | jamielennox | dtroyer: a possible implementation might be a request class you can pass to ksa? subclass the request() bit with a number of if microversion >x<y stuff | |
| 22:28:14 | jamielennox | i think i'll let you play with it | |
| 22:28:40 | jamielennox | though one of the things i meant to do after atlanta was draw up a new version of a cross-project discovery page | |
| 22:28:52 | dtroyer | I need to make version decisions in commands before I get that far | |
| 22:28:57 | jamielennox | something that did major and microversion discovery - and probably capabilities on the same request | |
| 22:29:00 | dtroyer | oooh, that would be helpful at some point :) | |
| 22:29:37 | jamielennox | ya, if we just put it on a new content-type and say ksa works if you implement this i think we might actually get some traction as opposed to last time i did it | |
| 22:33:05 | jamielennox | dtroyer: anyway i can wait and make sure to put everything we actually need in there first | |
| 22:33:27 | jamielennox | dtroyer: so on another front did you have a look at the os-c-c-2 WIP i put up | |
| 22:33:30 | jamielennox | ? | |
| 22:33:37 | jamielennox | i cannot figure out what i want that interface to look like | |
| 22:33:50 | dtroyer | I did last week and wasn't exactly sure I understood it all | |
| 22:34:19 | jamielennox | yea, i didn't make it easy, it was all experimenting and no comments | |
| 22:35:21 | dtroyer | I am ok with the current interface, basically decomposing get_one_cloud() so I can insert things and leave out other things is what I'm looking for | |
| 22:35:47 | dtroyer | that auth plugin loading bit me again this week | |
| 22:36:12 | dtroyer | it happens waaaaaay to early in o-c-c | |
| 22:37:05 | jamielennox | dtroyer: agreed, i'm not sure i want people overriding it | |
| 22:37:12 | jamielennox | my thought was it should be simply a datastore | |
| 22:37:29 | jamielennox | but i got way into the weeds | |
| 22:39:19 | dtroyer | that would be my preference | |
| 22:40:25 | dtroyer | I would love to hand it an argparse Namespace, have it merge that with clouds.*, do all of the hacky things to make interop work and be done | |
| 22:41:49 | jamielennox | that's part of where i was getting caught up, does o-c-c control the parser, what about envs? | |
| 22:43:28 | jamielennox | how do you handle the AllClouds object vs the get_one_cloud case | |
| 22:43:49 | dtroyer | OSC does the parser and env (via argparse) | |
| 22:43:55 | dtroyer | I don't look at AllClouds at all | |
| 22:44:06 | jamielennox | yea, but o-c-c has to maintain that | |
| 22:44:10 | dtroyer | altough commands to work with clouds.yaml might | |
| 22:44:29 | dtroyer | right, that's fine | |
| 22:45:15 | dtroyer | I would be OK with there being a common set of argparse declaration in o-c-c, but I want control over it | |
| 22:46:52 | dtroyer | working with this again Monday I realized just how f-ed up OSC's use of the auth plugins is. IS it work fixing that before this rewrite is done? do those go together? | |
| 22:51:05 | jamielennox | dtroyer: i've attempted to mess with osc's auth plugins before and can never find a way to exactly maintain compatibility | |
| 22:51:14 | jamielennox | but i don't think you should wait for o-c-c | |
| 22:51:41 | dtroyer | we can't avoid breaking some things. I'm preparing for a 4.0 where we can make some changes there | |
| 22:52:36 | dtroyer | since _everything else_ is doing some things differently than OSC, maybe its time OSC adjusts a bit | |
| 22:53:28 | jamielennox | would be nice to have the o-c-c fixed up for then | |
| 22:53:33 | jamielennox | not sure how likely that is though | |
| 22:54:09 | dtroyer | yeah, I expected some things to change there. I don't knwo what the timing of 4.0 is, June/July at the absolute earliest | |
| 22:56:32 | dtroyer | one other thing that's bugging me: you mentioned a long time ago that I should be making requests adapters rather than sessions. | |
| 22:57:03 | dtroyer | I'm thinking I need to fix that too | |
| 23:04:40 | jamielennox | dtroyer: so adapters were a direct response to how you create a client once and then reuse it with the same parameters | |
| 23:05:16 | jamielennox | it meant you could do things like set the service_type on an object and make calls via that rather than set it every time on a session.request | |
| 23:05:51 | jamielennox | it's _probably_ easier give that you do like a create_client thing that returns something specific to that usage | |
| 23:06:07 | jamielennox | but if you know what you're doing with a session you may not need it | |
| 23:06:46 | jamielennox | it really depends on how you want to use it | |
| 23:07:30 | dtroyer | ok. I was looking at shade and wanting to converge some of the lower-level stuff a bit more. I've got to implement some nova-net stuff that's being removed from novaclient so I was looknig again at OSC' api layer stuff | |
| #openstack-sdks - 2017-03-30 | |||
| 00:31:57 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/451606 | |
| 01:52:06 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: start using api.versions https://review.openstack.org/451618 | |
| 01:52:43 | dtroyer | jamielennox: ^^^ is a very quick attempt at microversion handling in osc. openstackclient.api.versions is the bit that I'm thinking about for ksa | |
| 02:28:32 | reedip | stevemar ; there ? | |
| 04:18:39 | reedip | RuiChen : there? | |
| 04:40:15 | openstackgerrit | Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/451606 | |
| 06:22:17 | openstackgerrit | Thomas Bechtold proposed openstack/python-openstacksdk master: Fix doc build if git is absent https://review.openstack.org/451662 | |
| 06:42:22 | reedip | RuiChen : ping | |
| 08:36:27 | rabel | good morning! | |
| 08:36:48 | reedip | its evening ! :D | |
| 08:37:38 | rabel | :D good evening, reedip | |
| 10:05:07 | openstackgerrit | Thomas Bechtold proposed openstack/python-openstacksdk master: Fix doc build if git is absent https://review.openstack.org/451662 | |
| 12:15:58 | openstackgerrit | Merged openstack/python-openstacksdk master: Fix doc build if git is absent https://review.openstack.org/451662 | |
| 13:01:41 | RuiChen | we have IRC meeting now? | |
| 13:01:52 | reedip | we do ? | |
| 13:03:22 | RuiChen | I'm not sure, but today is thursday | |
| 13:05:04 | dtroyer | it's later today, 1900 UTC | |
| 13:05:21 | reedip | whats the time now ?? | |