Wednesday, 2020-07-01

johnsomaannuusshhkkaa I have not, sorry, lost track of that one. Will look at it tomorrow00:03
openstackgerritYang JianFeng proposed openstack/octavia-lib master: Define the protocols supported by listener and pool respectively
*** yamamoto has joined #openstack-lbaas00:46
*** yamamoto has quit IRC00:49
*** yamamoto has joined #openstack-lbaas00:58
*** also_stingrayza has joined #openstack-lbaas02:03
*** stingrayza has quit IRC02:07
*** ramishra has quit IRC02:30
*** ramishra has joined #openstack-lbaas02:31
*** wuchunyang has joined #openstack-lbaas02:53
*** wuchunyang has quit IRC02:58
aannuusshhkkaajohnsom, no worries! Thank you.. :)03:15
*** armax has quit IRC03:19
*** psachin has joined #openstack-lbaas03:33
*** wuchunyang has joined #openstack-lbaas04:37
*** gcheresh has joined #openstack-lbaas04:46
*** mugsie has quit IRC04:53
*** wuchunyang has quit IRC04:55
*** wuchunyang has joined #openstack-lbaas04:56
*** gcheresh has quit IRC04:56
*** wuchunyang has quit IRC04:57
*** mugsie has joined #openstack-lbaas04:57
*** strigazi has quit IRC05:04
*** gcheresh has joined #openstack-lbaas05:05
*** strigazi has joined #openstack-lbaas05:06
*** gcheresh has quit IRC05:12
*** gcheresh_ has joined #openstack-lbaas05:12
*** vishalmanchanda has joined #openstack-lbaas05:23
*** wuchunyang has joined #openstack-lbaas05:28
*** wuchunyang has quit IRC05:35
*** gcheresh_ has quit IRC05:44
*** strigazi has quit IRC05:46
*** gcheresh_ has joined #openstack-lbaas05:50
*** ccamposr__ has joined #openstack-lbaas06:14
*** ccamposr has quit IRC06:17
*** njohnston has quit IRC06:18
*** ccamposr has joined #openstack-lbaas06:31
*** michchap has joined #openstack-lbaas06:32
*** ccamposr__ has quit IRC06:34
*** also_stingrayza is now known as stingrayza06:49
*** luksky has joined #openstack-lbaas07:02
*** rcernin has quit IRC07:02
*** rcernin has joined #openstack-lbaas07:04
*** maciejjozefczyk has joined #openstack-lbaas07:15
*** rcernin has quit IRC07:30
openstackgerritAnn Taraday proposed openstack/octavia master: [Amphorav2] Healthmonitor operation minor fixes
*** rcernin has joined #openstack-lbaas07:50
*** born2bake has joined #openstack-lbaas07:57
*** rcernin has quit IRC08:06
*** ramishra has quit IRC08:09
*** sapd1 has joined #openstack-lbaas08:18
*** ataraday_ has quit IRC09:15
*** yamamoto has quit IRC09:37
*** yamamoto has joined #openstack-lbaas09:55
*** tkajinam has quit IRC09:59
*** yamamoto has quit IRC10:06
*** yamamoto has joined #openstack-lbaas10:07
*** gcheresh_ has quit IRC10:10
*** gcheresh_ has joined #openstack-lbaas10:34
*** ramishra has joined #openstack-lbaas10:45
lxkongjohnsom, rm_work: When the amphora status is set to ERROR (e.g. because of failed communication), how the ERROR status will be restored back to ALLOCATED?10:48
lxkongrm_work: yeah, that's what i thought.  Why octavia didn't reset amphora status when updating health status?10:49
lxkongrm_work: sometimes because of the a temporary network issue, amphora status becomes ERROR, but after several minutes, the networking is back to normal, shouldn't octavia automatically reset the status to normal, given it is stilll receiving data from amphora?10:51
rm_workwell, maybe? but we don't record exactly why it went to error10:53
rm_workit could be in ERROR because of bad certificates, or failed service, or not heartbeating10:53
rm_workso if heartbeats reset it, i guess that'd handle most of that, but not sure it'd strictly cover like ... our ability to reach out (cert / network)10:53
rm_worklike UDP packets might not be blocked, but TCP into 9443 is for the agent HTTPS server? or the certs on that are bad?10:54
rm_workso we would have to also do a test connection to that10:54
rm_workit's possible you could do some code to handle that... maybe housekeeping could periodically check connection to ERROR amps, and if they both recently received a health packet AND an info-get works to the agent API, maybe we could mark them up again?10:55
rm_workwould have to think about what else could be the reason for ERROR10:55
lxkonghmm, make sense.10:56
lxkongso maybe failover is the solution for now, although sometimes the amphorae are still functioning10:59
*** njohnston has joined #openstack-lbaas11:01
rm_workyeah, but it's safest to always just failover11:03
lxkongrm_work: another issue we have met is, the lb operating status is ONLINE, but the amphorae are actually disappeared11:06
lxkongso the operating status is only updated when there is data received by health manager, right?11:06
lxkongi am not asking why the amphorae are missing, just want to know in this case, ONLINE is expected?11:07
*** kevinz has quit IRC11:11
rm_workyeah, only updated in that case, yes11:11
rm_workif UDP packets NEVER happen (like, ACLs blocking them forever) for example, it will always be ONLINE11:11
lxkongrm_work: hmm, ok, sounds weird but yeah, that's the mechanism.11:12
rm_workthere is probably some fun additional stuff we can do with like, housekeeping or something11:13
rm_workbut that's all extra11:13
lxkongright, thanks for the answers11:14
openstackgerritCarlos Goncalves proposed openstack/octavia stable/stein: Remove scenario bionic job from check
openstackgerritGregory Thiemonge proposed openstack/octavia-tempest-plugin master: WIP SCTP traffic scenario tests
*** sapd1 has quit IRC12:05
*** sapd1 has joined #openstack-lbaas12:05
openstackgerritGregory Thiemonge proposed openstack/octavia-lib master: Add SCTP protocol and health-monitor constants
*** irclogbot_0 has quit IRC12:14
*** irclogbot_1 has joined #openstack-lbaas12:17
*** trident has quit IRC12:46
openstackgerritGregory Thiemonge proposed openstack/octavia master: WIP Add SCTP support in API and Amphora
*** trident has joined #openstack-lbaas12:49
openstackgerritGregory Thiemonge proposed openstack/octavia master: WIP Add SCTP support in API and Amphora
*** psachin has quit IRC13:31
*** TrevorV has joined #openstack-lbaas13:31
*** yamamoto has quit IRC13:50
*** yamamoto has joined #openstack-lbaas14:11
*** yamamoto has quit IRC14:11
*** yamamoto has joined #openstack-lbaas14:12
*** yamamoto has quit IRC14:16
*** gcheresh_ has quit IRC14:28
*** gcheresh_ has joined #openstack-lbaas14:39
*** armax has joined #openstack-lbaas14:47
*** gcheresh_ has quit IRC15:33
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Update IPv6 job for mirrors and log offloading
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Update IPv6 job for mirrors and log offloading
cgoncalveshave we considered either renaming the amphorav2 provider to amphora or alias amphora->amphorav2 once we switch the default to amphorav2?15:56
*** gcheresh_ has joined #openstack-lbaas15:58
*** ataraday_ has joined #openstack-lbaas15:58
*** shtepanie has joined #openstack-lbaas15:59
johnsomI think it is a logical choice to make that change at some point, but given the extra infrastructure I'm not sure aliasing amphorav2 to amphora is a good idea.16:00
johnsom#startmeeting Octavia16:00
openstackMeeting started Wed Jul  1 16:00:14 2020 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: Octavia)"16:00
openstackThe meeting name has been set to 'octavia'16:00
johnsomHi everyone16:00
johnsom#topic Announcements16:00
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"16:00
johnsomI don't really have any announcements this week.16:01
johnsomWe finally got a stable/train release out the door. I think it had been nine months since the last release.16:01
* johnsom shames himself16:01
johnsomAny other announcements this week?16:01
johnsom#topic Brief progress reports / bugs needing review16:02
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"16:02
ataraday_I create patch with experimental job with amphorav2 and find out that several things is/got broken.16:03
johnsomAside from reviews, rebases, and the occasional small bug fix, I have been focusing on failover for amphorav2. It's a bit slow going, but making progress.16:04
ataraday_there is also issue with barbican tls, still looking into it..16:04
johnsomI think after we have that landed there are going to be some patches to simplify and clean up stuff. I'm trying to not go crazy doing that now as I don't want another monster patch and want to move faster on this patch.16:04
johnsomNice, thank you.16:05
ataraday_johnsom, Thanks for proposing failover for amphorav2!16:05
johnsomI'm also looking into why the IPv6 job is timing out. sigh16:05
johnsomataraday_ Still a lot to be done, but work in progress16:05
*** armax has quit IRC16:06
cgoncalvesI extended the amphora flavor capabilities to add amp_image_tag. this is useful for multi-architecture clouds and testing amphora images in staging environments, for example. as part of that work I also removed some deprecated options and create an image driver interface (noop and glance drivers)16:06
johnsomYeah, nice! I think I have reviewed about half of that now16:07
*** gcheresh_ has quit IRC16:07
rm_workI'm revisiting the failover threshold thingy16:07
johnsomNice, also helpful16:07
cgoncalvesI successfully deployed via devstack Octavia in an arm64/aarch64 system, although the amphora agent is not coming up in Zuul CI. this is a side project, thus low priority for me16:07
rm_workisn't TrevorV working on that stuff? aarch6416:08
johnsomTrevor is working on power16:08
rm_workahh he's on ppc, ok16:08
johnsomThere was a mailing list post about the ppc work and Octavia I mentioned last week. I think I was the only one to reply16:09
cgoncalvesOpenDev has aarch64 nodepool nodes, thanks to Linaro!16:09
rm_workwhat's a "mailing list"16:09
rm_workI forgot what email was after Google killed Inbox16:09
rm_workRIP Inbox16:09
johnsomYou sign up for coupons with one16:09
rm_workRIP email16:09
cgoncalvesIT'S A TRAP!16:09
rm_workooo nice, aarch64 testing resources is good :) do we also have ppc?16:10
cgoncalvesI found a clever way to run our CI jobs in nest-virt enabled nodes, cutting job time from close to 2 hours down to as low as 38 minutes16:10
johnsomI don't think so, not in zuul at least. Red Hat has some ppc stuffs16:10
rm_workyeah I just +2'd that, seems workable16:11
cgoncalvesyeah, we have also ppc systems internally but, as you said, TrevorV has been working on that16:11
*** armax has joined #openstack-lbaas16:11
johnsomYeah, I don't have cycles to put into that at the moment16:12
* rm_work is just enjoying causing TrevorV's IRC client to possibly ping16:12
TrevorVWoah woah woah!  I haven't touched arm16:12
rm_workhaha there we go16:12
TrevorVWhat'd I miss now?16:12
rm_workyes, johnsom pointed out it was ppc :D16:12
johnsomArm either, though I have run our code on a raspberry pi 4 with very good results.16:12
rm_workI just remembered you were on some alternate arch16:12
cgoncalvesTrevorV, we were saying you've been working on ppc, not arm16:12
rm_workok so moving on16:13
johnsom#topic Open Discussion16:14
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)"16:14
johnsomSomeone seems anxious....16:14
johnsomAny other topics this week?16:14
cgoncalvesI asked just before the meeting started a question about the amphorav2. would now be a good time to discuss it?16:15
cgoncalvesok, I'll paste the question again:16:16
cgoncalveshave we considered either renaming the amphorav2 provider to amphora or alias amphora->amphorav2 once we switch the default to amphorav2?16:16
johnsomI think it is a logical choice to make that change at some point, but given the extra infrastructure I'm not sure aliasing amphorav2 to amphora is a good idea.16:16
* johnsom pastes his answer again16:16
cgoncalvesok, so you're not for aliasing. are you then for renaming or?16:16
*** etp has quit IRC16:16
johnsomThat said, I might look at if we can have the v2 path jobboard/extra requirements optional. It seems like it should be do-able16:17
johnsomInterested in what people think....16:18
rm_workYeah I had some concerns here16:18
rm_workIf we deprecate/remove the amphora (v1) driver, we are going to be explicitly choosing to make our default deployment more complex than previously (introducing a second required service)16:18
rm_workif we DON'T, we will forever have two code-paths, and that sucks, so I don't think it's really an option T_T16:19
*** etp has joined #openstack-lbaas16:19
johnsomYeah, we have to deprecate the v1 path. It's just not workable long term IMO16:19
rm_workSO going from that: if we deprecate the old version, and force people over to the new version, given the new complexity/requirements, they MUST explicitly switch over for it to work16:19
rm_workso for people who do upgrades without reading release-notes, if they upgrade from say X->Y release and v1 becomes v2, it's just going to explode but not "cleanly"/"clearly"16:20
rm_workrather than "the provider does not exist" it'll be some error nestled down inside the worker where it tries and fails to connect to unconfigured redis16:21
johnsomWe can put some tooling in to warn people or make it obvious early. I think Ann already has updated the upgrade check tool.16:22
* johnsom notes, upgrade check tool nobody runs....16:22
cgoncalvesataraday_ has a pre-upgrade check for the amphorav2 provider that may be handy16:22
johnsomWe can set it up to check on startup and fail to start if it's not present as well.16:23
rm_workfail to start if a flavor is using a provider that doesn't exist?16:23
johnsomOr the default is v2, yeah, basically.  It's ugly, but possible16:24
*** etp has quit IRC16:24
rm_workanyway, yeah, if we rename/alias automatically then it really hides stuff from the operator that I don't think we should be hiding16:25
johnsomSo I think the original question was about the name. I assume for upgrade reasons. Is there a need to rename it from amphorav2?16:26
cgoncalvesamphorav2 should be able manage amphorav1-created resources, correct? when we remove the amphorav1 code, we could either do a db migration to change the provider driver of existing LBs to amphorav2 or rename amphorav2 to amphora (with the bonus that we don't potentially break things for the user as the provider name would not change)16:26
rm_worki mean, it does look kinda weird16:26
rm_workI guess so, with the caveat that we prevent the service from starting if everything for amphorav2 isn't configured properly?16:27
rm_workwhich kinda handles that in a more up-front way16:28
cgoncalvesmy question comes from a deployment side as I started work to support the amphorav2 in tripleo16:28
rm_workyeah ok i'm coming around, maybe we do alias it, and deal with my concerns via the service startup checking its config is valid16:28
rm_worksame as "can i connect to SQL" and "can I connect to RMQ", add "can I connect to Redis/Zookeeper"16:29
johnsomI think we should also look at making the "jobboard" part of the v2 driver optional.16:29
rm_workhmm that is the other posibility16:29
rm_workI actually would prefer that but I didn't know if THAT was feasible, as it's pretty baked in16:29
johnsomWe should be able to run the new flows just like we have, without the need for redis, and have a bit-flip for jobboard16:29
rm_workyeah ok I think that is my #1 preferred option -- and then yes, alias amphora to amphorav216:30
johnsomReally it's about how we launch the flows.16:30
rm_workand keep the default to False for "use_jobboard"16:30
ataraday_without jobboard we won't be able to resume jobs16:31
ataraday_so why we will may need that?16:31
johnsomRight, that would be the trade off of that setting16:31
rm_workso Octavia is still possible to run without Redis16:31
ataraday_in this case we may leave amphora16:31
rm_workand using no additional upgrade requirements16:31
openstackgerritPierre Riteau proposed openstack/octavia master: Add debootstrap installation instructions for CentOS
rm_workbasically that allows for what I wanted as far as "keeping v1 and v2 around" except we don't ACTUALLY have to keep v1 around, and consolidate code paths16:32
rm_workbecause the ONLY advantage of v1 was not requiring Redis16:32
johnsomYeah, I really don't want to keep the v1 code around. That is asking for mistakes to be made and doubles work effort (I'm feeling the pain now, lol)16:34
rm_worki absolutely do not want to keep it around, for the record16:35
cgoncalves+1. amphorav2++16:35
rm_workI just hated the idea of having no way to run without jobboard (if you want a simpler install, with the possibility of stuff stuck in PENDING)16:35
johnsomSo, maybe in parallel someone can look at making that config setting? Or I could look at it after failover is done.16:36
johnsomI think it's just making a method that runs the flows like the v1 driver does or like the v2 driver does, depending on the config setting.16:37
cgoncalvesI have little to none (more like none TBH, lol) understanding on the amphorav2/jobboard but I could maybe take a look16:38
ataraday_this may make code really twisted16:38
johnsomcgoncalves Ok cool. I can give you a few pointers to what I'm thinking.16:38
* cgoncalves l16:38
*** ccamposr__ has joined #openstack-lbaas16:39
rm_workyeah, my concern (and why I didn't ask for this originally) was that it might not even be possible or would make things incredibly more complex within v216:39
johnsomataraday_ Yeah, I may be overlooking something, but I think we should give it a shot.16:39
aannuusshhkkaawe needed feedback on metric selection for the amphoras.. can we take that up next?16:40
rm_workok, so decision was: yes to alias, and try to make v2 have a "jobboardless" option?16:40
cgoncalvesif feasible, I'd advocate for use_jobboard=true as default. devstack can set redis up and is our recommendation for production environments, right?16:40
johnsomOr was it "alias if we can make the jobboard part optional"?16:40
rm_workhmm maybe that16:40
rm_workyes, let's plan to take that topic up next aannuusshhkkaa!16:41
johnsomYeah, we should push for it as the default16:41
rm_workI am unsure I agree16:41
*** ccamposr has quit IRC16:41
rm_workbut I guess it is as simple as "oh, my service won't start due to an error that says I don't have redis configured and might need to turn off use_jobboard" and then they do that16:42
johnsomI think it is a question of timing.16:42
cgoncalvesrm_work, before this conversation, amphorav2 was already set to become the default in Victoria or later release so either way Redis would be required16:42
rm_workyeah which I never liked16:43
johnsomWe need to make a call by the end of ms2 because we need to send an e-mail out about the need for Redis to the deployment tools have time to add it.16:43
cgoncalvesyou get the bonus now that there may be a chance jobboard/redis not to be mandatory :)16:43
rm_worklets do some research on this and see if it's even possible to make it optional?16:43
rm_workthen revisit before ms216:44
johnsomOk, yeah, I agree16:44
*** etp has joined #openstack-lbaas16:44
johnsomMS2 is coming up fast though16:44
johnsomWeek of July 27th16:44
rm_workcan we move on to metrics then?16:44
cgoncalvesmetrics, that's why you were anxious earlier :D16:45
johnsomI think so. What is up with metrics? I know there is a patch that needs some reviews16:45
aannuusshhkkaahere is the list of metrics we are thinking of implementing:16:45
aannuusshhkkaaMust Haves:16:45
aannuusshhkkaaCPU Usage (Current %)16:45
aannuusshhkkaaLoad Averages16:45
aannuusshhkkaaRAM Usage (some combo of: total / free / available / cached / etc)16:45
aannuusshhkkaaNice to Haves:16:45
aannuusshhkkaaDisk usage (used/free? or used%?)16:45
aannuusshhkkaaRandom extra HAProxy fields (taking suggestions)16:45
aannuusshhkkaaare we good on the ones we have selected? are we missing something? have we included something that isn’t plausible?16:45
rm_workyes, we have one patch up that changes the interfaces around slightly16:45
rm_workack, in the future you should paste multi-line stuff into something like
johnsomDo we need load averages? Personally I would like to keep the data minimal, so just %'s16:46
rm_workI feel like it's generally more useful than "point in time" CPU usage16:47
johnsomYeah, you can get booted off the server to too much multi-line pastes.16:47
aannuusshhkkaarm_work gotcha16:47
aannuusshhkkaajohnsom, haha okay! thanks for the correction..16:48
johnsomOk, if you have a use for it.16:48
rm_workWell, it's super easy for a single point in time CPU % to be totally off16:48
johnsomaannuusshhkkaa The server can consider you a spam bot basically.16:48
aannuusshhkkaayeap that makes sense.. will keep that in mind..16:49
johnsomYeah, but we will get samples every 10 seconds or so.16:49
rm_workwhereas load averages are very nice locally generated averages that we can keep collecting at a much slower interval and still have them be useful16:49
*** ataraday_ has quit IRC16:49
rm_workyeah if we were collecting every second, doing our own averages might make more sense, but...16:50
johnsomYeah, maybe. You would have to then get the number of cores to calculate a percent16:50
rm_workhmm yes that is true16:51
rm_workpossibly do THAT locally? and return load average %s16:51
rm_workrather than have to ship that info up and calculate later16:51
johnsomThat could work.16:52
rm_workanyway, we will look into options for that -- any comments about the others? RAM numbers that are actually useful?16:52
rm_workLinux "free memory" is basically a useless metric16:52
rm_workbut I don't know exactly which combination of RAM metrics is *actually* most useful16:52
johnsomYeah, really I'm looking for % of available memory16:53
johnsomcache and free, not so useful to me16:53
aannuusshhkkaaokay.. what about disk usage? used %s?16:55
rm_workI would assume used% is better possibly? though I also wonder if without context that could be not so useful if it says 50% and then you wonder "at what rate will that fill"16:56
johnsomRate is why you have time series16:56
johnsomA simple scaling driver could have just thresholds and ignore rate. A fancy driver could build a rate and make decisions.16:58
johnsomThen at some point someone can add AI and ML, then build a model of what works and doesn't. Then we retire16:58
rm_workso that means... percentage? or used/total? lol16:59
johnsomOh, just about out of time for the meeting. We can continue after if you still have questions.16:59
johnsomOr defer to next week.16:59
aannuusshhkkaayes we do..16:59
aannuusshhkkaanext week would probably be a little too late..17:00
*** openstack changes topic to "Discussions for OpenStack Octavia | Priority bug review list:"17:00
openstackMeeting ended Wed Jul  1 17:00:10 2020 UTC.  Information about MeetBot at . (v 0.1.4)17:00
openstackMinutes (text):
johnsomOk, I can hang around a bit17:00
aannuusshhkkaaso for load averages - % or used/total?17:01
rm_workoh, the reason we were bringing it up during the meeting and not just whenever, was we wanted the largest possible audience for input on anything we missed17:02
johnsomI would lean towards % for each over used/total, but what do you think rm_work?17:02
rm_workdid anyone have any comments before they run off about things they'd want to see but we didn't list?17:02
rm_workyeah I think generally standardizing on percentage makes sense17:02
johnsomI don't have any other metrics I need from harpoxy right now.17:03
johnsomI think ram, cpu, disk are the high priority items for me.17:03
johnsomLooking at:
rm_workyeah we talked about some specific haproxy metrics last week but i don't think we decided on any that were REALLY that important17:05
rm_workthere's a bunch that are very specific to HTTP or whatever17:05
rm_workor things that just... don't really matter17:05
johnsomYeah, or could be collected via the log offloading17:06
aannuusshhkkaamy list of metrics was much longer, but rm_work seemed to think the same thing..17:07
aannuusshhkkaaso in a nutshell, johnsom, % of used and total cpu/ram/disk is what's most important for you right?17:09
johnsomI lean towards keeping these metrics "operational" in that things we need to operate the service effectively. For "analysis" type metrics I would much rather analyze the log files. Partly because I know we need to keep the message reasonably small so that the heartbeat packet can handle a lot of listeners.17:09
aannuusshhkkaaokay understood.17:10
johnsomAny other metrics topics you need to discuss before next week?17:12
aannuusshhkkaajohnsom, no.. i think we have everything we need to get started17:13
johnsom+1 great!17:14
aannuusshhkkaathank you so much for sticking around!17:14
*** jamespage has quit IRC17:15
*** jmccrory has quit IRC17:15
*** jamespage has joined #openstack-lbaas17:18
*** jmccrory has joined #openstack-lbaas17:18
*** ccamposr__ has quit IRC17:26
*** born2bake has quit IRC17:26
*** michchap has quit IRC17:26
*** TMM has quit IRC17:26
*** zzzeek has quit IRC17:26
*** devfaz has quit IRC17:26
*** numans has quit IRC17:26
*** hongbin has joined #openstack-lbaas17:28
*** irclogbot_1 has quit IRC17:28
*** ccamposr__ has joined #openstack-lbaas17:29
*** born2bake has joined #openstack-lbaas17:29
*** michchap has joined #openstack-lbaas17:29
*** TMM has joined #openstack-lbaas17:29
*** zzzeek has joined #openstack-lbaas17:29
*** devfaz has joined #openstack-lbaas17:29
*** numans has joined #openstack-lbaas17:29
*** irclogbot_3 has joined #openstack-lbaas17:30
*** njohnston_ has joined #openstack-lbaas17:43
*** njohnston has quit IRC17:43
*** yamamoto has joined #openstack-lbaas17:44
*** njohnston_ is now known as njohnston17:45
*** yamamoto has quit IRC17:53
*** ramishra has quit IRC18:01
*** dasp_ has quit IRC18:39
*** dasp has joined #openstack-lbaas18:41
*** hongbin has quit IRC18:44
*** hongbin has joined #openstack-lbaas19:18
*** vishalmanchanda has quit IRC19:47
*** spatel has joined #openstack-lbaas19:55
*** hongbin has quit IRC20:06
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Update IPv6 job for mirrors and log offloading
*** spatel has quit IRC20:29
*** spatel has joined #openstack-lbaas20:30
*** spatel has quit IRC20:30
*** also_stingrayza has joined #openstack-lbaas20:33
*** maciejjozefczyk has quit IRC20:36
*** stingrayza has quit IRC20:37
*** gcheresh_ has joined #openstack-lbaas20:42
*** hongbin has joined #openstack-lbaas20:54
*** gcheresh_ has quit IRC21:06
*** haleyb has quit IRC21:40
*** haleyb has joined #openstack-lbaas21:52
*** born2bake has quit IRC22:08
*** gregwork has joined #openstack-lbaas22:09
*** luksky has quit IRC22:29
openstackgerritMerged openstack/octavia-tempest-plugin master: Apply Octavia hacking checks to the tempest plugin
*** rcernin has joined #openstack-lbaas22:36
*** tkajinam has joined #openstack-lbaas22:46
*** rcernin has quit IRC22:47
*** rcernin has joined #openstack-lbaas22:47
*** TrevorV has quit IRC22:54
*** spatel has joined #openstack-lbaas22:58
*** spatel has quit IRC23:07
*** hongbin has quit IRC23:11
*** hongbin has joined #openstack-lbaas23:16
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Update IPv6 job for mirrors and log offloading
*** yamamoto has joined #openstack-lbaas23:52
*** yamamoto has quit IRC23:57

Generated by 2.17.2 by Marius Gedminas - find it at!