| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-02-07 | |||
| 15:33:32 | mordred | Qiming: awesome. messaging is their 'old' service type ... I've got a patch half-finished that should fix that issue - I'll try to get it finished today | |
| 15:33:37 | frickler | mordred: hmm, that still seems to fail the non -tips check | |
| 15:34:20 | mordred | frickler: yes - it pulled in 0.11.2 of sdk in its last run which does not contain the fixes | |
| 15:34:58 | mordred | frickler: but the constraints bump landed, so this run SHOULD be ok | |
| 15:35:39 | frickler | mordred: ah, great, thx | |
| 15:37:52 | dtroyer | mordred: thanks for watching the store for me the last while… I may finally be home again for a bit now… | |
| 15:59:10 | mordred | dtroyer: no worries! sorry for the breakage - but I think we've got the gate jobs fixed to actually catch such breakages in the first place | |
| 16:51:28 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Use openstacksdk for most transitive depends https://review.openstack.org/541796 | |
| 16:57:46 | mordred | dtroyer: I think http://logs.openstack.org/54/540554/3/check/osc-functional-devstack-tips/e8fc19f/testr_results.html.gz is an unrelated issue and I should just recheck that patch, yes? | |
| 16:58:52 | openstackgerrit | Merged openstack-infra/shade master: Allow not resolving outputs on get stacks https://review.openstack.org/541244 | |
| 16:59:40 | mordred | rods_, SamYaple, slaweq: if you have sec, take a quick peek at https://review.openstack.org/541796 - I'd like to get that in and then cut shade's queens release | |
| 17:08:02 | openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Use openstacksdk for most transitive depends https://review.openstack.org/541796 | |
| 17:09:21 | rods_ | mordred https://review.openstack.org/#/c/541796/2 LGTM | |
| 17:09:26 | mordred | rods_: thanks! | |
| 17:11:16 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Add shade jobs to openstacksdk zuul config https://review.openstack.org/541802 | |
| 17:11:25 | rods_ | mordred what else is needed to land https://review.openstack.org/#/c/540169/? | |
| 17:11:27 | mordred | rods_: similar/related ^^ | |
| 17:11:48 | mordred | rods_: we just need to land the three patches in front of it | |
| 17:12:25 | mordred | rods_: although I kinda think we should wait for https://review.openstack.org/#/c/540556/ so we can verify we don't break osc ... | |
| 17:12:33 | mordred | rods_: lemme rebase that stack on the jobs | |
| 17:14:20 | rods_ | mordred +2 on https://review.openstack.org/#/c/541802/1 | |
| 17:32:56 | dtroyer | mordred: yes, aggregates are an occasional race-like issue | |
| 17:52:01 | mordred | dtroyer: cool. I've rechecked. it should be green this time | |
| 18:04:45 | johnsom | dtroyer Have a minute to give the Octavia team some input on a new OSC command? | |
| 18:04:56 | dtroyer | johnsom: sure | |
| 18:05:31 | johnsom | dtroyer Thank you sir. We have a need to expose some "driver" specific commands targeted to admins. | |
| 18:05:36 | johnsom | dtroyer https://etherpad.openstack.org/p/octavia-drivers-osc | |
| 18:06:21 | johnsom | dtroyer The team likes "openstack octavia amphora failover" where octavia is the project name, amphora is the "load balancing element (service vm currently). | |
| 18:07:25 | johnsom | dtroyer I warned them that we tend to stay away from project code names in the commands. In this case the "octavia amphora ..." is all driver dependent and will return "Not implemented" if the driver isn't loaded into octavia, etc. | |
| 18:07:50 | johnsom | dtroyer We seek you CLI wisdom... grin | |
| 18:08:19 | dtroyer | yes, I really try to discourage using project names in CLIs, the resources should be named descriptively, but generically | |
| 18:08:28 | mordred | johnsom: SO ... I just discovered something that i'm going to bug you about during the rocky cycle | |
| 18:08:41 | mordred | johnsom: octavia does not have a version discovery document | |
| 18:09:26 | johnsom | mordred Ha, ok. Yes, this is on the todo list to make sure we have that figured out. We dump some version info based on the API-wg doc at the time, but need to understand that better for sure. | |
| 18:10:16 | johnsom | mordred Can you put a story in for us with a pointer of the "right way", maybe a project example? | |
| 18:10:16 | mordred | johnsom: I discovered it because of an sdk patch that's failing functional tests on octavia things (so yay for testing!) | |
| 18:10:33 | mordred | johnsom: I will TOTALLY put in a story for you and work to make sure it's all done right | |
| 18:10:45 | mordred | johnsom: (and I can work around it sdk-side for now) | |
| 18:10:59 | johnsom | mordred Thank you. I can probably hammer it out pretty quickly with the right guidence | |
| 18:11:17 | mordred | yah- it should be super simple | |
| 18:11:44 | dtroyer | johnsom: so "amphora" is the name of the type of service vm? | |
| 18:11:48 | johnsom | dtroyer So, my other worrry is: "openstack octavia", "openstack f5", "openstack radware", etc. | |
| 18:12:16 | johnsom | dtroyer https://docs.openstack.org/octavia/latest/reference/glossary.html | |
| 18:12:34 | dtroyer | at some point we break this overloading of the "openstack" command. maybe this is approaching one of those places? IDK | |
| 18:12:45 | johnsom | dtroyer it's an element of the octavia driver that does the load balancing. Could be service vm, container, baremetal, etc. | |
| 18:13:50 | johnsom | dtroyer Yeah, it's a bit interesting. The need is there for admin commands for the plugin drivers. | |
| 18:14:11 | dtroyer | my first (sime-uninformed) reaction is to suggest just using "amphora" as the top-level resource. It is closer to a project name in style than a resource description, but might make snese in this case | |
| 18:14:23 | dtroyer | s/sime/semi/ | |
| 18:14:31 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Cleanup the BaseProxy docs a bit https://review.openstack.org/539270 | |
| 18:14:31 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Shift config exceptions to openstack.exceptions https://review.openstack.org/539396 | |
| 18:14:32 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Generate proxy methods from resource objects https://review.openstack.org/540169 | |
| 18:14:32 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Rename BaseProxy to Proxy https://review.openstack.org/539271 | |
| 18:14:33 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Use get_session_client in Connection https://review.openstack.org/541060 | |
| 18:14:33 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Calculate name in CloudRegion https://review.openstack.org/541059 | |
| 18:14:47 | johnsom | dtroyer This is why I was thinking making a namespace under the overall service, "openstack loadbalancer" might be the best idea. Then the plugins can just expand that as needed. | |
| 18:14:49 | mordred | rods_: ^^ rebased that stack on the OSC tips enablement patch | |
| 18:14:57 | dtroyer | johnsom: the big win with that is "amphora" is likely to be unique | |
| 18:15:24 | dtroyer | I really try to not use the word "namespace" as it is subtly different from the way OSC names resources | |
| 18:15:25 | johnsom | dtroyer The downside is only the "octavia" driver has "amphora". F5 doesn't for example. | |
| 18:15:35 | rods_ | mordred cool, I'll give a look at all of them in a few minutes | |
| 18:15:50 | mordred | dtroyer: yah - I think in this case it'sa driver-specific function for admins who have deployed that driver, so having them do 'openstack amphora blah' doesn't seem super bad to me | |
| 18:16:06 | dtroyer | johnsom: so maybe that is why we use it bare? it names the resource directly. Is there a parallel for f5 or other drivers? | |
| 18:16:56 | johnsom | dtroyer Speaking out of line since I don't work for F5, maybe "bigIP"???? | |
| 18:17:07 | johnsom | dtroyer or "LTM" | |
| 18:18:03 | dtroyer | the point being that other lb drivers may have a similar concept, if they do, is using amphora for the octavia driver setting a good or bad precedent? | |
| 18:18:04 | johnsom | dtroyer So we would be ok with third party OSC plugins that add top level commands? | |
| 18:19:08 | dtroyer | johnsom: mostly, yes. we do ask for plugins to play nice and register resource names with OSC, but can not enforce that | |
| 18:19:59 | dtroyer | and when we get into areas where there are multiple implementations of a thing, we either need to hide that from the user, or if the user is expected to know and care about the difference, make it logical for them | |
| 18:20:50 | johnsom | dtroyer Ok, so "openstack octavia amphora failover" = "openstack <driver> <element><command>" | |
| 18:20:52 | dtroyer | is the use of LB drivers "one-per-cloud"? or could a deployment have multiple? it does sound like the user of this CLI will need to kow in any case | |
| 18:21:13 | johnsom | dtroyer "openstack amphora failover" = "openstack <element> <action>" | |
| 18:21:17 | dtroyer | think this way: openstack <resource-name> <action> | |
| 18:21:32 | johnsom | dtroyer most deployments use two or more load balancing drivers | |
| 18:21:36 | dtroyer | your suggestion is resource-name == "octavia amphora", mine is == "amphora" | |
| 18:23:37 | dtroyer | johnsom: ok, for the other drivers, how will users think about driver-specific stuff? I'm looking for the name of the driver-specific resources, they might begin with something parallel to amphora for octavia. this is a space I don't have much experience with | |
| 18:23:49 | johnsom | dtroyer Ok, I think we have good guidance to bring to our meeting today. The meeting is at 20:00 UTC today in #openstack-lbaas if you want to join the conversation. | |
| 18:24:37 | johnsom | dtroyer For non-admin commands, they have little knowledge of the driver. They simply do "openstack loadbalancer create --provider <driver name>" | |
| 18:25:38 | dtroyer | johnsom: I'll be on the phone most of the afternoon… ok, so using a name that identifies the driver as part of the admin driver-specific resource nmae is appropriate I think | |
| 18:28:23 | dtroyer | johnsom: I left a couple of comments in that etherpad | |
| 18:28:30 | johnsom | dtroyer Thank you | |
| 19:19:51 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: WIP Handle unversioned endpoints with no discovery document https://review.openstack.org/541844 | |
| 19:23:36 | mordred | dtroyer: https://review.openstack.org/#/c/540554/ <-- that's green now! dhellmann if you're around too | |
| 19:24:05 | mordred | dtroyer, dhellmann: this is the fix for the gate job issue that let us release sdk with changes that broke osc | |
| 19:25:01 | mordred | dtroyer, dhellmann: and https://review.openstack.org/#/c/540556 is the corresponding SDK change that's going through recheck right now | |
| 19:25:06 | dhellmann | dtroyer beat me to it | |
| 19:25:10 | dtroyer | mordred: +W and thank you! | |
| 19:25:50 | mordred | woot! | |
| 19:30:56 | openstackgerrit | Monty Taylor proposed openstack/python-openstackclient master: Make Profile fallback go bye-bye https://review.openstack.org/540541 | |
| 19:31:25 | mordred | dtroyer: there's the followup for post-queens to remove the profile fallback code | |
| 20:01:49 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Calculate name in CloudRegion https://review.openstack.org/541059 | |
| 20:05:47 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Use get_session_client in Connection https://review.openstack.org/541060 | |
| 20:25:48 | openstackgerrit | Merged openstack-infra/shade master: Use openstacksdk for most transitive depends https://review.openstack.org/541796 | |
| 20:26:17 | openstackgerrit | Monty Taylor proposed openstack/os-service-types master: Update from service-types-authority https://review.openstack.org/541864 | |
| 20:51:02 | EmilienM | hi | |
| 20:54:19 | mordred | EmilienM: please don't tell me that the latest openstacksdk release has broken tripleo in new and creative ways | |
| 20:54:38 | mordred | EmilienM: I think the release team might kill me if I have to release another point release during freeze :) | |
| 20:54:58 | mordred | EmilienM: (I'm kidding, obviously tell us if something broke) | |
| 20:55:55 | mordred | dtroyer: if you have a sec, wanna pull the trigger on sdk gating on osc tips? https://review.openstack.org/#/c/540556/ | |
| 20:56:37 | stevebaker | mordred: we're just talking optimal default behaviour when someone ctrl-c's a command | |
| 20:56:56 | mordred | oh good. that sounds like an osc question :) | |