*** 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!