| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-29 | |||
| 16:26:25 | reedip | wait | |
| 16:26:57 | reedip | http://paste.openstack.org/show/604690/ | |
| 16:27:50 | reedip | The --check resources is | |
| 16:27:52 | reedip | Does not return a topology. | |
| 16:27:52 | reedip | --check-resources Validate the requirements for auto allocated topology. | |
| 16:28:19 | reedip | ankur-gupta-f4 : I guess the current tenant ID needs to be used up | |
| 16:28:33 | reedip | for aut-allocated-topology with --check-resource | |
| 16:29:11 | ankur-gupta-f4 | so its just not passing, getting from context, the tenant/project id | |
| 16:29:23 | reedip | guess so | |
| 16:29:40 | ankur-gupta-f4 | bah. annoying. | |
| 16:29:57 | reedip | welcome to my world :D | |
| 16:30:20 | reedip | that was the last patch on _proxy | |
| 16:30:25 | reedip | https://github.com/openstack/python-openstacksdk/commit/e5068ec46aa7bb6b1738b8a64c29e44307f4ba98 | |
| 16:30:59 | reedip | seems like it fixed some. broke some | |
| 16:31:03 | reedip | maybe | |
| 16:35:49 | ankur-gupta-f4 | hmmm | |
| 16:36:04 | ankur-gupta-f4 | its weird because the fix from terry was in the last release of the SDK | |
| 16:36:13 | ankur-gupta-f4 | :( | |
| 16:36:21 | reedip | did it have the check for --check-resources? | |
| 16:36:49 | ankur-gupta-f4 | yea --check-resources his the Validate... function in auto_allocated_topology and the changes are there | |
| 16:37:30 | reedip | hmm lem edebug | |
| 16:37:53 | reedip | wait I think my code is not up to date ! | |
| 16:39:00 | reedip | I have 0.9.13 | |
| 16:39:59 | reedip | Upgraded to 0.9.14 and now checking | |
| 16:40:05 | reedip | it works ! | |
| 16:40:10 | reedip | thats weird ! | |
| 16:40:38 | ankur-gupta-f4 | yea | |
| 16:40:53 | ankur-gupta-f4 | its a matter of bumping global reqs | |
| 16:42:04 | reedip | done! | |
| 16:42:34 | reedip | He may have pulled up the master for OSC but not SDK | |
| 16:42:50 | reedip | if he is on Neutron, then lemme drop him a ping | |
| 16:47:40 | ankur-gupta-f4 | briancurtin: here? | |
| 16:48:05 | reedip | ankur-gupta-f4; that bug is now closed ( or would be soon ) | |
| 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 | |