Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-03-29
16:50:45 ankur-gupta-f4 k thanks
16:51:21 reedip :)
17:01:59 openstackgerrit Nakul Dahiwade proposed openstack/python-openstacksdk master: [WIP] Introduce Member for Octavia (loadbalancing) https://review.openstack.org/451488
17:28:15 openstackgerrit Ankur proposed openstack/python-openstackclient master: Network L3 Router Commands for OSC https://review.openstack.org/385729
18:33:47 openstackgerrit Sindhu Devale proposed openstack/python-openstackclient master: "floating ip set/unset port" for OSC https://review.openstack.org/383025
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

Earlier   Later