| *** yamamoto has quit IRC | 00:17 | |
| kevinbenton | mestery: is it still office hours? | 00:47 |
|---|---|---|
| *** yamamoto has joined #openstack-neutron-release | 00:57 | |
| *** carl_baldwin has quit IRC | 01:27 | |
| *** amotoki has joined #openstack-neutron-release | 02:04 | |
| *** amotoki has quit IRC | 02:20 | |
| *** amotoki has joined #openstack-neutron-release | 02:31 | |
| *** amotoki has quit IRC | 02:39 | |
| *** amotoki has joined #openstack-neutron-release | 02:39 | |
| *** amotoki has quit IRC | 03:01 | |
| *** yamamoto has quit IRC | 08:58 | |
| *** yamamoto has joined #openstack-neutron-release | 08:58 | |
| kevinbenton | DB folks, can you take a look at review.openstack.org/#/c/166725/ | 09:58 |
| *** amuller has joined #openstack-neutron-release | 11:56 | |
| *** yamamoto has quit IRC | 11:57 | |
| *** yamamoto has joined #openstack-neutron-release | 12:58 | |
| *** yamamoto_ has joined #openstack-neutron-release | 13:02 | |
| *** yamamoto has quit IRC | 13:05 | |
| *** carl_baldwin has joined #openstack-neutron-release | 13:59 | |
| *** amotoki has joined #openstack-neutron-release | 14:00 | |
| *** carl_baldwin has quit IRC | 14:42 | |
| *** carl_baldwin has joined #openstack-neutron-release | 14:59 | |
| *** amotoki has quit IRC | 16:28 | |
| *** amotoki has joined #openstack-neutron-release | 17:11 | |
| *** yamamoto_ has quit IRC | 17:42 | |
| *** amuller is now known as amuller_afk | 18:30 | |
| *** amotoki has quit IRC | 18:49 | |
| dougwig | fellow drivers and LTs, opinions on the API ramfications of this one? https://bugs.launchpad.net/neutron/+bug/1463594 | 18:51 |
| openstack | Launchpad bug 1463594 in neutron "LBaaS drivers can be queried to determine whether they support a feature the API exposes" [Undecided,Confirmed] | 18:51 |
| mestery | dougwig: -1 to that one | 19:23 |
| *** blogan has joined #openstack-neutron-release | 19:27 | |
| dougwig | and his point about flavors? | 19:27 |
| mestery | I left a comment on that one | 19:28 |
| dougwig | k | 19:28 |
| blogan | mestery: can we discuss taht in here instead of in comments? and then add a comment on the resolution if we come to one? | 19:30 |
| mestery | blogan: Ack, good idea! | 19:31 |
| *** yamamoto has joined #openstack-neutron-release | 19:31 | |
| blogan | mestery: alright so are you against that the API would return an error if a particular driver does not support somethign the API does? | 19:32 |
| blogan | err something the API says it does? | 19:32 |
| dougwig | blogan: i think he's against the notion of different providers supporting different behavior. | 19:33 |
| mestery | dougwig: yeah, that | 19:33 |
| dougwig | that's why i flagged it for the driver's group to discuss. | 19:33 |
| mestery | I had a longer reply in progress but I like your tl;dr better | 19:33 |
| blogan | lol | 19:33 |
| mestery | dougwig: What are your thoughts? | 19:33 |
| blogan | doesn't flavors support different behaviors though? | 19:34 |
| mestery | blogan: To some extent, yes, it could be used to expose different backends via a flavor | 19:34 |
| blogan | so the alternative to this is to do what is currently being done and do something the user doesn't expect, PING monitor for example is actually a TCP monitor, minor issue but obviously not what the user intended | 19:34 |
| dougwig | super super fucking torn. on the one hand, not having vendor lock-in on APIs is a big thing with openstack, and can be abused for adding features. on the other hand, it is fucking reality that even within the lowest common denominator feature set, there will be slight variances. the a10 drivers doesn't support APP_COOKIE, haproxy doesn't support hm PING's, | 19:35 |
| dougwig | eg.. | 19:35 |
| dougwig | blogan: flavors are under operator control to deviate, not the driver authors. | 19:35 |
| mestery | dougwig: BINGO! | 19:35 |
| mestery | That's the big difference | 19:35 |
| blogan | dougwig: yeah that is good difference | 19:35 |
| mestery | Thus, flavors > "API query" | 19:35 |
| mestery | ;) | 19:35 |
| blogan | shhh | 19:35 |
| dougwig | i was going to deny the rfe on that basis, but figured i'd give you a shot with the larger group. :) | 19:36 |
| mestery | lol | 19:36 |
| *** yamamoto has quit IRC | 19:36 | |
| blogan | well there's gotta be a better alternative than just taking what the user intent is and then doing something else | 19:36 |
| mestery | rofl | 19:37 |
| dougwig | ideas? maybe add conflicting items as config toggles? or? | 19:37 |
| dougwig | i agree that the current behavior is kinda wonky. like haproxy with PING, if you pass the a10 an APP_COOKIE health monitor, you silently get a HTTP_COOKIE monitor instead. | 19:38 |
| blogan | shouldn't the user be told that something is not exactly what they intended though? | 19:38 |
| mestery | can the backend return an error for things it doesn't support? But, that may not be different than a query since it exposes this anyways ... | 19:39 |
| blogan | right now its minor things that 99% users won't realize | 19:39 |
| dougwig | you can raise a not supported exception, but it becomes messy fast with running the same tests for your CI. | 19:39 |
| dougwig | it works well in v1 because the test coverage is lousy. | 19:39 |
| dougwig | ;) | 19:39 |
| blogan | yeah it could put the object in error status, but then thats not a good UX | 19:40 |
| blogan | lol | 19:40 |
| dougwig | yeah, horizon also doesn't handle the exception backtrace well. | 19:40 |
| blogan | full transparency, this rfe was something i always thought about doing, but procrastinated, then realize it would solve something wwe need to do at RAX for neutron lbaas, so my procrastination ended | 19:42 |
| mestery | :) | 19:43 |
| blogan | which dougwig i've discussed with you a bit before and that is haivng some way decide whether to have the plugin create the vip port or delegate to the drivers | 19:43 |
| dougwig | and the alternative, that is acceptable, it damn close to the same thing. (that being, just try a new driver interface, and if it doesn't exist, try the old one.) | 19:46 |
| dougwig | /it damn/is damn/ | 19:46 |
| blogan | its kind of the same thing but not as it is guaranteed to work all the time since it will try the old one anyway and that should always work | 19:47 |
| blogan | whereas the rfe in question would fail fast | 19:48 |
| blogan | this would continue with doing somethign else, and really its not something else as the user's intention would still be upheld | 19:48 |
| blogan | but its still basically a query to the driver seeing if it supports it, but not in a way that leaks implementation details | 19:49 |
| blogan | mestery: would you be okay with this approach? | 19:49 |
| blogan | i think dougwig is | 19:49 |
| dougwig | both fail fast, since you just query if the new method exists. | 19:49 |
| mestery | so, we're talking about a query to verify if a backend supports a specific API? | 19:50 |
| blogan | but why fail fast if the user doesn't care how the vip is created, if the driver doesn't support vip delegation then it would just create it the normal way | 19:50 |
| blogan | mestery: no in this specific case, the neutron lbaas plugin creates the vip port before it even passes control to the driver, so drivers are guaranteed a vip port is created for them | 19:51 |
| mestery | OK | 19:51 |
| blogan | mestery: but in some cases, a driver may want to cotnrol how the vip is atually allocated, it may be accomplished with a different method | 19:51 |
| dougwig | blogan: would you be willing to write up a spec with the specific use cases and a high-level description of the interface you want? | 19:54 |
| blogan | dougwig: certainly | 19:54 |
| dougwig | let's punt to the spec, then. | 19:55 |
| mestery | yes | 19:58 |
| blogan | no implementation details right? just what and why? | 19:58 |
| mestery | yes | 19:59 |
| mestery | :) | 19:59 |
| blogan | lets just say it goes back to the cells and segment support :) as usual in our case | 20:00 |
| blogan | thanks for the discussions though, i can update that rfe with what was decided | 20:01 |
| blogan | actually should i make a new rfe since what we're discussing is quite different? | 20:01 |
| dougwig | nah, just morph it. | 20:01 |
| blogan | ok | 20:01 |
| blogan | was hoping to give you some pleasure by denying one of my rfes, i know how much you'd enjoy it | 20:02 |
| dougwig | you can get yourself towed in colorado and i'll be good. | 20:02 |
| blogan | oh im not going now | 20:02 |
| blogan | i did what was best for clb in this particular instance :( because i'm dummy | 20:03 |
| *** amuller_afk is now known as amuller | 21:01 | |
| *** carl_baldwin has quit IRC | 23:05 | |
| *** yamamoto has joined #openstack-neutron-release | 23:22 | |
| *** yamamoto has quit IRC | 23:26 | |
| *** yamamoto has joined #openstack-neutron-release | 23:32 | |
| *** yamamoto has quit IRC | 23:34 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!