Wednesday, 2019-04-10

openstackgerritMerged openstack/neutron-lbaas stable/queens: Replace git:// URLs with https://
openstackgerritMerged openstack/neutron-lbaas stable/ocata: Replace git:// URLs with https://
openstackgerritMerged openstack/neutron-lbaas master: Replace git:// URLs with https://
*** yamamoto has joined #openstack-lbaas00:48
*** yamamoto has quit IRC00:51
*** yamamoto has joined #openstack-lbaas00:58
*** yamamoto has quit IRC01:03
*** openstackgerrit has quit IRC01:30
*** yamamoto has joined #openstack-lbaas01:47
*** abaindur has quit IRC01:51
*** eandersson has joined #openstack-lbaas01:52
*** openstackgerrit has joined #openstack-lbaas02:17
openstackgerritErik Olof Gunnar Andersson proposed openstack/octavia master: [WIP] Add thread support to health manager
eanderssonSuper WIP ^02:17
*** hongbin has joined #openstack-lbaas02:29
*** yamamoto has quit IRC02:40
*** yamamoto has joined #openstack-lbaas02:41
*** psachin has joined #openstack-lbaas03:01
*** ricolin has joined #openstack-lbaas03:31
*** HVT has joined #openstack-lbaas03:36
*** hongbin has quit IRC03:42
*** ramishra has joined #openstack-lbaas03:44
openstackgerritErik Olof Gunnar Andersson proposed openstack/octavia master: [WIP] Add thread support to health manager
eanderssonsapd1, rm_work, johnsom etc let me know if you have any feedback etc ^04:05
eanderssonWe have been running this for a few weeks internally04:05
rm_workHmm k I'll look tomorrow or later tonight04:06
eanderssonThanks - not a super important patch04:06
eanderssonJust felt like I would try to upstream it04:06
*** abaindur has joined #openstack-lbaas04:13
*** abaindur has quit IRC04:26
*** abaindur has joined #openstack-lbaas04:26
*** openstackstatus has quit IRC04:35
*** openstackstatus has joined #openstack-lbaas04:36
*** ChanServ sets mode: +v openstackstatus04:36
*** yamamoto has quit IRC04:57
*** pcaruana has joined #openstack-lbaas05:06
*** yamamoto has joined #openstack-lbaas05:07
*** yamamoto has quit IRC05:10
*** yamamoto has joined #openstack-lbaas05:10
*** ricolin has quit IRC05:30
*** gcheresh has joined #openstack-lbaas05:34
*** gcheresh has quit IRC05:39
*** yamamoto has quit IRC05:49
*** yamamoto has joined #openstack-lbaas05:50
openstackgerritVishal Manchanda proposed openstack/neutron-lbaas-dashboard master: Fix sphinx-docs job for sphinx >1.7
*** ccamposr has joined #openstack-lbaas05:58
*** gcheresh has joined #openstack-lbaas06:04
*** vishalmanchanda has joined #openstack-lbaas06:04
*** abaindur has quit IRC06:25
*** yamamoto has quit IRC06:26
*** yamamoto has joined #openstack-lbaas06:27
*** yamamoto has quit IRC06:32
*** yamamoto has joined #openstack-lbaas06:38
*** luksky has joined #openstack-lbaas06:45
*** yamamoto has quit IRC06:47
*** yamamoto has joined #openstack-lbaas06:48
*** rpittau|afk is now known as rpittau07:05
*** ivve has joined #openstack-lbaas07:12
*** ataraday has quit IRC07:18
cgoncalveseandersson, we just moved off of threads to processes around rocky, heh07:31
*** psachin has quit IRC07:32
cgoncalveseandersson, thanks for the patch! it would be great if you could add more context as to what is the problem you see with processes and why green threads07:32
*** pcaruana has quit IRC07:34
*** pcaruana has joined #openstack-lbaas07:35
*** psachin has joined #openstack-lbaas07:36
*** yamamoto has quit IRC07:37
*** yamamoto has joined #openstack-lbaas07:38
*** yamamoto has quit IRC07:56
*** livelace has joined #openstack-lbaas07:58
*** lemko has joined #openstack-lbaas08:09
*** luksky has quit IRC08:11
*** yamamoto has joined #openstack-lbaas08:11
*** yamamoto has quit IRC08:22
*** ricolin has joined #openstack-lbaas08:30
*** luksky has joined #openstack-lbaas08:50
*** yamamoto has joined #openstack-lbaas08:54
*** livelace has quit IRC08:59
*** salmankhan has joined #openstack-lbaas09:15
*** salmankhan has quit IRC09:19
*** salmankhan has joined #openstack-lbaas09:19
openstackgerritMerged openstack/octavia stable/queens: Fix the API list performance regression
cgoncalvesQueens 2.0.5 and Rocky 3.0.3 releases proposed:
cgoncalvesthank you every one of you for your patches and reviews!09:27
*** yamamoto has quit IRC09:28
*** happyhemant has joined #openstack-lbaas09:32
*** livelace has joined #openstack-lbaas09:41
*** rcernin has quit IRC09:47
*** yamamoto has joined #openstack-lbaas09:58
*** yamamoto has quit IRC10:01
*** yamamoto has joined #openstack-lbaas10:01
*** yamamoto has quit IRC10:05
*** yamamoto has joined #openstack-lbaas10:44
*** yamamoto has quit IRC10:50
lxkongcgoncalves: not sure you are the right person i should ask, but when do we plan to do a new release for python-octaviaclient?11:07
*** HVT has left #openstack-lbaas11:12
cgoncalveslxkong, hi. guessing you're asking because of
lxkongcgoncalves: correct :-)11:13
cgoncalveslxkong, it is merged only in master. how far back would you like to have it?11:13
cgoncalvesI mean, in which stable branch?11:14
lxkongooh, i forgot the client lib also has stable branch11:14
lxkonglet me check11:14
cgoncalvesif would be great if you could propose the backports11:15
lxkongcgoncalves: we need stable/queens11:16
lxkongqueens and rocky both have conflict, if no one is interested, i need to find time to figure out11:17
cgoncalveslxkong, conflicts should be due to added support to new APIs like flavors, amphora configure, etc. should be easy to resolve. let me know if you can do it, otherwise one us can take it11:20
lxkongcgoncalves: i will have a try tomorrow, it's 23:21 for me now11:21
cgoncalveslxkong, sure. thank you! let us know if you need help11:21
lxkongcgoncalves: cheers11:22
*** livelace has quit IRC11:24
*** yamamoto has joined #openstack-lbaas11:26
*** sapd1 has quit IRC11:29
*** sapd1 has joined #openstack-lbaas11:29
*** lemko has quit IRC11:39
*** sapd1 has quit IRC12:00
*** sapd1 has joined #openstack-lbaas12:02
*** boden has joined #openstack-lbaas12:03
*** ricolin has quit IRC12:50
*** ricolin has joined #openstack-lbaas12:51
openstackgerritMerged openstack/neutron-lbaas-dashboard master: Fix sphinx-docs job for sphinx >1.7
*** irclogbot_2 has joined #openstack-lbaas13:03
*** altlogbot_3 has joined #openstack-lbaas13:07
*** yamamoto has quit IRC13:19
*** yamamoto has joined #openstack-lbaas13:19
*** chungpht has quit IRC13:45
*** happyhemant is now known as hemant13:57
*** hemant is now known as Guest1036113:57
*** Guest10361 is now known as happyhemant13:58
*** fnaval has joined #openstack-lbaas14:10
*** openstackgerrit has quit IRC14:14
*** Vorrtex has joined #openstack-lbaas14:15
*** Vorrtex has quit IRC14:18
*** Vorrtex has joined #openstack-lbaas14:19
*** sapd1 has quit IRC14:27
*** sapd1 has joined #openstack-lbaas14:27
*** Vorrtex has quit IRC14:33
*** yamamoto has quit IRC14:36
*** yamamoto has joined #openstack-lbaas14:40
*** yamamoto has quit IRC14:41
*** yamamoto has joined #openstack-lbaas14:42
*** yamamoto has quit IRC14:47
*** openstackgerrit has joined #openstack-lbaas14:50
openstackgerritVishal Manchanda proposed openstack/neutron-lbaas-dashboard master: Drop nodejs4 job
*** luksky has quit IRC14:51
*** ianychoi has quit IRC14:56
*** ccamposr has quit IRC14:58
*** sapd1 has quit IRC15:09
*** sapd1 has joined #openstack-lbaas15:09
*** CBR09 has joined #openstack-lbaas15:10
CBR09hi everyone, when I create a loadbalancer, I always get LB in active and offline status, not online15:21
CBR09I investigated I think my octavia-health-manager didn't receive heartbeat from amphora15:22
CBR09but when I capture udp packet, I can see heartbeat packet from my amphora15:22
cgoncalvesCBR09, hi. check if the amphora is sending the heartbeats out to the health manager on port 5555 (default) protocol UDP15:22
cgoncalvesok. are you capturing that on the amphora port or health manager port?15:23
CBR09yea I use tcpdump -n udp on my health manager port15:23
*** gcheresh has quit IRC15:24
cgoncalvesCBR09, the health manager should be logging income heartbeats. could you please check that? enable debug mode15:24
CBR09I also check health-manager logs, I don't see any log about receive hearbeat (I enabled debug=true), that why I know my health-manager didn't get packets15:26
CBR09is there any chance for kernel drop udp packets?15:26
cgoncalvesif you say you're seeing packets arriving to the health manager port, unlikely15:27
cgoncalvesin any case, check your firewall15:27
cgoncalvesUDP :5555 on the health manager port15:27
*** ivve has quit IRC15:28
CBR09I checked my firewall, everything is open and when I capture heartbeat packet, I think my firewall allow that15:29
cgoncalvesany chance you could share with us the health manager logs?15:31
CBR09my command tcpdump15:31
CBR09tcpdump -n udp -X -vv15:31
CBR09my packet capture15:32
cgoncalvesCBR09, that capture is not on the health manager port, so I wonder if the packets are not indeed being dropped by firewall or so15:33
CBR09ah I not showing that, when I capture above packets, I just capture on -i interfaces15:34
CBR09my netstat -suna output15:35
CBR09Udp:      4760839594 packets received      245908 packets to unknown port received.      6024234678 packet receive errors      10785320512 packets sent      6024234678 receive buffer errors      0 send buffer errors15:35
CBR09I can see receive buffer errors15:35
CBR09is there any chance for that?, my kernel drop udp packet15:36
cgoncalvesthat's a lot of packet errors...15:38
cgoncalvestry to send a dummy packet to the HM port from the same host just to see if it it logs something15:39
cgoncalvessyslog might also be logging something useful15:40
CBR09you mean, I fake udp packet to port 5555?15:41
cgoncalvesI'd expect HM to receive, log and drop15:42
CBR09yea, let me try it15:47
*** gcheresh has joined #openstack-lbaas15:50
*** yamamoto has joined #openstack-lbaas15:50
*** rpittau is now known as rpittau|afk15:53
openstackgerritMerged openstack/neutron-lbaas-dashboard master: Drop nodejs4 job
*** yamamoto has quit IRC15:59
CBR09Hi @cgoncalves16:00
CBR09I send a udp packet16:00
CBR09and HM logs16:00
cgoncalvesCBR09, yeah so the health manager service is working fine. the problem is the heartbeat packets are being dropped somewhere before reaching to the service16:05
CBR09yea, I also think that, but I have no idea what drop16:06
cgoncalvesCBR09, have you checked syslog?16:07
CBR09we run centos os, so we don't have syslogs, we just have message16:09
cgoncalveswell, that :)16:12
CBR09it's hard to think how that is possible :))16:13
*** psachin has quit IRC16:14
CBR09I've tried capture on HM port 555516:16
CBR09I can see udp packet on that port16:16
cgoncalvesCBR09, right, but for some reason packets are dropped as you don't see any sign of them being logged in the health manager16:26
cgoncalvescheck /var/log/message and /var/log/audit/audit.log16:27
cgoncalvesdo you have SELinux enforcing?16:27
openstackgerritMerged openstack/neutron-lbaas stable/rocky: Fix proxy extension for neutron RBAC
*** ivve has joined #openstack-lbaas16:30
*** sapd1 has quit IRC16:32
*** sapd1 has joined #openstack-lbaas16:32
*** ramishra has quit IRC16:41
*** altlogbot_3 has quit IRC16:46
*** salmankhan has quit IRC16:50
*** ivve has quit IRC16:51
*** gcheresh has quit IRC16:51
CBR09thank @cgoncalves, I will check more :*16:55
CBR09thank @cgoncalves, I will check more :(16:55
CBR09thank for your support16:55
cgoncalvesCBR09, please let us know if you find what is causing the behavior you're observing16:56
CBR09@cgoncalves: ah, my health-manager IP and amphora IP is difference16:56
CBR09is that okay ?16:57
CBR09my health-manager listen at 10.x.x.x and my amphora on 172.x.x.x16:57
eanderssoncgoncalves, it allowed me to push more, with less workers17:10
eanderssonThis is different from the old implementation though as this combines threads and workers17:13
eanderssonIt really just gives you a bit more control, as you can use both threads and workers17:15
*** sapd1 has quit IRC17:29
*** sapd1 has joined #openstack-lbaas17:30
*** xgerman has joined #openstack-lbaas17:33
*** luksky has joined #openstack-lbaas17:47
*** ricolin has quit IRC17:49
*** CBR09 has quit IRC17:49
*** sapd1 has quit IRC18:00
*** sapd1 has joined #openstack-lbaas18:00
*** gcheresh has joined #openstack-lbaas18:05
*** Vorrtex has joined #openstack-lbaas18:09
*** yamamoto has joined #openstack-lbaas18:12
*** happyhemant has quit IRC18:33
*** gcheresh has quit IRC18:37
*** ivve has joined #openstack-lbaas18:38
*** vishalmanchanda has quit IRC18:39
-openstackstatus- NOTICE: Restarting Gerrit on to pick up new configuration for the replication plugin19:05
*** yamamoto has quit IRC19:23
*** yamamoto has joined #openstack-lbaas19:24
*** yamamoto has quit IRC19:29
cgoncalvesjohnsom, o/20:01
*** ivve has quit IRC20:01
cgoncalvesweekly meeting?20:02
johnsomYeah, sorry, just a sec20:02
johnsom#startmeeting Octavia20:03
openstackMeeting started Wed Apr 10 20:03:16 2019 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.20:03
*** openstack changes topic to " (Meeting topic: Octavia)"20:03
openstackThe meeting name has been set to 'octavia'20:03
johnsomUgh, sorry folks.  Still getting back in the groove after travel.20:03
cgoncalveshope you enjoyed it :)20:04
johnsom#topic Announcements20:04
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"20:04
johnsomHa, well, yesterday was a long travel day.20:04
johnsomThe biggest announcement I have today is:20:05
johnsomStein is released!20:05
johnsomlol, ok, that was a link to message, with a link to a message, with a link to the release.20:06
cgoncalvesawesome! thanks to many of you for your code contributions, reviews and discussions!20:06
johnsomThank you to the whole team for your efforts on Octavia this cycle!20:06
johnsomWe got a lot of good work done.20:07
cgoncalvesthe Octavia Stein release notes are impressive!20:07
johnsomYou beat me to posting that link.20:07
johnsomThere are also the cycle highlights for the press type people:20:08
johnsomAgain, thank you all for a successful release. Please raise yourself a toast!20:09
*** sapd1 has quit IRC20:10
johnsomAre there any other announcements today?20:11
johnsomOk, just a heads up, the Summit is coming up in a few weeks.20:12
johnsomPlease remember to enter any topic ideas, etc. on the Octavia PTG etherpad:20:12
johnsom#topic Brief progress reports / bugs needing review20:13
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"20:13
cgoncalvesif someone cannot attend the PTG but would like to participate, please let us know. we may be able to setup a conference system20:14
johnsomOther than traveling, I worked on cleaning up our "unset" story for the client and the API. I'm working through the API making sure that PUT calls with "None/null" are handled correctly and that we have openstack client "unset" actions available.20:14
johnsomYes, and please still add your topic to the list.  We can also do a coordinated IRC time if that works better for folks than attempting a video conference.20:15
nmagneziyeah, I had some question about one patch related to listener20:15
*** sapd1 has joined #openstack-lbaas20:16
johnsomI also spent some time last week working on a last minute critical bug for the release. My fix ifup patch introduced a bug that could cause the base port IP to not come up.20:16
johnsomnmagnezi Do you want to chat about those in open discussion?20:16
nmagnezijohnsom, sure20:16
johnsomCool.  Any other updates from folks?20:17
cgoncalvesprogress report from my side is: active-standby tempest test is ready for reviews20:17
cgoncalvesas is the spare pool tempest test20:17
johnsomYay!  That Active/Standby likely would have caught the above mentioned bug.20:18
cgoncalvesI also did some important backports, namely one about performance contributed by eandersson20:18
johnsomNice. I think you also have some stable releases up for review to get those out.20:19
johnsomcgoncalves I know there was some talk while I was gone about a client release. Is that in progress or something I should look at?20:20
cgoncalvesrelease Octavia Queens 2.0.5 and Rocky 3.0.320:20
cgoncalvesjohnsom, lxkong is work on the backport tomorrow his time20:20
johnsomOk, sounds good20:21
cgoncalves(the "yes" was for the stable releases up for review comment)20:21
johnsomI will also mention here, there are a number of tempest plugin patches still open for review. Some relating to flavors, etc.  It would be good to get some eyes on those so we have a stronger testing suite.20:22
johnsomAny other updates before we move on?  (remember, this isn't just for the core team, it's a great time for anyone participating to share with the wider team)20:24
johnsomFor the week going forward,20:24
johnsomI have some internal stuff to work on, then probably getting slides started for the Summit and continuing to work on the unset work.20:25
rm_worki'm just looking forward to the PTG, so we can get some discussion in on priorities and roadmap for Train20:25
rm_workand get started on the big rocks there20:25
johnsomYep!  Maybe in a week or so I will start working on a rough schedule for the topics.  That is unless rm_work wants to do it.20:26
rm_workgo ahead, sounds good :)20:26
* johnsom feels like the team all just took a step back20:26
cgoncalvesthere is a patch up proposing a fix in our providers support20:27
johnsomYeah, I need to take a close look at that. We have a wrapper that should be handling any driver issue, so not sure how that would not have been handled.20:28
cgoncalvesthe OVN team might have been hit by this issue a few weeks ago, too. they work-arounded it by creating the VIP port themselves20:28
johnsomI will also note, the NSX driver in neutron had some release trouble because they were linking directly into Octavia and directly accessing the database. I hope the folks working on that will work with us to make sure they have what they need to be "good provider citizens" and this isn't an issue going forward.20:29
cgoncalvesprovider vendors out there listening: please reach out if you need advise/help!20:30
johnsomIt didn't look like it was any big design issue, just a few fields or new driver API methods needed.20:31
johnsom#topic New IRC meeting time20:31
*** openstack changes topic to "New IRC meeting time (Meeting topic: Octavia)"20:31
johnsomOk, so last week we started a doodle poll and sent e-mail to the discuss list about changing the Octavia IRC meeting time.20:32
johnsomThat is/was the link to the doodle poll20:33
rm_workpersonally i am kinda hoping it doesn't have to change :D20:33
johnsomThere was a four way tie, all of which were a new time.20:34
*** sapd1 has quit IRC20:34
johnsomThe winning times were on Tuesday or Wednesday, 15:00 or 16:00 UTC.20:35
johnsomWe have a choice to make:20:35
johnsom1: we can do another poll, with only those time slots.20:35
johnsom2: We can pick the time slot based on the new PTL's choices, which would be 16:00 UTC.20:36
johnsomPersonally I think we should just use the 16:00 time slot and pick either Tuesday or Wednesday.20:37
*** sapd1 has joined #openstack-lbaas20:37
johnsomI would lean towards keeping it on Wednesday.20:38
cgoncalves16:00 UTC works for me. I'd say Wednesday to keep the same week day20:38
rm_workOk. Hopefully I make it to enough of those :D20:39
rm_workis that... 9am PST?20:39
johnsomAny comments/concerns with Wednesdays at 16:00 UTC?20:41
rm_workjohnsom: as our community manager, you're going to continue to run the meetings, right?20:41
nmagneziI preferred the current time. But if that works for everyone I guess that's okay20:41
rm_worknmagnezi: did you do the poll? :D20:41
johnsomrm_work Ummm, technically that is a PTL activity.....20:42
nmagnezirm_work, I did20:42
rm_workthen apparently yes20:42
rm_workjohnsom: does it say that somewhere? ;)20:42
johnsomrm_work I have a few weeks to *make* it say so if I need....  grin20:43
johnsomSeriously though, you can delegate that out20:43
johnsomOk, so are we good that I should do all the paperwork type stuff to move the time to 16:00 UTC?20:44
johnsomGoing once....20:45
johnsomgoing twice....20:45
johnsomSold! Our new IRC meeting time will be Wednesdays at 16:00 UTC (four hours earlier than our previous time).20:45
* rm_work dies20:46
* cgoncalves updates his calendar20:47
johnsomI will update the OpenStack meetings page, our wiki, and send out an e-mail.20:47
*** ivve has joined #openstack-lbaas20:48
johnsomFYI, I have also opened it so you can see how folks voted now that the poll is done.20:48
* nmagnezi looks20:49
johnsom#topic Open Discussion20:49
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)"20:49
nmagnezicgoncalves, you really wanted to change the time. lol20:49
cgoncalvesnmagnezi, as you can see, I was open to any time slot proposal!20:50
johnsomnmagnezi I think you had some questions about the listener unset patch?20:51
nmagnezijohnsom, yes20:51
nmagnezijohnsom, wrote it as a comment
nmagnezijust wondering why we reset to default and if we should actually do that, that's all20:52
johnsomYeah, sorry, I have been traveling and haven't caught up yet.20:52
nmagneziJust asking because another way to look at it, is as some invalid input that you ignore20:53
nmagneziSo as I wrote, the patch itself is fine code-wise. Just wondered about the outcome20:53
johnsomWell, the values that I reset to the default are values that don't make sense with "None" in them.  Like a timeout value, you can't really have a None timeout, we have a defined range for those. So I felt an "unset" of a timeout would translate back to the default we have set for those.  However, very  open for discussion on it.20:54
nmagneziFully agree. But aren't this just for updates?20:55
nmagneziI mean, if you create a new listener and provided nulls I agree that defaults make sense20:55
johnsomAh, ok, so your question is how do they *not* set a currently set field?  I.e. Timeout A is set to 11, where the default is 10 (yes, yes, select numbers chosen).20:56
johnsomSo with the PUT API, to *not* update a field, you just don't include that parameter in the JSON document.  This is how it works today.20:57
nmagneziAha, okay probably I got it wrong by looking at the "Fix listener API handling of None/null updates" topic (no need to change it)20:57
johnsomIf you want to update the "name" but not the "timeout A", you would PUT a json with just 'name': 'great' in it and not include the "timeout A" field at all.20:58
nmagneziI thought this is for updates20:58
johnsomYes, this is for updates.20:58
cgoncalvesyeah, set/unset are PUT API requests20:59
johnsomWith this patch, if you do include "timeout A" field, with "null" in it, it will now reset to the default value for that field.20:59
johnsom(FYI, null is JSON for None in python in this case)20:59
johnsomOk, we are out of time because I was late, sorry.  We can continue chatting in the channel.21:00
*** openstack changes topic to "Discussions for OpenStack Octavia | Train PTG etherpad:"21:00
openstackMeeting ended Wed Apr 10 21:00:27 2019 UTC.  Information about MeetBot at . (v 0.1.4)21:00
openstackMinutes (text):
johnsomnmagnezi Does that help clarify or am I confusing you more?21:01
nmagneziI'm thinking maybe I should look at this again21:01
nmagneziBut just to double check21:01
johnsomOk. I think I also need to update the API reference to call out the null behavior better. I was saving that until the end, but maybe I should do that in each section.21:02
nmagneziA value fed to an option with None/null will cause it to get reset to default, even if there was come valid value placed in it beforehand, right?21:02
johnsomIf there is a defined default for that field.21:02
nmagneziSo my question is21:02
johnsomIf our API doesn't have a default for the field, like name, it will go to None.21:02
nmagneziWhy is None/null being handled like that and not the same as any other invalid input?21:03
nmagneziThat's where I said I'm open for discussion so I might change my vote21:03
johnsomYeah, I like the discussion, it only makes the project better.21:04
johnsomLet's look at one of the timeouts:21:05
johnsomSo in our current code, when you create a listener, we define both a default, and a valid range.21:05
johnsomSo, if we create a listener and don't set this field, it gets the default value. But let's say they do set it to 11 (default is 10).21:06
johnsomThen, later, they decide 11 isn't right, and they want to reset it to the default value.  They could go look at the API ref, find the default value and set that, or with the patch they can do a PUT (update) with the field set to null.21:07
nmagneziso we basically look at it as.. a feature? :)21:08
johnsomWe don't want to set this field to None for a few reasons: First, None isn't valid for the validation ranges we define in the API ref. Second, we like to keep the "show" commands returning a value that represents what is actually being used in the load balancer.21:09
johnsomWell, It's not quite a feature in that if you set it to null today, we break. It does shove "None" in the field, which then blows up when the config file is rendered.21:09
nmagneziSo yeah I fully agree on the fact that we need to handle null21:10
johnsomSo, right now, before the patch, "null" is .... Who knows what will happen.21:10
nmagneziIt's just that I wanted to know why in the specific way (as opposed to just reject it for example)21:10
rm_workyeah i think default makes sense21:10
rm_workit echoes quotas, in that when you "delete your custom value" it goes back to the default21:11
johnsomThat is what I'm trying to fix.  Some of our fields work right, some just blindly take None and fail.21:11
johnsomRight, and from the CLI it's pretty intuitive that "unset" of a field restores the default.21:11
johnsomWe could just reject nulls on fields that can't be "None". That is a valid option.21:12
colin-hello sorry i'm late21:13
johnsomI just felt this approach was a bit more user friendly in that they don't have to lookup the defaults to reset it.21:13
nmagneziI don't have a strong opinion here. I fully agree that we should definitely handle null and not take it blindly. It's just that the decision to reset to default was unique :) but maybe it is common and I just didn't notice21:13
johnsomThese are "proposed" patches.... grin21:14
nmagneziYeah if we do that21:14
nmagneziwe should be consistent21:14
*** sapd1 has quit IRC21:14
johnsomI don't think the API working group has guidance on this. I should probably go double check.21:14
johnsomI think I looked last week, but I'm not 100% sure.21:15
nmagneziif you find something just write it and I'll catch up my morning21:15
nmagneziThanks for the good discussion!21:15
johnsomThis is the URL BTW:
johnsomSure, thanks for asking the questions!  Have a good night.21:16
nmagneziWill re-review the patch tomorrow21:16
*** sapd1 has joined #openstack-lbaas21:19
*** fnaval has quit IRC21:20
*** ivve has quit IRC21:25
*** fnaval has joined #openstack-lbaas21:29
*** fnaval has quit IRC21:32
*** fnaval has joined #openstack-lbaas21:34
*** boden has quit IRC21:35
lxkongjohnsom, rm_work,  morning, i'm reading the release notes of Octavia Stein. `The Stein release of Octavia adds the driver-agent controller process` i wonder if the driver-agent  is necessary?21:38
johnsomlxkong Only if you are using provider drivers other than Octavia. However, at some point in the future, the Octavia provider will also use that.21:41
lxkongjohnsom: ok, so we don't need to care about that right now.21:42
lxkongjohnsom: btw, thanks for the hard work for Stein, I can see there were significant improvements and new features21:43
johnsomlxkong Team effort!21:45
*** sapd1 has quit IRC21:50
*** sapd1 has joined #openstack-lbaas21:54
*** rcernin has joined #openstack-lbaas22:06
*** luksky has quit IRC22:17
*** jiteka1 has quit IRC22:22
*** sapd1 has quit IRC22:41
*** sapd1 has joined #openstack-lbaas22:42
*** sapd1 has quit IRC22:55
*** sapd1 has joined #openstack-lbaas22:58
*** sapd1 has quit IRC23:23
*** sapd1 has joined #openstack-lbaas23:24
*** ianychoi has joined #openstack-lbaas23:46
*** sapd1 has quit IRC23:48
*** sapd1 has joined #openstack-lbaas23:50
*** rcernin has quit IRC23:52

Generated by 2.15.3 by Marius Gedminas - find it at!