| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-23 | |||
| 10:17:21 | openstackgerrit | liyi proposed openstack/python-openstackclient master: Remove log translations https://review.openstack.org/449045 | |
| 12:16:06 | reedip | o/ | |
| 13:45:28 | openstackgerrit | Merged openstack/osc-lib master: The python 3.5 is added https://review.openstack.org/442960 | |
| 13:49:09 | openstackgerrit | Merged openstack/osc-lib master: Pass ssl values through to OCC https://review.openstack.org/438277 | |
| 13:50:11 | cdent | edleafe, elmiko: thoughts on how to proceed on http://gnocchi.xyz/install.html with the disagreement between sdague and mugsie ? | |
| 13:50:50 | cdent | oopth, wrong linke | |
| 13:51:01 | cdent | elmiko, edleafe : https://review.openstack.org/#/c/421846/ | |
| 13:54:29 | openstackgerrit | Merged openstack/osc-lib master: Util methods for column name backward compatibility https://review.openstack.org/436289 | |
| 13:57:05 | edleafe | cdent: I don't like having an Alternatives section in a guideline. I think we should suggest a best practice, and leave it at that. | |
| 13:58:02 | elmiko | cdent: is there any way to work a leg-wrestling match in here? | |
| 13:58:58 | elmiko | i'm a little more lenient i suppose, i could see leaving an even smaller alternatives section that just says we acknowledge alternatives and we recommend against it. | |
| 13:59:29 | elmiko | but for me this goes back to the whole "api police" line | |
| 14:15:51 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Don't duplicate commands https://review.openstack.org/447592 | |
| 14:27:30 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to create legacy router https://review.openstack.org/449176 | |
| 14:29:49 | reedip | dtroyer: there? | |
| 14:30:10 | reedip | ankur-gupta-f4 , sindhu, stevemar ??? | |
| 14:30:37 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to create legacy router https://review.openstack.org/449176 | |
| 14:58:29 | sindhu | reedip: hey, wass up | |
| 14:58:47 | reedip | review requested for https://review.openstack.org/#/c/447938/ | |
| 14:59:23 | reedip | its stuck for reviews .... | |
| 16:08:02 | sindhu | dtroyer: https://review.openstack.org/#/c/382023/ is ready for your review :) | |
| 16:19:41 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstackclient master: Introduce neutron flavor associate, disassociate to OSC https://review.openstack.org/403907 | |
| 16:33:31 | rabel_b1 | can someone tell me what a quota class is? as in "openstack quota set --class ..." ? | |
| 16:51:29 | openstackgerrit | Merged openstack/python-openstackclient master: docs: Don't include ChangeLog https://review.openstack.org/447588 | |
| 17:34:38 | cdent | elmiko, edleafe (anyone else): proof please: https://etherpad.openstack.org/p/api-wg-newsletter | |
| 17:45:00 | cdent | elmiko, edleafe shipped it | |
| 17:52:44 | elmiko | cdent: sorry, was at lunch | |
| 17:53:00 | cdent | no worries, but any flubs are YOUR FAULT | |
| 17:53:02 | cdent | :) | |
| 17:54:51 | elmiko | LOL | |
| 18:04:46 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to create legacy router https://review.openstack.org/449176 | |
| 18:06:53 | edleafe | cdent: yeah, stepped out. LGTM in any case, so it's all elmiko's fault | |
| 18:07:24 | cdent | I can live with that | |
| 18:24:35 | elmiko | haha | |
| 18:24:42 | elmiko | guess i'm out voted? | |
| 18:29:16 | ankur-gupta-f4 | dtroyer: ping | |
| 18:33:42 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstacksdk master: [WIP] Introduce Pool resource in Octavia Load Balancer Base https://review.openstack.org/449264 | |
| 18:34:17 | dtroyer | ankur-gupta-f1: yo | |
| 18:35:45 | ankur-gupta-f4 | hey its about the osc plugin | |
| 18:36:02 | ankur-gupta-f4 | if set up as a pure plugin, how does the interaction with the API happen | |
| 18:36:28 | ankur-gupta-f4 | https://review.openstack.org/#/c/446223/ is the initial patches for the plugin | |
| 18:36:46 | ankur-gupta-f4 | but i also did a skeleton patch for the repo: https://review.openstack.org/#/c/448331/ | |
| 18:37:10 | openstackgerrit | Shashank Kumar Shankar proposed openstack/python-openstacksdk master: [WIP] Introduce Pool resource in Octavia Load Balancer Base https://review.openstack.org/449264 | |
| 18:37:11 | ankur-gupta-f4 | but not sure if the skeleton is needed if the API interaction happens through OSC/SDK. | |
| 18:37:20 | dtroyer | it happens like any other, there is nothing restricting a plugin to only what is in its package | |
| 18:37:49 | dtroyer | remember, everything in the OSC repo itself is built as a plugin, it's just all in the same repo | |
| 18:38:06 | ankur-gupta-f4 | like any other meaning through the SDK. or should the API binding happen within python-octaviaclient | |
| 18:38:19 | dtroyer | so the adidtional things to think about with a plugin in a package with no lib is to make sure you install it's dependencies properly | |
| 18:38:54 | dtroyer | python-octaviaclient implies that it is a python API lib for the Octavia REST API | |
| 18:39:04 | dtroyer | that's what that naming convention is used for | |
| 18:39:31 | dtroyer | the presence of OSC plugins within those is a convenience, just as the presence of the CLi binaries that some have | |
| 18:40:09 | ankur-gupta-f4 | Okay that makes sense. Will continue down the patch I am on then. | |
| 18:40:16 | dtroyer | kk | |
| 18:40:23 | dtroyer | are you using SDK for that? | |
| 18:41:02 | ankur-gupta-f4 | wasn't planning on it. what would be easier | |
| 18:41:11 | ankur-gupta-f4 | our guys will also be introducing Octavia to the SDK as well | |
| 18:41:46 | dtroyer | SDK isn't 1.0 yet, so OSC itself isn't going to use it for anything else for a while. | |
| 18:42:20 | ankur-gupta-f4 | so then I should continue down the skeleton path where all the client bindings happen in the native python-octaviaclient lib | |
| 18:42:25 | dtroyer | eventually it should, but I'm revisiting the openstackclient.api stuff to be able to dump some of the existing lib dependencies sooner | |
| 18:42:55 | ankur-gupta-f4 | Could you comment on this then: https://review.openstack.org/#/c/448331/ to clarify | |
| 18:43:03 | dtroyer | think through the transition plan if you ever want to change that | |
| 18:43:44 | ankur-gupta-f4 | i think its mostly about getting it done at this point since we are trying to get it all done by Pike. Poor planning, but Neutron has put us on the clock | |
| 18:44:14 | ankur-gupta-f4 | also in team meeting there was a discussion about whether the namespace should be "loadbalancer" or "load balancer" | |
| 18:45:03 | dtroyer | is python-octaviaclient a thing already? | |
| 18:45:08 | ankur-gupta-f4 | indeed | |
| 18:45:19 | ankur-gupta-f4 | https://github.com/openstack/python-octaviaclient | |
| 18:45:36 | ankur-gupta-f4 | there is nothing in it yet except the stuff im trying to push up | |
| 18:46:26 | ankur-gupta-f4 | there isn't a release of it yet | |
| 18:46:29 | dtroyer | so why are you creating a stand-alone lib and also an SDK implementation? | |
| 18:47:37 | ankur-gupta-f4 | given what you have mentioned we will halt the SDK implementation I believe and just make a stand alone lib | |
| 18:47:59 | dtroyer | ok. there are a LOT of patterns in the existing client libs that should not be recreated | |
| 18:48:09 | ankur-gupta-f4 | what should be avoided | |
| 18:48:16 | dtroyer | most of it :) | |
| 18:48:38 | dtroyer | seriously, I don't know of a good reference for that | |
| 18:48:56 | ankur-gupta-f4 | okay, reword the question. How would you set it up | |
| 18:49:24 | dtroyer | look at OSC's api tree, which is based off using the KSA session directly and building a low-level API for the REST layer | |
| 18:50:29 | dtroyer | that's what I wanted in the SDK for OSC to use, if that's all you are building, that's the level you need, not the entire manager/resource mapping stuff. | |
| 18:50:48 | dtroyer | even lower level is what is in Shade | |
| 18:51:12 | dtroyer | basically, you want to write your REST client layer to take a KSA session and do things | |
| 18:53:05 | ankur-gupta-f4 | i.e. this? https://review.openstack.org/#/c/448331/2/octaviaclient/client.py | |
| 18:54:29 | dtroyer | yes, OMG, do not do that | |
| 18:54:36 | ankur-gupta-f4 | haha okay | |
| 18:55:12 | dtroyer | that's all the stuff that KSA's Session handles. OSC's ClientManager used to have to do a LOT of work to bypass all that. | |
| 18:56:00 | ankur-gupta-f4 | okay. Burn it all. Try it again seems to be the general message ;) | |
| 18:56:30 | dtroyer | look at OSC's api.objectstore stuff. That _all_ we have for the entire thing | |
| 18:56:50 | dtroyer | the command classes call that instead of swiftclient (which BTW wasn't a thing when I wrote that) | |
| 18:57:55 | ankur-gupta-f4 | looking | |
| 18:59:39 | dtroyer | the code in object_store_v1.py was largely lifted from the original swift CLI so it looks a lot different from everything else for that reason, but that's the sort of structure I would suggest you consider | |
| 19:00:35 | ankur-gupta-f4 | okay. looks simple. But object store still uses the SDK. | |
| 19:00:36 | dtroyer | Shade is even simpler, their equivalent for OSC would be to just make REST calls directly in the command take_action() methods. | |
| 19:00:48 | ankur-gupta-f4 | what is Shade? | |
| 19:01:14 | dtroyer | https://github.com/openstack-infra/shade | |
| 19:01:24 | dtroyer | infra's cross-cloud compatibility layer | |
| 19:01:38 | dtroyer | what OSC is to a CLI, Shade is to trying to use the client libs | |
| 19:02:06 | dtroyer | except that it also addresses the multitude of ways a deployer can configure clouds so the app dev doesn't have to think about that more than necessary | |
| 19:02:16 | dtroyer | as Monty says, Shade's existence is a bug. | |
| 19:04:12 | ankur-gupta-f4 | okay. Will simplify everything down to make REST calls directly to the API. Won't touch SDK for now. | |
| 19:04:50 | dtroyer | I still like the separation between cliff command classes and a Python API layer, but not much more than that. Your call though | |
| 19:05:24 | dtroyer | it lets you re-use things in multiple commands | |
| 19:05:47 | ankur-gupta-f4 | That is a call for the Octavia cores. I will be happy if I can get a 'loadbalancer list' command working soon :) | |