| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-03 | |||
| 18:03:19 | elmiko | sdague: agreed | |
| 18:03:43 | elmiko | bare in mind that i'm mainly talking about projects that may not be hot-beds of openstack activity. (for example sahara) | |
| 18:03:47 | edleafe | elmiko: re: bitrot - yeah, agreed. That's why I don't subscribe to the "once an API is released, you have to maintain it forever" school of thought | |
| 18:04:09 | edleafe | elmiko: see: https://blog.leafe.com/api-longevity/ | |
| 18:04:15 | sdague | edleafe: it mostly depends on who has control over the deployment | |
| 18:04:39 | sdague | so... if sahara wasn't a thing the cloud operator deployed, but a thing that I deployed in my tenant | |
| 18:04:48 | elmiko | if my, downstream, employer has hot demands on what goals they would like to see for a particular cycle, it can extremely difficult to get traction for spending signifcant time doing a microversion re-write | |
| 18:04:49 | sdague | then I've got control on the upgrade cycle | |
| 18:04:59 | sdague | which makes it like vendored libraries | |
| 18:05:07 | sdague | and, then I think some of these concerns go away | |
| 18:05:13 | elmiko | sdague: totally agree | |
| 18:05:21 | elmiko | in-tenant services is a fantastic idea | |
| 18:05:31 | sdague | but when the user has no control of the upgrade schedule | |
| 18:06:06 | sdague | ... I have a hard time understanding a different path then the one we've taken | |
| 18:06:21 | elmiko | i feel like this is an area where, due to no ones fault, there are "services" that are embedded into the control plane which would be better served as application riding on top of openshift | |
| 18:06:40 | elmiko | er, openstack | |
| 18:06:46 | elmiko | sorry.. too many open* | |
| 18:06:57 | cdent | elmiko bleeds red | |
| 18:06:58 | sdague | heh | |
| 18:07:04 | elmiko | FOR THE HAT!!!! | |
| 18:07:17 | edleafe | sdague: I'm totally agreed on the microversion approach that nova has followed | |
| 18:07:27 | sdague | elmiko: yeh, that would have been an interesting different road to have taken | |
| 18:07:40 | elmiko | honestly though, i've doing way more with kubernetes recently and the model of deploying "heroic" services on top the orchestration substrate is a powerful idea | |
| 18:07:49 | edleafe | sdague: but I'm trying to find a middle ground to help improve all OpenStack APIs, even for those projects that reject microversions | |
| 18:08:08 | elmiko | sdague: ack, c'est la vie ;) | |
| 18:08:32 | sdague | elmiko: I do kind of wonder if zaneb's ideas around application tokens might get us back headed towards that path | |
| 18:08:55 | elmiko | sdague: i have not seen that written up, but it sounds interesting | |
| 18:09:07 | cdent | elmiko: https://review.openstack.org/#/c/447031/ | |
| 18:09:13 | elmiko | cdent++ | |
| 18:09:29 | sdague | edleafe: sure, I applaud that effort. However, I also feel like we've got a set of services where this matches well, and it would be nice to get that flag in the ground. | |
| 18:09:32 | cdent | (in the links in the bottom) | |
| 18:10:20 | dtroyer | ZZelle: hey | |
| 18:11:02 | elmiko | i totally agree with the thought that for certain "core" services, mandating microversions is a much stronger idea. but that takes us away from the big tent idea | |
| 18:12:01 | cdent | (I'm going to need to go at any moment now, I think, if there's a concrete outcome to this conversation that is germane to the doc, can somebody leave a new comment there so I can act on it?) | |
| 18:12:12 | elmiko | cdent: ack | |
| 18:12:17 | cdent | thanks | |
| 18:12:39 | ZZelle | dtroyer, about your comment in https://review.openstack.org/#/c/452328/1/doc/source/command-objects/server.rst | |
| 18:12:50 | ZZelle | dtroyer, i am not sure to understand what you mean | |
| 18:13:33 | cdent | I think being more specific about the scope of the doc and the rigor of the standard being set is probably a good way to go, especially if we leave open the option (we always do) for more docs later | |
| 18:13:34 | cdent | That moves the doc forward | |
| 18:13:45 | cdent | but I don't know that that helps us with what might be called the social problem. | |
| 18:13:58 | cdent | but it may be we don't need to do anything about that | |
| 18:14:06 | dtroyer | its just the form of the help line, we put the '(name or ID)' test at the end pretty much everywhere, except some differences have snuck in. Fix yours, I'll get the other ones | |
| 18:14:26 | dtroyer | there's an RST error in there too that stevemar noted but +2'd anyway | |
| 18:14:53 | ZZelle | dtroyer, so something like 'Server ... (name or ID).' instead of 'Server (name or ID) ...'? | |
| 18:15:04 | stevemar | ZZelle: yep | |
| 18:15:13 | ZZelle | stevemar, dtroyer good for me | |
| 18:15:17 | dtroyer | yes. look at nearly every other command in that file than the add commands near yours | |
| 18:15:18 | elmiko | cdent: imo, for a guideline that will define a tag, it should be as explicit as possible in terms of the hoops needed to jump through | |
| 18:15:37 | elmiko | so, that may speak to having 2 separate docs | |
| 18:17:23 | cdent | I remain a bit unclear on what the second doc is | |
| 18:18:48 | elmiko | i guess that would be needed if we couldn't make the first one specific enough? | |
| 18:19:02 | elmiko | or just having 2 tags or something, one for interop and one for ? | |
| 18:19:32 | cdent | yes, that blank is what I'm blank on | |
| 18:19:48 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to add/remove port to/from a server https://review.openstack.org/452328 | |
| 18:19:54 | ZZelle | stevemar, dtroyer ^^ | |
| 18:21:38 | elmiko | cdent: yeah, sadly, i have no better answers here =( | |
| 18:22:07 | dtroyer | ZZelle: thanks | |
| 18:22:42 | cdent | elmiko: no worries. if/when edleafe comes back he may have something, I gotta run to dinner, thanks for the input, we'll figure something out. | |
| 18:22:53 | elmiko | cdent: cool, enjoy o/ | |
| 18:23:35 | stevemar | ZZelle: ohhh are you cedric? | |
| 18:27:01 | sshank | dtroyer, I think https://review.openstack.org/#/c/403907/ (flavor associate, dissociate) is ready for reviews. | |
| 18:28:29 | openstackgerrit | Ankur proposed openstack/python-openstacksdk master: Introduce Base for Octavia (load balancing) https://review.openstack.org/428414 | |
| 18:32:49 | openstackgerrit | Ankur proposed openstack/python-openstackclient master: Network L3 Router Commands for OSC https://review.openstack.org/385729 | |
| 18:39:15 | dtroyer | ankur-gupta-f1: re https://review.openstack.org/#/c/449757/, why are you filtering the show output? we've removed specific fields before, I don't understand why you are treating this one like a list command | |
| 18:55:31 | openstackgerrit | Merged openstack/python-openstackclient master: Add help commands withouth auth in functional https://review.openstack.org/452407 | |
| 19:01:51 | ankur-gupta-f4 | dtroyer: based on the api response. Since the advanced commands hit different endpoints that the normal list commands | |
| 19:02:06 | ankur-gupta-f4 | I can go back thru them do verify if you want | |
| 19:03:20 | dtroyer | what happened to advanced commands going into plugins? | |
| 19:04:24 | ankur-gupta-f4 | Because its not advanced in the sense that certain features have to be enabled to use the commands. Its just a complex endpoint | |
| 19:05:06 | dtroyer | right, that's what I thought made it different. 'advanced services' has a specific meaning in neutron | |
| 19:05:39 | ankur-gupta-f4 | Yea. Will reword it. Sorry for confusion | |
| 19:06:00 | ZZelle | stevemar, yes i am | |
| 19:06:15 | dtroyer | but that doesn't change a) different endpoint and b) the same resource isn't represented by the same fields? | |
| 19:06:25 | dtroyer | what endpoint is it? | |
| 19:07:11 | ankur-gupta-f4 | i.e. for routers for the list command it hits /v2.0/routers for the list routers --agent <agent-id> it hits /v2.0/routers/<router-id>/l3-agents i believe | |
| 19:07:29 | dtroyer | ok, again, endpoint has a specific meaning: service catalog thing | |
| 19:07:42 | dtroyer | that's a route in wsgi terms | |
| 19:07:53 | dtroyer | so much overloading of words! | |
| 19:07:53 | ankur-gupta-f4 | okay. route. | |
| 19:08:12 | dtroyer | so the server returns a different object in that case? | |
| 19:08:27 | ankur-gupta-f4 | correct | |
| 19:08:40 | dtroyer | and the SDK doesn't fill it out? this is one place I'd expect the SDK's high-level-ness to step in and make things look right | |
| 19:08:41 | ankur-gupta-f4 | https://github.com/openstack/python-openstacksdk/blob/master/openstack/network/v2/router.py#L134 is how the route is determined in the SDK | |
| 19:09:37 | dtroyer | we should just start issuing random 3 letter names for all of these different things | |
| 19:10:53 | ankur-gupta-f4 | route, complex command, idiotic API.. should suffice | |
| 19:11:08 | dtroyer | so, back to the issue at hand, is —router a filter or a type specifier? | |
| 19:13:03 | ankur-gupta-f4 | not a filter in the sense that it filters the resulting data from hitting the common list route. rather a flag to indicate that instead of hitting the usual list route, to hit the specific route that would return a different routers list object from the API. | |
| 19:15:20 | dtroyer | ok, the problem is that the columns are different | |
| 19:16:20 | dtroyer | in your examples the router ID is the same so it is that the server returns a different object, except it is still the same router at each endpoint? | |
| 19:17:06 | ankur-gupta-f4 | yes | |
| 19:17:36 | ankur-gupta-f4 | well.. | |
| 19:19:10 | ankur-gupta-f4 | the example I posted, the paste.openstack.org link, was just to show that the commands are still listing the correct items | |
| 19:20:23 | dtroyer | so I clearly still don't understand wtf neutron is doing here. If I were to say: make a router list command always show the same columns, eept for -c and —long, what would you suggest? | |
| 19:21:49 | ankur-gupta-f4 | I just ran the commands in --debug to look at the dicts. | |
| 19:21:54 | openstackgerrit | Nakul Dahiwade proposed openstack/python-openstacksdk master: Introduce Listener for Octavia (load balancing) https://review.openstack.org/451574 | |
| 19:22:31 | ankur-gupta-f4 | It should be possible to have all the list commands return the same values. | |
| 19:23:02 | ankur-gupta-f4 | what we can do is have all the list commands have the same columns. | |
| 19:23:10 | ankur-gupta-f4 | then if the certain agent flag is given | |
| 19:23:15 | ankur-gupta-f4 | append the additional columns | |