rm_work | xgerman_: ah you mean a rebase? | 00:00 |
---|---|---|
rm_work | my own patch should have added enough skip_tests? | 00:00 |
*** yamamoto has quit IRC | 00:04 | |
*** annp has quit IRC | 00:20 | |
*** annp has joined #openstack-lbaas | 00:21 | |
*** harlowja has joined #openstack-lbaas | 00:26 | |
*** harlowja has quit IRC | 00:27 | |
*** longkb has joined #openstack-lbaas | 00:43 | |
*** yamamoto has joined #openstack-lbaas | 01:00 | |
*** yamamoto has quit IRC | 01:06 | |
sapd_ | rm_work: How do you tun your loadbalancer? What tool did you use? | 01:21 |
rm_work | ? | 01:22 |
*** hongbin has joined #openstack-lbaas | 01:27 | |
*** yamamoto has joined #openstack-lbaas | 02:02 | |
*** yamamoto has quit IRC | 02:07 | |
*** sapd_ has quit IRC | 02:45 | |
*** yamamoto has joined #openstack-lbaas | 03:04 | |
*** yamamoto has quit IRC | 03:09 | |
*** sapd has joined #openstack-lbaas | 03:44 | |
*** ramishra has joined #openstack-lbaas | 03:49 | |
bzhao__ | johnsom: ping, hi michael, "net.ipv4.vs.conntrack" configuration(/proc/sys/net/ipv4/vs) not exist before a keepalived start which hold a lvs, and the amp namespace happen in plug vip during create lb, so sysctl --system into amp namespace happened there, at that moment, amp ns can not load the kernel configuraion. If we do not reload the system configuraion in udp logic, that seems "net.ipv4.vs.conntrack" still | 03:52 |
bzhao__ | is 0... :(.. But for "net.ipv4.ip_forward" is OK. | 03:52 |
*** hongbin has quit IRC | 03:55 | |
johnsom | bzhao__ Hi | 03:55 |
johnsom | bzhao__ Ok, it is likely a kernel module that exposes that path, so try this, before you start the keepalived, run an "lsmod" then start keepalived and do another "lsmod" and compare. Then you should see some kernel modules loaded. If so, we can modprobe those modules (or insmod depending on the module) to load it early and be able to set the setting | 03:57 |
johnsom | bzhao__ It is 9pm before a holiday here, so I'm not at my computer any longer. | 03:58 |
*** yamamoto has joined #openstack-lbaas | 04:05 | |
bzhao__ | johnsom: OK, thanks very much. I think today it could be done. Also happy holiday and good night. :) | 04:10 |
johnsom | bzhao__: ok, cool. I worked on UDP today. I left one comment about the stats. Good news is the performance looks pretty good in my tests. | 04:12 |
johnsom | Will continue to focus on the on Thursday | 04:12 |
johnsom | I got my other priority task done today | 04:13 |
bzhao__ | johnsom: HA. :). Thanks. Never mind. But I lack so many tests, I will add them then. | 04:13 |
*** yamamoto has quit IRC | 04:13 | |
bzhao__ | johnsom: Sorry , Uts or some tests | 04:14 |
bzhao__ | johnsom: Take a good rest. :) | 04:14 |
*** yamamoto has joined #openstack-lbaas | 04:18 | |
*** kobis has joined #openstack-lbaas | 05:25 | |
*** kobis has quit IRC | 05:42 | |
*** ispp has joined #openstack-lbaas | 06:56 | |
*** kobis has joined #openstack-lbaas | 07:09 | |
*** rcernin_ has quit IRC | 07:13 | |
*** AlexStaf has quit IRC | 07:16 | |
*** ispp has quit IRC | 07:20 | |
*** ianychoi has quit IRC | 07:20 | |
*** tesseract has joined #openstack-lbaas | 07:28 | |
*** kiennt26 has joined #openstack-lbaas | 07:38 | |
*** ktibi has joined #openstack-lbaas | 07:50 | |
*** yboaron has joined #openstack-lbaas | 07:56 | |
*** ispp has joined #openstack-lbaas | 08:01 | |
*** ktibi has quit IRC | 08:37 | |
*** ktibi has joined #openstack-lbaas | 08:40 | |
*** sapd has quit IRC | 08:56 | |
*** sapd has joined #openstack-lbaas | 08:56 | |
openstackgerrit | Merged openstack/octavia master: Enable oslo_config mutable configurations https://review.openstack.org/579391 | 08:57 |
*** apuimedo has joined #openstack-lbaas | 09:16 | |
*** kobis has quit IRC | 09:58 | |
*** yboaron_ has joined #openstack-lbaas | 10:01 | |
*** yboaron has quit IRC | 10:04 | |
*** kiennt26 has quit IRC | 10:07 | |
*** kobis has joined #openstack-lbaas | 10:27 | |
*** crazik has joined #openstack-lbaas | 10:47 | |
crazik | hello | 10:47 |
crazik | What should happen if I shutdown MASTER amphora (ACTIVE_STANDBY layout)? | 10:49 |
crazik | switch to STANDBY (role->MASTER) and recreate second with STANDBY role? | 10:50 |
crazik | Looks like at my setup something is wrong, both amphoras were replaced by new ones. | 10:51 |
*** yboaron has joined #openstack-lbaas | 11:03 | |
*** yboaron_ has quit IRC | 11:05 | |
*** annp has quit IRC | 11:33 | |
*** peereb has joined #openstack-lbaas | 11:52 | |
*** longkb has quit IRC | 12:14 | |
*** ispp has quit IRC | 12:32 | |
*** yamamoto has quit IRC | 12:33 | |
*** ispp has joined #openstack-lbaas | 12:34 | |
*** yamamoto has joined #openstack-lbaas | 12:54 | |
*** yamamoto has quit IRC | 12:54 | |
*** yamamoto has joined #openstack-lbaas | 12:55 | |
*** ispp has quit IRC | 14:04 | |
*** xcc has joined #openstack-lbaas | 14:05 | |
*** ispp has joined #openstack-lbaas | 14:05 | |
*** ramishra has quit IRC | 14:18 | |
*** ramishra has joined #openstack-lbaas | 14:22 | |
johnsom | crazik: yes, the failed amp should be replaced. Note, the roles in the database are settings, not the current state of which amp is master | 14:47 |
*** ramishra has quit IRC | 14:51 | |
*** ramishra has joined #openstack-lbaas | 14:53 | |
*** yboaron has quit IRC | 15:04 | |
*** ramishra has quit IRC | 15:20 | |
*** kobis has quit IRC | 15:21 | |
*** kobis has joined #openstack-lbaas | 15:54 | |
*** sapd1 has joined #openstack-lbaas | 16:11 | |
*** peereb has quit IRC | 16:21 | |
*** ispp has quit IRC | 16:21 | |
*** tesseract has quit IRC | 16:30 | |
*** ktibi_ has joined #openstack-lbaas | 16:42 | |
*** ktibi has quit IRC | 16:45 | |
*** kobis has quit IRC | 17:18 | |
cgoncalves | yay! neutron-lbaas stable/queens fixed. kudos to johnsom! | 17:33 |
johnsom | Oh good! Now we have a bunch of rechecks... | 17:34 |
cgoncalves | all done | 17:36 |
johnsom | Thanks! | 17:36 |
cgoncalves | probably worth tagging stable/queens once all cherry-picks get merged | 17:37 |
cgoncalves | I've been seeing quite a few DNS issues at CI recently. for example: http://logs.openstack.org/07/579707/1/check/neutron-lbaasv2-dsvm-py3x-api-namespace/09f9d06/job-output.txt.gz#_2018-07-04_17_33_46_990335 | 17:44 |
cgoncalves | I can resolve http://mirror.ca-ymq-1.vexxhost.openstack.org/wheel locally | 17:45 |
cgoncalves | mnaser, ^ do you happen to know? | 17:46 |
mnaser | cgoncalves: interesting, let me see. | 17:59 |
cgoncalves | mnaser, more here (apt command): http://logs.openstack.org/14/578014/1/check/octavia-v1-dsvm-scenario-multinode/20c191c/job-output.txt.gz#_2018-07-04_17_46_18_292722 | 17:59 |
mnaser | cgoncalves: i've noticed this issue before but i dont actually have control over mirror vm | 17:59 |
mnaser | oh thats interesting | 17:59 |
mnaser | a dns failure | 17:59 |
mnaser | let me talk to infra | 17:59 |
cgoncalves | thanks | 18:00 |
*** sapd1 has quit IRC | 18:06 | |
crazik | johnsom: thanks! | 18:25 |
*** kobis has joined #openstack-lbaas | 18:39 | |
*** kobis has quit IRC | 19:07 | |
*** kobis has joined #openstack-lbaas | 19:08 | |
*** kobis has quit IRC | 19:09 | |
*** kobis has joined #openstack-lbaas | 19:10 | |
*** kobis has quit IRC | 19:19 | |
nmagnezi | o/ | 19:56 |
johnsom | #startmeeting Octavia | 20:00 |
openstack | Meeting started Wed Jul 4 20:00:04 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
*** openstack changes topic to " (Meeting topic: Octavia)" | 20:00 | |
openstack | The meeting name has been set to 'octavia' | 20:00 |
johnsom | Hi folks! | 20:00 |
nmagnezi | O/ | 20:00 |
cgoncalves | hi | 20:00 |
johnsom | I'm guessing this will be a quick one as the US is on holiday today. | 20:00 |
johnsom | But since we are an international team I figured we should still have our meeting as scheduled. | 20:00 |
johnsom | #topic Announcements | 20:01 |
*** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 20:01 | |
cgoncalves | oh, right. what are you doing here today?! :) | 20:01 |
nmagnezi | johnsom, don't miss out the fireworks! :) | 20:01 |
johnsom | cgoncalves It's called dedication to the PTL role.... Grin | 20:01 |
johnsom | My normal reminder, we have a priority bug list for the Rocky release: | 20:01 |
johnsom | #link https://etherpad.openstack.org/p/octavia-priority-reviews | 20:02 |
nmagnezi | johnsom, four more years!.. mm.. cycles :) | 20:02 |
johnsom | Thank you to everyone that has been helping there! | 20:02 |
* johnsom sighs | 20:02 | |
johnsom | Also a heads up, python-octaviaclient needs to have it's final Rocky release before July 26th per the release calendar | 20:02 |
johnsom | #link https://releases.openstack.org/rocky/schedule.html | 20:03 |
johnsom | So any additions we want to get into the "official" Rocky version of the client needs to be in by the 26th. | 20:03 |
nmagnezi | aye. We have some client patches to get in.\ | 20:03 |
johnsom | I think we have two right now, backup members and the UDP extensions (which I have been testing). | 20:03 |
johnsom | If there are any others not on that list, let me know so I can keep track of them and make sure we get them in | 20:04 |
cgoncalves | FWIW I quickly tested the backup member patch and looked good to me | 20:05 |
johnsom | The last item I have is about the recent queens breakage in neutron-lbaas. However I understand this is now resolved. | 20:05 |
johnsom | Cool, thanks! | 20:05 |
cgoncalves | it is. thank YOU! | 20:05 |
nmagnezi | johnsom, great job! | 20:05 |
johnsom | FYI, the trouble with stable/queens started with this patch: https://review.openstack.org/576526 | 20:06 |
nmagnezi | I reviewed bunch of queens backports today so we can have those in soon | 20:06 |
cgoncalves | jobs are arbitrarily failing due to DNS failures. rechecking should do the trick | 20:06 |
johnsom | Someone added neutron-lbaas to upper constraints and then later global requirements. | 20:06 |
johnsom | If you look in those files, none of the "plugins" horizon or neutron are in those files | 20:07 |
johnsom | This is because the tests for these plugins need to install the "parent" project, neutron in our case, from a filesystem path (zuul) or git (tox) and you can't set an upper-constraint limit on those install types. | 20:08 |
*** kobis has joined #openstack-lbaas | 20:09 | |
johnsom | Anyway, we got those changes reverted. They should not have been approved as requirements changes on stable branches are against the stable policy, but that is a different issue. | 20:09 |
johnsom | cgoncalves Thanks for the rechecks and looking into that DNS issue. I know Mr. Naser is working to fix it. | 20:09 |
*** kobis has quit IRC | 20:10 | |
johnsom | Any other announcements today? | 20:10 |
johnsom | #topic Brief progress reports / bugs needing review | 20:10 |
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 20:10 | |
*** kobis has joined #openstack-lbaas | 20:11 | |
johnsom | I have wrapped up the initial version of the neutron-lbaas to octavia LB migration tool. I have been working on the gate to test it, which was a pain with little Ansible gotchas. | 20:11 |
* nmagnezi still waits for the magical local.conf :-) | 20:11 | |
johnsom | Like the one where it merges stderr into the stdout content from the "neutron" command | 20:11 |
johnsom | Yeah, I need to do another spin to take another approach at getting two drivers enabled in neutron-lbaas. | 20:12 |
johnsom | I will poke at that after the meeting. | 20:12 |
johnsom | Anyway, the second test will migrate a non-octavia LB (even though there is no octavia driver for it) as a test. | 20:13 |
nmagnezi | Will that migration tool work for migration from n-lbaas (any provider) to Octavia as a keystone endoint? | 20:13 |
johnsom | Should be good soon-ish. I plan to make it a periodic gate | 20:13 |
johnsom | Yes, any neutron-lbaas provider to Octavia. Octavia should have the appropriate provider installed of course. | 20:14 |
johnsom | It sounds like VMware is making good progress on their provider driver, so likely to see that soon. They already have a third party gate setup. | 20:14 |
johnsom | The tool will not migrate from one provider to a different provider on Octavia. That is not it's intent. | 20:15 |
johnsom | I think that is possible, but a bunch more work that probably wouldn't make Rocky | 20:15 |
johnsom | Then after that work I am focusing on helping with the UDP support. | 20:16 |
nmagnezi | I think we should think about at least haproxy-ns to amphora driver migration since both are reference implementations. But maybe that is something I will follow up with, after you migrate what you plan for Rocky | 20:16 |
johnsom | I have been doing some testing. I was able to push 4.76 Gbits/sec through it on my little devstack setup, so performance looks decent. We just have some stuff to finish up there. | 20:17 |
johnsom | Yeah, technically the namespace driver ceased to be a reference driver in Liberty, but I'm not sure that was communicated well. | 20:17 |
johnsom | Agreed though, that is a really good use case. | 20:18 |
johnsom | Feel free to start work on it.... grin | 20:18 |
nmagnezi | Sadly many folks still use it, and migration path might help them to move :-) | 20:18 |
nmagnezi | Haha, first we finish yours. I plan to test it | 20:19 |
johnsom | I have "ideas" of how to do it if someone wants to work on it. | 20:19 |
johnsom | Cool, thanks! | 20:19 |
johnsom | It "should" work now, I'm really just poking at the gate tests | 20:19 |
johnsom | After UDP is in good shape I need to work on an active/standby test gate. (internal request) | 20:20 |
johnsom | Any other progress updates? | 20:21 |
johnsom | #topic Open Discussion | 20:22 |
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)" | 20:22 | |
johnsom | Any other topics today? | 20:22 |
cgoncalves | not much from my side. essentially backporting patches and working in tripleo to have an octavia scenario with octavia tempest tests | 20:22 |
johnsom | Cool. I really appreciate the help with backports BTW. | 20:23 |
johnsom | I know you mentioned cutting a new release, should we do that around MS3 time or would you like it sooner? | 20:23 |
*** fnaval has joined #openstack-lbaas | 20:24 | |
cgoncalves | I *think* I don't have a preference. I just thought that it would be nice to release since we have backported a couple of good stuff | 20:24 |
nmagnezi | On my side, I'm currently digging into Active Standby, looks like data plane takes longer than expected time to recover (but the backup amp does send GARPS, so.. still looking) | 20:25 |
johnsom | Yeah, agreed. Ok, I will set a mental upper bound on MS3 timeline | 20:25 |
johnsom | Yeah, that is interesting. If we see the GARPs coming out of the backup that became master, but traffic isn't getting to us, then something is fishy in neutron land. Well worth looking into. | 20:26 |
cgoncalves | nmagnezi, that reminds me of the MASTER/BACKUP role topic we discussed offline | 20:26 |
nmagnezi | And by longer.. It took it 8 minutes to recover on my devstack. So definitely something worth looking into | 20:26 |
johnsom | Yeah, that is crazy | 20:26 |
cgoncalves | but maybe we can leave it to another time | 20:26 |
nmagnezi | cgoncalves, yeah, this is something I'm also looking into. Trying to find a way to determine the nodes state in a reliable way so we can report it to Octavia. | 20:27 |
johnsom | cgoncalves We can chat about it if you want. The meeting is scheduled for an hour | 20:27 |
*** aojea_ has joined #openstack-lbaas | 20:27 | |
johnsom | nmagnezi Let me share a video demo I prepared for Vancouver but didn't get to present. | 20:27 |
nmagnezi | johnsom, please do :) | 20:27 |
cgoncalves | johnsom, I'd rather like having you reviewing https://review.openstack.org/#/c/568361/ xD | 20:27 |
johnsom | #link https://drive.google.com/open?id=1wx1kkLjUxwNAOpd9KeTGSAV-INZS58fD | 20:28 |
johnsom | That is a video I recorded of a failover flow (it was part of a dashboard demo) | 20:29 |
cgoncalves | johnsom, in a nutshell we think that showing amphora roles as MASTER or BACKUP confuses users. folks tend to think the MASTER one is the active, and the other the standby | 20:29 |
cgoncalves | and that on an amp failover, they would expect the BACKUP to become MASTER and the new spawned amp the BACKUP | 20:30 |
cgoncalves | cool, thanks for the video! | 20:30 |
johnsom | cgoncalves Yes, I understand. This is why we called it "role" and not "status" as it's really about configuration settings applied to the amphora | 20:30 |
johnsom | Luckily it's only an admin API that exposes that. | 20:31 |
nmagnezi | Today when I created an HA lb, without even doing anything I got it exactly the opposite from the listed roles | 20:31 |
nmagnezi | O_O | 20:31 |
johnsom | Yeah, and that is perfectly ok. | 20:32 |
johnsom | The amps are autonomous on their "active" status | 20:32 |
nmagnezi | By that logic I agree with you. It's just counterintuitive | 20:33 |
cgoncalves | why would admins care about configuration settings if they can't (in many cases) log-in to the amps? what is the use case for exposing the roles? | 20:33 |
nmagnezi | cgoncalves, for swapping amps (to update images) and I would even say to understand the impact of evacuating a specific compute node that has amps running on it, No? | 20:35 |
johnsom | None really. It was just an API that Adam wanted to be able to see the details of an amphora. Amphora are really supposed to be "hidden" things that are an implementation detail. I think that column just got swept up with the more interesting columns about the amp | 20:35 |
cgoncalves | nmagnezi, I don't follow. what you said sounds to me more of a reason for exposing the current status of the amps than their roles | 20:36 |
nmagnezi | cgoncalves, yup | 20:36 |
johnsom | No, the Role column has no operational value really. It is just there to track the priority value and preemption settings that get applied to each in the pair. | 20:36 |
nmagnezi | Sorry, you got it right | 20:37 |
cgoncalves | johnsom, ok. I don't see right now a use case where admins/operators would be interested in consuming that column. Adam may have and might be able to share | 20:38 |
cgoncalves | anyhow, I brought this up because I expect users to get confused about this | 20:39 |
johnsom | Hmm, looking in the code I'm not sure that even matters anymore.... We may have removed the differentiation between the settings on each (other than the priority which is tracked separate) | 20:39 |
johnsom | *If* we can find a reliable way to get the actual "active" status of an amp (long discussion with Nir about that yesterday), then we certainly can add a status column for it. | 20:40 |
johnsom | The challenge is getting an accurate status from keepalived. | 20:40 |
johnsom | This also brings us back around to Mr. Ohara | 20:41 |
cgoncalves | right. I read the discussion you had to amuller back in end of May here too | 20:41 |
cgoncalves | s/to/with/ | 20:42 |
*** kobis has quit IRC | 20:42 | |
johnsom | grin | 20:42 |
*** kobis has joined #openstack-lbaas | 20:42 | |
johnsom | Yeah, it does have a bit of usefulness. I also don't want to break the autonomy of the amps in this failover. They should be free to switch whenever they detect an issue, which may be faster than the heartbeat interval. | 20:44 |
johnsom | VRRP failover should be around a second or less depending on the configuration. Heartbeat is usually spaced higher than that. | 20:46 |
johnsom | So, please feel free to work on this. We can also add a column "active status" or something and just put "unkown" in it.... grin | 20:46 |
cgoncalves | right. I think, though, that keepalived has a notification subsystem. we could leverage that and callback octavia | 20:47 |
cgoncalves | lol | 20:47 |
nmagnezi | haha | 20:47 |
johnsom | Yeah, I couldn't get it to reliably give me the actual state. | 20:47 |
*** kobis has quit IRC | 20:47 | |
johnsom | I would skip some, or give bogus "Failed" while in the master role, etc. | 20:47 |
johnsom | Maybe it's been fixed and we can make it work. | 20:48 |
johnsom | The active IP thing might also solve this if we go clean that up. | 20:48 |
cgoncalves | interesting. maybe I can play a bit with that some day | 20:48 |
johnsom | Yeah, right now I don't have cycles to go play with it again. As long as it is *working* it's lower on the priority list. | 20:49 |
cgoncalves | knowing status of amps would improve maintenance ops greatly (e.g. failover first standby amp for image update than active amp) | 20:50 |
johnsom | Well, technically, not really. | 20:50 |
johnsom | Since if you happen to kill the master, it's going to failover inside the TCP timeout window, so it should be transparent other than a slight delay in that packet. | 20:51 |
johnsom | This is why it's a bit funny when the marketing folks ask how many milliseconds does it take for a HA failover. With TCP flows it's just a metric of jitter, not a window of downtime. | 20:53 |
cgoncalves | hmmm the first failover would fail to the standby amp, ok, then we'd need to failover once more to also rotate the now active amp | 20:53 |
johnsom | Correct, that is what the LB failover flow does | 20:54 |
johnsom | When you call the LB failover API | 20:54 |
cgoncalves | ok, you're right in saying that technically it's possible | 20:54 |
*** ThomasWhite has quit IRC | 20:55 | |
cgoncalves | I'd just like to avoid failing over active amps twice | 20:55 |
cgoncalves | low prio for now :) | 20:55 |
johnsom | I'm not following, how would you failover one of the amps twice? | 20:56 |
johnsom | It should be, amp A and amp B, each get one failover | 20:57 |
cgoncalves | right. I'm saying it would involve failing over twice insie the TCP timeout window as you mentioned before | 20:58 |
johnsom | Oh, that would be impressive if you could cycle your first amp inside one packet timeout | 20:58 |
cgoncalves | amp A (MASTER), amp B (BACKUP) running image X. failover amp A to image X+1. amp B (now ACTIVE) is still on image X. we'd need to fail it over to update it to image X+1 too | 20:59 |
nmagnezi | johnsom, cgoncalves, my connection went down few minutes ago, sorry. | 21:00 |
nmagnezi | johnsom, cgoncalves, good night/day folks! | 21:00 |
johnsom | Correct, but amp failover (not vrrp failover) of A takes 10+ seconds on a good day, so B would be VRRP master and handling traffic long before you are ready to do amp B. | 21:00 |
johnsom | Ah, yeah, out of time.... | 21:00 |
johnsom | Thanks folks! | 21:01 |
johnsom | #endmeeting | 21:01 |
*** openstack changes topic to "Discussion of OpenStack Load Balancing (Octavia) | https://etherpad.openstack.org/p/octavia-priority-reviews" | 21:01 | |
openstack | Meeting ended Wed Jul 4 21:01:06 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:01 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-07-04-20.00.html | 21:01 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-07-04-20.00.txt | 21:01 |
openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-07-04-20.00.log.html | 21:01 |
cgoncalves | good discussion. thanks for helping clarify, and for the time today on a holiday, Michael! | 21:01 |
johnsom | So in a full LB failover, two packets would see a slightly higher latency, or increased jitter. | 21:02 |
johnsom | Sure, let's keep talking about this so we are all on the same page. | 21:02 |
cgoncalves | ack :) | 21:03 |
johnsom | Also, there is a demo in this Tokyo summit presentation: https://youtu.be/8n7FGhtOiXk | 21:03 |
johnsom | Ah, here to be exact: https://youtu.be/8n7FGhtOiXk?t=23m40s | 21:03 |
cgoncalves | nice! | 21:04 |
*** ktibi_ has quit IRC | 21:57 | |
*** threestrands has joined #openstack-lbaas | 22:05 | |
*** threestrands has quit IRC | 22:05 | |
*** threestrands has joined #openstack-lbaas | 22:05 | |
*** threestrands has quit IRC | 22:06 | |
*** rcernin has joined #openstack-lbaas | 22:27 | |
*** aojea_ has quit IRC | 22:29 | |
*** kobis has joined #openstack-lbaas | 23:10 | |
*** kobis has quit IRC | 23:15 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!