| johnsom | We might want to make that stevedore a "pass the data to multiple drivers" model as opposed to a single driver. | 00:04 |
|---|---|---|
| rm_work | yep | 00:06 |
| rm_work | yepyep | 00:06 |
| rm_work | that helps clarify things a bit | 00:12 |
| rm_work | we can discuss the specific metrics we want to add another time, soon? | 00:13 |
| rm_work | but we can start with the assumption that it'll be at LEAST cpu and ram | 00:13 |
| johnsom | Sure. The only two I know of are CPU and RAM. We don't even need to necessarily store them or figure out what to do with them now, just that we start collecting them. | 00:14 |
| johnsom | In Shanghai there was some discussion of pool level and member level stats like we have for load balancers and listeners, but I'm not sure I get the concept of those, plus I think it may be hard if not impossible to collect. Also UDP may not be able to provide them. | 00:16 |
| rm_work | yeah | 00:17 |
| rm_work | we're going to have to introduce "system" level stats | 00:17 |
| johnsom | I'm not sure if that was a "wouldn't it be neat" or "I have a use case for this" type of thing | 00:17 |
| rm_work | outside of listeners/pools | 00:17 |
| rm_work | also, system level stats will NOT be deltas | 00:17 |
| rm_work | at least, most of them won't | 00:18 |
| johnsom | Yeah. Correct | 00:18 |
| rm_work | which means we may also have to provide a setting per stat in the structure to say whether it's actually a delta or not | 00:18 |
| rm_work | for everything | 00:18 |
| johnsom | Umm, I don't want to fatten the heartbeat message too much. Really the version should determine how the message is parsed. | 00:19 |
| rm_work | right but.... | 00:19 |
| rm_work | well ok | 00:19 |
| rm_work | i guess we can just "know" on the driver side on the control-plane | 00:19 |
| rm_work | that's probably fine | 00:19 |
| johnsom | Yeah, heartbeat side is a bit tightly coupled and space constrained | 00:20 |
| johnsom | Which is another argument for deltas | 00:20 |
| rm_work | adding metrics to the agenda for tomorrow | 00:25 |
| johnsom | Ok | 00:25 |
| *** armax has quit IRC | 00:33 | |
| *** yamamoto has quit IRC | 00:35 | |
| *** yamamoto has joined #openstack-lbaas | 00:35 | |
| *** wuchunyang has quit IRC | 00:38 | |
| *** wuchunyang has joined #openstack-lbaas | 00:39 | |
| *** wuchunyang has quit IRC | 00:51 | |
| *** wuchunyang has joined #openstack-lbaas | 01:20 | |
| *** spatel has joined #openstack-lbaas | 01:21 | |
| *** wuchunyang has quit IRC | 01:31 | |
| *** wuchunyang has joined #openstack-lbaas | 01:48 | |
| *** armax has joined #openstack-lbaas | 01:52 | |
| *** wuchunyang has quit IRC | 02:21 | |
| *** wuchunyang has joined #openstack-lbaas | 02:35 | |
| *** wuchunyang has quit IRC | 02:41 | |
| *** wuchunyang has joined #openstack-lbaas | 02:41 | |
| *** psachin has joined #openstack-lbaas | 02:48 | |
| *** rcernin has quit IRC | 02:49 | |
| *** rcernin has joined #openstack-lbaas | 02:54 | |
| *** wuchunyang has quit IRC | 03:00 | |
| *** rcernin has quit IRC | 03:08 | |
| *** wuchunyang has joined #openstack-lbaas | 03:16 | |
| *** wuchunyang has quit IRC | 03:19 | |
| *** psachin has quit IRC | 03:31 | |
| *** psachin has joined #openstack-lbaas | 03:33 | |
| *** armax has quit IRC | 03:40 | |
| *** rcernin has joined #openstack-lbaas | 03:45 | |
| *** rcernin has quit IRC | 03:45 | |
| *** rcernin has joined #openstack-lbaas | 03:50 | |
| *** yamamoto has quit IRC | 04:19 | |
| *** gcheresh has joined #openstack-lbaas | 04:20 | |
| *** yamamoto has joined #openstack-lbaas | 04:35 | |
| *** wuchunyang has joined #openstack-lbaas | 04:38 | |
| *** vishalmanchanda has joined #openstack-lbaas | 04:42 | |
| *** wuchunyang has quit IRC | 04:52 | |
| *** threestrands has joined #openstack-lbaas | 05:27 | |
| *** spatel has quit IRC | 05:29 | |
| *** wuchunyang has joined #openstack-lbaas | 05:31 | |
| *** threestrands has quit IRC | 05:33 | |
| *** wuchunyang has quit IRC | 05:35 | |
| *** wuchunyang has joined #openstack-lbaas | 06:12 | |
| *** rpittau|afk is now known as rpittau | 06:56 | |
| *** JayLiu has joined #openstack-lbaas | 07:07 | |
| *** psachin has quit IRC | 07:15 | |
| *** psachin has joined #openstack-lbaas | 07:17 | |
| *** wuchunyang has quit IRC | 07:33 | |
| *** rcernin has quit IRC | 07:47 | |
| *** ataraday_ has joined #openstack-lbaas | 07:53 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 08:02 | |
| *** maciejjozefczyk has quit IRC | 08:03 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 08:03 | |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia master: add the verify for the session https://review.opendev.org/726567 | 08:07 |
| *** ramishra has quit IRC | 08:17 | |
| *** JayLiu has quit IRC | 08:33 | |
| *** also_stingrayza is now known as stingrayza | 08:34 | |
| *** salmankhan has joined #openstack-lbaas | 08:52 | |
| *** salmankhan1 has joined #openstack-lbaas | 08:55 | |
| *** tkajinam has quit IRC | 08:57 | |
| *** salmankhan has quit IRC | 08:57 | |
| *** salmankhan1 is now known as salmankhan | 08:57 | |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia master: Use uwsgi binary from path https://review.opendev.org/736137 | 09:04 |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia master: add the verify for the session https://review.opendev.org/726567 | 09:05 |
| *** aannuusshhkkaa has quit IRC | 09:20 | |
| *** born2bake has joined #openstack-lbaas | 09:31 | |
| *** ramishra has joined #openstack-lbaas | 09:37 | |
| *** yamamoto has quit IRC | 10:01 | |
| *** yamamoto has joined #openstack-lbaas | 10:02 | |
| *** yamamoto has quit IRC | 10:02 | |
| openstackgerrit | Ann Taraday proposed openstack/octavia master: Preupgrade check for amphorav2 provider https://review.opendev.org/735556 | 10:06 |
| cgoncalves | ataraday_, hi! FYI, you may want to rebase ^ on top of https://review.opendev.org/#/c/736137/ (gate fix) | 10:08 |
| *** rpittau is now known as rpittau|bbl | 10:18 | |
| *** psachin has quit IRC | 10:31 | |
| *** yamamoto has joined #openstack-lbaas | 10:38 | |
| *** yamamoto has quit IRC | 10:39 | |
| *** yamamoto has joined #openstack-lbaas | 10:40 | |
| *** TMM has quit IRC | 10:40 | |
| *** TMM has joined #openstack-lbaas | 10:40 | |
| ataraday_ | cgoncalves, Oh, thanks! I though fixes in devstack repo is enough :) | 10:43 |
| openstackgerrit | Ann Taraday proposed openstack/octavia master: Preupgrade check for amphorav2 provider https://review.opendev.org/735556 | 10:44 |
| *** yamamoto has quit IRC | 10:50 | |
| *** yamamoto has joined #openstack-lbaas | 11:00 | |
| *** psachin has joined #openstack-lbaas | 11:03 | |
| *** also_stingrayza has joined #openstack-lbaas | 11:34 | |
| *** stingrayza has quit IRC | 11:36 | |
| *** psachin has quit IRC | 11:58 | |
| *** psachin has joined #openstack-lbaas | 12:00 | |
| *** rpittau|bbl is now known as rpittau | 12:06 | |
| *** numans has quit IRC | 12:14 | |
| *** spatel has joined #openstack-lbaas | 12:31 | |
| *** spatel has quit IRC | 12:36 | |
| *** TrevorV has joined #openstack-lbaas | 13:37 | |
| *** rpittau is now known as rpittau|brb | 13:39 | |
| *** kberger_ has joined #openstack-lbaas | 13:45 | |
| *** kberger_ has quit IRC | 13:46 | |
| *** kberger_ has joined #openstack-lbaas | 13:46 | |
| *** KeithMnemonic has quit IRC | 13:49 | |
| *** rpittau|brb is now known as rpittau | 13:53 | |
| *** yamamoto has quit IRC | 14:06 | |
| *** TMM has quit IRC | 14:22 | |
| *** TMM has joined #openstack-lbaas | 14:23 | |
| *** yamamoto has joined #openstack-lbaas | 14:34 | |
| *** yamamoto has quit IRC | 14:34 | |
| *** yamamoto has joined #openstack-lbaas | 14:34 | |
| *** psachin has quit IRC | 14:34 | |
| *** yamamoto has quit IRC | 14:41 | |
| johnsom | cgoncalves Thanks for catching that we were specifying a path for uwsgi. I have rage-merged it to unblock the gates | 14:50 |
| cgoncalves | thanks! | 14:52 |
| cgoncalves | it was copy-pasta from devstack and confirmed by another designate patch | 14:52 |
| johnsom | Yeah, I think some of that was template stuff from the community goal, so not surprised to see it in a few repos. | 14:55 |
| *** gcheresh has quit IRC | 15:29 | |
| *** aannuusshhkkaa has joined #openstack-lbaas | 15:57 | |
| johnsom | #startmeeting Octavia | 16:00 |
| openstack | Meeting started Wed Jun 17 16:00:33 2020 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: Octavia)" | 16:00 | |
| openstack | The meeting name has been set to 'octavia' | 16:00 |
| johnsom | Hello everyone | 16:00 |
| gthiemonge | Hi | 16:01 |
| ataraday_ | hi | 16:01 |
| aannuusshhkkaa | Hello! | 16:01 |
| rm_work | o/ | 16:01 |
| shtepanie | Hi! | 16:01 |
| cgoncalves | hi | 16:02 |
| openstackgerrit | Merged openstack/octavia master: Use uwsgi binary from path https://review.opendev.org/736137 | 16:02 |
| johnsom | #topic Announcements | 16:02 |
| *** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 16:02 | |
| johnsom | Well, that was one announcement ^^^^ | 16:02 |
| johnsom | uwsgi was broken for devstack recently. That patch should resolve the master branch. | 16:03 |
| johnsom | Does anyone have any other announcements this week? | 16:05 |
| rm_work | aannuusshhkkaa and shtepanie are joining us for the summer as dev interns at vzm! | 16:06 |
| johnsom | Yay! Welcome | 16:06 |
| cgoncalves | nice, welcome! | 16:06 |
| gthiemonge | welcome! | 16:06 |
| shtepanie | thank you! | 16:07 |
| aannuusshhkkaa | Thank you!! :) | 16:07 |
| rm_work | In the process of getting them up to speed, and we've got a topic later about what they'll be working on (metrics!) | 16:07 |
| openstackgerrit | Merged openstack/octavia master: add the verify for the session https://review.opendev.org/726567 | 16:08 |
| *** armax has joined #openstack-lbaas | 16:08 | |
| johnsom | Sounds good | 16:08 |
| johnsom | #topic Brief progress reports / bugs needing review | 16:08 |
| *** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 16:08 | |
| johnsom | I have been focused on catching up on reviews, getting the stable branches - sigh - stable, and cutting some stable branch releases. | 16:09 |
| ataraday_ | I was a bit off with internal processes. Now, want to highlight two changes, adding retry and preupgrade check for amphorav2 | 16:10 |
| johnsom | We got Ussuri and Stein out of the gate. Train is still broken on grenade issues | 16:10 |
| ataraday_ | #link https://review.opendev.org/#/c/726084/ | 16:10 |
| ataraday_ | #link https://review.opendev.org/#/c/735556/ | 16:10 |
| rm_work | Oh was it just this last week that we EOL'd two branches? Or was that already announced | 16:10 |
| rm_work | I'm losing track of time | 16:10 |
| johnsom | Oh, yeah, in fact it was! | 16:11 |
| * johnsom is living in a time warp as well | 16:11 | |
| johnsom | We have officially EOL'd the Ocata and Pike releases of Octavia. | 16:11 |
| johnsom | Thanks rm_work for leading that effort and navigating the process waters | 16:12 |
| cgoncalves | +1, thank you | 16:12 |
| rm_work | You mean breaking through the process wall like koolaid man | 16:12 |
| johnsom | Yes, that exactly, lol | 16:12 |
| rm_work | Which is my preferred style of political negotiation :D | 16:13 |
| johnsom | Well, it was a good thing as we should have truth in advertising and really no one was maintaining those branches anymore. | 16:13 |
| johnsom | I also spent some time looking at the centos amphora images to see if I could find any tricks to speed it up under qemu tcg. I achieved a huge improvement of 17 seconds. | 16:14 |
| johnsom | Which means, it still takes four minutes to boot and is still a problem. | 16:15 |
| rm_work | lol | 16:16 |
| rm_work | Well that's something | 16:16 |
| johnsom | Yeah, not worth the trouble really. | 16:16 |
| johnsom | Ok, any other progress reports or updates? | 16:17 |
| johnsom | ataraday_ Thanks for the patches! | 16:17 |
| *** rpittau is now known as rpittau|afk | 16:17 | |
| cgoncalves | I spent some time working on diskimage-builder to add centos 8 stream support. centos stream is the rolling pre-release of RHEL 8 and CentOS 8. there's a WIP patch in octavia side that builds an amphora and runs the tests, all successful | 16:17 |
| johnsom | Nice | 16:17 |
| rm_work | Cool | 16:17 |
| cgoncalves | I also continued to review johnsom's monster patch aka failover refactor patch | 16:17 |
| rm_work | Yeah we need to get that in :) | 16:18 |
| johnsom | Yeah, I have done a few comment update spins on that | 16:18 |
| rm_work | We've been running it in prod for over a month now? Multiple months maybe? | 16:18 |
| rm_work | It's been good | 16:18 |
| johnsom | Nice, that is good feedback. | 16:18 |
| johnsom | For the most part, the comment have been minor issues. I think the biggest change was adding retry timeouts to the configuration file. | 16:19 |
| johnsom | Based on the PTG feedback | 16:20 |
| johnsom | Ok, if there are no more updates, we can move on to "metrics" | 16:20 |
| johnsom | #topic metrics | 16:20 |
| *** openstack changes topic to "metrics (Meeting topic: Octavia)" | 16:20 | |
| johnsom | rm_work You have the conn | 16:20 |
| rm_work | Alright | 16:21 |
| rm_work | So, we're picking up this task! | 16:21 |
| rm_work | We discussed it briefly last night, and it seems it's essentially three parts | 16:21 |
| rm_work | ... and my irc window doesn't want to scroll back that far, apparently | 16:22 |
| rm_work | anyway, we think it's essentially: | 16:23 |
| rm_work | 1) Add new metrics at the system level (for example, RAM usage, CPU usage) | 16:23 |
| rm_work | 2) Transition to sending deltas instead of absolute totals, where it makes sense (for things like total connections and transfer bytes, but not for current active or the system stuff probably) | 16:24 |
| njohnston | tdd 9 | 16:25 |
| rm_work | 3) Rework/improve the driver layer to allow running multiple metrics storage drivers at once, and probably add at least one new driver for shipping metrics somewhere like influxdb | 16:25 |
| johnsom | +1 That is the list I am aware of | 16:26 |
| rm_work | We'll probably tackle 1 and 2 first | 16:27 |
| rm_work | The discussion topic today though is basically -- can we brainstorm what we actually want for #1? | 16:27 |
| johnsom | Yeah, those should go together nicely with a heartbeat protocol version bump | 16:27 |
| johnsom | yeah, that is a good question. | 16:28 |
| rm_work | i listed the two i can think of off the top of my head | 16:28 |
| johnsom | My first thought is percentages. Simply because the agent would have the best information about the nova flavor of the instance. | 16:29 |
| rm_work | yeah, definitely thinking percentages | 16:29 |
| johnsom | Ah, you meant which metrics. Yeah, RAM and CPU are on the top of my list. I personally don't have any others. | 16:29 |
| rm_work | which does mean those numbers would be absolute, not deltas | 16:29 |
| johnsom | Correct | 16:30 |
| rm_work | yeah is there anything else useful we could collect? | 16:30 |
| cgoncalves | disk? local logs can pile up | 16:30 |
| rm_work | hmm | 16:30 |
| rm_work | as an admin, having an at-a-glance of the disk might be useful in that specific situation | 16:31 |
| johnsom | Personally I think we have other ways to address that (log offloading and hourly rotation), but we have seen one case where some other issue in the cloud filled the system log file with garbage. | 16:31 |
| rm_work | but i don't know how generally useful that'd be in the 99% case for a user | 16:31 |
| cgoncalves | ok, it was just a thought. we can add later if we want to | 16:32 |
| rm_work | i guess we should clarify the goal | 16:32 |
| rm_work | I THINK what we're trying to do is add metrics that would allow one essential insight: how much "capacity" does my LB have left | 16:32 |
| johnsom | Yeah, my goal for those is to get us a step closer to auto-scaling | 16:33 |
| rm_work | and really, I am considering formulas that we could use to turn that into one easily digestable number | 16:33 |
| rm_work | which is apparently what AWS does with ELB | 16:33 |
| johnsom | Initially I'm not sure we should even add the "system" metrics to the API. Simply because they have little to no meaning for other provider drivers | 16:34 |
| rm_work | Yeah I think I agree | 16:35 |
| johnsom | And I don't want us to get in a strange situation when we enable active/active. | 16:35 |
| rm_work | We should just collect at first | 16:35 |
| johnsom | +1 | 16:35 |
| rm_work | which actually simplifies the task a bit :D | 16:36 |
| rm_work | then we can handle what to do with those new metrics in step 3, when we ship them somewhere | 16:36 |
| aannuusshhkkaa | AWS offers read/write bandwidth, idle time, latency on EBS. Do we want to offer features like that? | 16:37 |
| johnsom | Correct. Maybe, if we want to give some indication to the end user, we could consider adding a "HIGH LOAD" operating status, but I would consider that #4 or #20 on the list. | 16:37 |
| rm_work | I wonder if we can actually have any idea what percentage of read/write bandwidth is actually being used | 16:38 |
| rm_work | that would require an operator config setting, possibly | 16:38 |
| johnsom | Right, that is a hard one given neutron can't usually come close to what we can handle. | 16:38 |
| rm_work | yeah, and even if we know which NIC is in a HV, we don't know what bandwidth is like on the rest of the VMs that live there | 16:39 |
| johnsom | We do have bytes in/out and with deltas you could calculate the rate | 16:39 |
| rm_work | ah, yeah... how do we do deltas, exactly? that is one of my major concerns | 16:39 |
| rm_work | there's a few concerns there actually | 16:39 |
| rm_work | firstly, HOW? do we *reset* haproxy's counters constantly? | 16:40 |
| rm_work | do we keep an internal tracker in the agent? | 16:40 |
| rm_work | I suppose that's just going to be some research | 16:40 |
| johnsom | Yeah, my expectation is the agent will keep the previous value in memory and calculate the delta | 16:40 |
| rm_work | also, since we use UDP, do we just... hope all the packets get there, and possibly under-report? | 16:41 |
| johnsom | Yes, this would be a "may under report in some cases" scenario | 16:41 |
| rm_work | we have a sequence number so on the control-plane we could actually tell if we're missing packets and try to do some fill based on the points on either side... but that could be wrong too | 16:41 |
| rm_work | and better to under-report than over-report i guess | 16:41 |
| rm_work | also don't want to hugely increase the workload on the heartbeat ingestion | 16:42 |
| johnsom | Right and complex. We do already have a sequence number in the heartbeat message. We just don't use it for more than a nonce | 16:42 |
| rm_work | right | 16:42 |
| johnsom | FYI, here are the metrics haproxy can report: | 16:43 |
| johnsom | #link http://cbonte.github.io/haproxy-dconv/1.8/management.html#9.1 | 16:43 |
| johnsom | However, the LVS UDP side cannot support most of those | 16:43 |
| rm_work | yeah... | 16:44 |
| johnsom | So until we can switch out the UDP engine, that may constrain what we report or we need to call out the limitations. | 16:44 |
| johnsom | I also want to make sure we are careful to not put in things that other drivers don't support. I.e. no haproxy specific metrics. | 16:44 |
| rm_work | ah, hrsp_4xx hrsp_5xx etc was something mentioned | 16:45 |
| rm_work | but I don't know if we want to try to ship those from haproxy, or allow those to be calculated by a user via log analysis | 16:45 |
| johnsom | ereq and econ are also candidates | 16:45 |
| rm_work | I believe other things should be able to report those for HTTP type stuff | 16:45 |
| rm_work | we already ship ereq :) | 16:46 |
| johnsom | Ah, ok, so .... grin | 16:46 |
| rm_work | maybe hanafail? | 16:46 |
| rm_work | "failed health checks details" | 16:46 |
| rm_work | that is one other use-case | 16:46 |
| rm_work | but also, can be handled by logs | 16:46 |
| johnsom | Yeah, that is in the flow logs | 16:47 |
| johnsom | We also need to keep in mind the heartbeat message size. I think it is limited to 64k at the moment. That includes both stats and status | 16:47 |
| johnsom | Not that we can't change that, but just a consideration | 16:48 |
| rm_work | lbtot for members would be interesting | 16:48 |
| rm_work | "total number of times a server was selected, either for new | 16:48 |
| rm_work | sessions, or when re-dispatching" | 16:48 |
| johnsom | Yeah, that is per-member hits | 16:49 |
| rm_work | but anyway, I suppose we can move on, could be here all day :D | 16:49 |
| rm_work | and also, the user could get that info *from their members* :D | 16:49 |
| johnsom | Lots of goodies, but we need to be conservative | 16:49 |
| rm_work | yeah | 16:49 |
| johnsom | Or the flow logs, it's in there | 16:50 |
| rm_work | alright, last thing would be, does anyone ELSE want to work on #3? since that also could probably be done in parallel | 16:50 |
| rm_work | (updating to allow multiple drivers to be used at once, and adding one for influxdb or similar) | 16:50 |
| johnsom | The hard work there is defining the interface really | 16:51 |
| rm_work | if not, we can look at handling that after we wrap up 1+2 | 16:51 |
| rm_work | I think the interface is already defined -- technically it's already a driver layer? | 16:51 |
| rm_work | and it takes "our health message" :D | 16:52 |
| rm_work | unless you are saying you want to rework that | 16:52 |
| rm_work | and actually do some level of pre-parsing first | 16:52 |
| johnsom | Yeah, I was trying to remember what the content was. It's a de-wrapped heartbeat json isn't it? | 16:53 |
| rm_work | that would require a decent refactor -- it'd basically mean shifting 90% of the current "update_db" code up above the driver layer | 16:53 |
| rm_work | which maybe should be done | 16:53 |
| rm_work | because that doesn't really make sense | 16:53 |
| rm_work | we should have all that pre-parsing outside of the drivers | 16:53 |
| rm_work | and the "update_db" part should literally just be taking the final stats struct, and ... updating the DB | 16:53 |
| johnsom | Yeah, we should be able to rev the message format version without requiring all of the drivers to respin IMO. If we can avoid it. | 16:54 |
| rm_work | it's actually pretty badly organized | 16:54 |
| rm_work | yeah | 16:54 |
| rm_work | ok so maybe we MOVE the driver layer there | 16:54 |
| rm_work | do you think it'd be ok to break our existing plugin agreement there? | 16:54 |
| rm_work | i doubt anyone is using it? | 16:54 |
| johnsom | It is not a published interface today. We don't document it. | 16:55 |
| rm_work | it's internal to the amphora-driver | 16:55 |
| rm_work | alright | 16:55 |
| rm_work | so we'll probably reorganize that first | 16:55 |
| rm_work | which i guess actually means parts of #3 will be #0 | 16:55 |
| johnsom | But do keep in mind, we have a stats interface for the provider drivers too | 16:55 |
| rm_work | k | 16:55 |
| rm_work | yeah but i believe it is already totally different from the interface i'm referring to | 16:56 |
| johnsom | Yeah, it is a bit different | 16:56 |
| *** maciejjozefczyk has quit IRC | 16:56 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 16:57 | |
| rm_work | https://github.com/openstack/octavia/blob/master/octavia/amphorae/drivers/health/heartbeat_udp.py#L32-L47 | 16:57 |
| rm_work | I am referring to that one | 16:57 |
| rm_work | because currently 100% of the logic that parses the packet lives in the "update_db" driver | 16:58 |
| johnsom | Yeah, that will need improvement | 16:58 |
| rm_work | which is ... not correct | 16:58 |
| rm_work | that should all happen well before it passes to a driver, and what it should pass is a final structure with data | 16:58 |
| johnsom | I am talking about: | 16:59 |
| johnsom | #link https://github.com/openstack/octavia/blob/master/octavia/api/drivers/driver_agent/driver_updater.py#L139 | 16:59 |
| rm_work | yeah thats already closer to what an "update_db" driver SHOULD be tho | 17:00 |
| rm_work | so right inside there, we can actually share the driver layer and the struct we pass, I think | 17:00 |
| johnsom | Ok, we are out of time today. Thanks for the great discussion and work on metrics! | 17:00 |
| rm_work | driver layer should be here: https://github.com/openstack/octavia/blob/master/octavia/api/drivers/driver_agent/driver_updater.py#L166-L167 | 17:01 |
| rm_work | o/ thanks everyone | 17:01 |
| johnsom | #endmeeting | 17:01 |
| *** openstack changes topic to "Discussions for OpenStack Octavia | Priority bug review list: https://etherpad.openstack.org/p/octavia-priority-reviews" | 17:01 | |
| openstack | Meeting ended Wed Jun 17 17:01:17 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-06-17-16.00.html | 17:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-06-17-16.00.txt | 17:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-06-17-16.00.log.html | 17:01 |
| *** spatel has joined #openstack-lbaas | 17:16 | |
| *** kberger_ has quit IRC | 17:20 | |
| *** ataraday_ has quit IRC | 17:21 | |
| *** ccamposr has joined #openstack-lbaas | 17:21 | |
| *** ccamposr__ has quit IRC | 17:24 | |
| *** KeithMnemonic has joined #openstack-lbaas | 17:25 | |
| *** KeithMnemonic has quit IRC | 17:27 | |
| *** KeithMnemonic has joined #openstack-lbaas | 17:37 | |
| *** KeithMnemonic has quit IRC | 17:43 | |
| *** spatel has quit IRC | 18:37 | |
| *** spatel has joined #openstack-lbaas | 18:39 | |
| *** spatel has quit IRC | 19:08 | |
| *** vishalmanchanda has quit IRC | 19:38 | |
| *** spatel has joined #openstack-lbaas | 19:40 | |
| *** emccormick_ has joined #openstack-lbaas | 20:11 | |
| *** tobberydberg_ has joined #openstack-lbaas | 20:12 | |
| *** JasonF has joined #openstack-lbaas | 20:13 | |
| *** irclogbot_1 has quit IRC | 20:14 | |
| *** tobberydberg has quit IRC | 20:18 | |
| *** emccormick has quit IRC | 20:18 | |
| *** dtruong has quit IRC | 20:18 | |
| *** JayF has quit IRC | 20:18 | |
| *** emccormick_ is now known as emccormick | 20:18 | |
| *** dtruong has joined #openstack-lbaas | 20:19 | |
| *** irclogbot_1 has joined #openstack-lbaas | 20:21 | |
| *** gcheresh has joined #openstack-lbaas | 20:30 | |
| *** lxkong has quit IRC | 20:35 | |
| *** aannuusshhkkaa has quit IRC | 20:37 | |
| *** shtepanie has quit IRC | 20:38 | |
| *** hemanth_n has quit IRC | 20:40 | |
| *** emccormick has quit IRC | 20:41 | |
| *** emccormick has joined #openstack-lbaas | 20:45 | |
| *** emccormick has quit IRC | 20:51 | |
| *** shtepanie has joined #openstack-lbaas | 20:52 | |
| *** hemanth_n has joined #openstack-lbaas | 20:57 | |
| *** shtepanie has quit IRC | 20:57 | |
| *** maciejjozefczyk has quit IRC | 21:00 | |
| *** JasonF is now known as JayF | 21:06 | |
| *** lxkong has joined #openstack-lbaas | 21:09 | |
| *** spatel has quit IRC | 21:13 | |
| *** lxkong has quit IRC | 21:16 | |
| *** gcheresh has quit IRC | 21:17 | |
| *** salmankhan has quit IRC | 21:27 | |
| *** aannuusshhkkaa has joined #openstack-lbaas | 21:34 | |
| *** lxkong has joined #openstack-lbaas | 21:34 | |
| *** spatel has joined #openstack-lbaas | 21:38 | |
| *** emccormick has joined #openstack-lbaas | 21:40 | |
| *** shtepanie has joined #openstack-lbaas | 21:42 | |
| *** spatel has quit IRC | 21:43 | |
| *** spatel has joined #openstack-lbaas | 21:45 | |
| *** stingrayza has joined #openstack-lbaas | 21:54 | |
| *** also_stingrayza has quit IRC | 21:57 | |
| *** spatel has quit IRC | 22:02 | |
| *** born2bake has quit IRC | 22:22 | |
| *** spatel has joined #openstack-lbaas | 22:29 | |
| *** spatel has quit IRC | 22:32 | |
| *** TrevorV has quit IRC | 22:36 | |
| *** rcernin has joined #openstack-lbaas | 22:42 | |
| *** tkajinam has joined #openstack-lbaas | 22:54 | |
| *** shtepanie has quit IRC | 23:05 | |
| *** ccamposr__ has joined #openstack-lbaas | 23:15 | |
| *** ccamposr has quit IRC | 23:18 | |
| *** ccamposr has joined #openstack-lbaas | 23:41 | |
| *** ccamposr__ has quit IRC | 23:44 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!