| *** RamT has joined #openstack-gslb | 15:54 | |
| RamT | hi | 15:59 |
|---|---|---|
| RamT | hi all | 16:00 |
| RamT | @mugsie you there? | 16:01 |
| mugsie | hey | 16:09 |
| mugsie | sorry, was distracted :) | 16:09 |
| mugsie | RamT: ^ | 16:10 |
| RamT | hey | 16:12 |
| RamT | :) | 16:12 |
| mugsie | we dont seem to be having meetings on a regular basius | 16:12 |
| mugsie | most of us are on other projects full time, so not much time to do on kosmos | 16:12 |
| RamT | ok | 16:13 |
| RamT | we can meet anytime it's convenient for you | 16:13 |
| mugsie | now is good | 16:13 |
| RamT | ok | 16:13 |
| RamT | so last time we were talking about the loadbalancer_parameters | 16:13 |
| RamT | and you were saying that it's not a good idea | 16:13 |
| mugsie | yeah | 16:13 |
| mugsie | basically, anything that can be changed by a driver is a problem | 16:14 |
| RamT | what about monitor_parameters or pool or pool_member_parameters | 16:14 |
| mugsie | they are predefined, and will be the same across instances | 16:14 |
| mugsie | (so people can use the same tools to create glbs across providers) | 16:14 |
| mugsie | monitor_parameters are things like "port", "http_path", "user", etc | 16:15 |
| RamT | yes but they can mean different to different providers | 16:15 |
| mugsie | so it is different per monitor type (http monitors, will have different options to tcp) | 16:16 |
| RamT | as we are not setting them to be constant we might end up each provider defining them in their own way | 16:16 |
| mugsie | well, kosmos's original designate was to have it do the monitoring | 16:16 |
| mugsie | so there was no provider involved | 16:16 |
| RamT | if we have monitors done by kosmos then yes | 16:16 |
| mugsie | well, thats a core part of the design | 16:17 |
| mugsie | if you off load that, there is no point in kosmos | 16:17 |
| mugsie | just stick keystone auth infront of the current API | 16:17 |
| RamT | well I have a situation where it is expected to be offloaded | 16:17 |
| mugsie | humm | 16:17 |
| mugsie | one of the core kosmos ideas was that *it* did the monitoring | 16:18 |
| RamT | so can we have it work both ways | 16:18 |
| mugsie | as that allowed providers to swap out drivers as they see fir | 16:18 |
| mugsie | fit* | 16:18 |
| RamT | like leave the choice to implementor | 16:18 |
| mugsie | I really dont like thaty | 16:18 |
| mugsie | as it has the same problem I said before | 16:18 |
| mugsie | users have no idea what they are getting | 16:19 |
| RamT | so here is what I think | 16:19 |
| mugsie | (that can be fine for some people - just not for an openstack project) | 16:19 |
| RamT | what if we have main parameters like port, http_path, moved to monitor object | 16:20 |
| RamT | which are common across multiple platforms and rest remain in parameters | 16:20 |
| mugsie | the montor could be anything. | 16:20 |
| mugsie | ICMP, SSH, authenticated HTTP, etc | 16:20 |
| RamT | yes | 16:21 |
| RamT | ok | 16:21 |
| mugsie | why does the monitoring have to be offloaded? | 16:21 |
| RamT | my glsb provider does monitoring on his own | 16:22 |
| mugsie | remeber for this to go to openstack, the reference implementation needs to be open source | 16:22 |
| RamT | yes | 16:22 |
| RamT | ok let me give it another thought | 16:22 |
| mugsie | so, it will need to be kosmos doing monitoring, and then something like designate moving DNS records | 16:23 |
| mugsie | does your provider allow you to make rapid updates to their API ? | 16:23 |
| RamT | no they do not | 16:23 |
| RamT | that is a bottle neck | 16:23 |
| mugsie | because you could do the monitor yourself, and then uipdate | 16:23 |
| mugsie | ah | 16:23 |
| mugsie | :( | 16:23 |
| RamT | Let me give it another thought | 16:24 |
| mugsie | OK | 16:24 |
| RamT | I'll get back to you on this one. | 16:24 |
| RamT | by next Tuesday I'll come up with what can be moved forward on Kosmos... | 16:24 |
| RamT | I would like to keep it same as upstream... | 16:25 |
| RamT | and figure out a way as how to integrate it with my provider.. and slowly move towards complete kosmos solution... | 16:25 |
| mugsie | great | 16:25 |
| mugsie | ping me / drop a comment on the review | 16:25 |
| RamT | where we can take advantage of rapid changes through the api | 16:25 |
| RamT | yeah sure | 16:26 |
| RamT | ttyl mugsie | 16:26 |
| RamT | have a good day | 16:26 |
| mugsie | you too | 16:26 |
| RamT | can we save this conv.? | 16:26 |
| mugsie | RamT: http://eavesdrop.openstack.org/irclogs/%23openstack-gslb/%23openstack-gslb.2017-03-07.log.html | 16:27 |
| mugsie | it is running a bit behind, but the logs will be there | 16:27 |
| RamT | ok | 16:27 |
| RamT | thank you | 16:27 |
| RamT | OnO | 16:27 |
| *** RamT has left #openstack-gslb | 16:28 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!