Wednesday, 2017-12-06

rm_workdefensive coding everywhere00:00
rm_workdon't get caught/screwed by an external service00:00
*** longstaff has joined #openstack-lbaas00:00
xgerman_yeah, it should be done but the question is  priority —00:00
rm_workk00:00
openstackgerritBar RH proposed openstack/python-octaviaclient master: Allow case-insevsitive enteries when selecting from choices  https://review.openstack.org/52579100:00
xgerman_BTW: reviewed your patch right away ;-)00:01
rm_workmy priority is "what is affecting me right now" :P which this just did00:01
rm_workappreciate it :P00:01
xgerman_yeah, I always forget the wacky cloud you run…00:02
tonglanyone noticed that in neutron-lbaas, adding more than 100 members to pool will slow down response significantly as the number increases.00:03
tonglI am wondering if this is related to db access or something.00:04
xgerman_we don’t use neutron-lbaas00:04
xgerman_but the db access in that is pretty wacky00:04
openstackgerritAdam Harwell proposed openstack/octavia master: Move loading the network driver into the flows  https://review.openstack.org/52579000:04
*** longstaff has quit IRC00:04
johnsomtongl Yes, if you mean API access, we are aware of that issue with neutron-lbaas.  It should be resolved in the octavia API00:05
johnsomOr, at least better00:05
tonglGreat. another reason to persuade our customer to move over to octavia.00:05
xgerman_+100:06
rm_workxgerman_: resolved your issue i hope :)00:06
xgerman_yep, I gave you +100:06
xgerman_rongl this might help: https://review.openstack.org/#/c/418530/ - bypasses Neutron…00:06
xgerman_tongl:00:07
tonglgood pointer, I am looking at it. thanks german00:09
openstackgerritBar RH proposed openstack/python-octaviaclient master: Allow case-insevsitive enteries when selecting from choices  https://review.openstack.org/52579100:11
openstackgerritBar RH proposed openstack/python-octaviaclient master: Allow case-insevsitive enteries when selecting from choices  https://review.openstack.org/52579100:12
tonglJust came back from a long business trip. Need to spend some time to pickup what I missed.00:12
openstackgerritMerged openstack/python-octaviaclient master: Add loadbalancer stats client api and osc  https://review.openstack.org/52330600:14
openstackgerritBar RH proposed openstack/python-octaviaclient master: Allow case-insensitive enteries when selecting from choices  https://review.openstack.org/52579100:15
*** fnaval has quit IRC00:17
*** threestrands has quit IRC00:25
openstackgerritAdam Harwell proposed openstack/octavia master: DNM: Revert "Disable kvm on OVH infra instances"  https://review.openstack.org/52572900:33
*** fnaval has joined #openstack-lbaas00:35
johnsomrm_work Remember it's only the scenario jobs.  The API jobs and lbaas jobs don't count.  I have made that mistake...00:35
rm_workahhh lol00:36
rm_worki was just thinking the api jobs would be ok but yeah :P00:36
*** tongl has quit IRC00:36
rm_workcorrect00:36
johnsomI got excited only to realize my test was bogus because I was looking at the worng job00:36
*** tongl has joined #openstack-lbaas00:36
rm_workheh00:37
*** tongl has quit IRC00:40
bar_johnsom, I submitted another octaviaclient patch (https://review.openstack.org/#/c/525791/). No dependencies this time.00:43
johnsombar_ Thanks.  I'm not sure I will have time to test/review that for Q2, but we still have Q3, so...00:44
*** SumitNaiksatam has left #openstack-lbaas00:46
*** bar_ has quit IRC00:47
openstackgerritMichael Johnson proposed openstack/octavia-dashboard master: Catch up with horizon framework  https://review.openstack.org/52324900:58
rm_workwooow01:04
rm_workthat's a change01:04
johnsomYeah, but it looks much better.01:04
johnsomMy only concern is it requires a new openstacksdk they have not released yet.01:04
rm_workumm01:04
rm_workah.01:04
johnsomhealth monitor fails without the fix in openstacksdk01:05
johnsomIt's merged, but not yet released, GR, etc.01:05
johnsomdayou This looks really good.01:05
dayouThanks, man!01:06
johnsomMy only worry is the openstacksdk package isn't out yet.01:06
johnsomWe may need to release Q2 without this one, but do it in Q301:06
johnsomThoughts?01:06
dayouMonty told me there should be a new release soon01:06
dayouI am ok with your arrangment, have no idea what is Q2 and what is Q3.01:07
johnsomAh, Queens milestone 2 and milestone 3 release.  The are intermediate releases before the official Queens release of OpenStack01:07
johnsomQueens 3 is when we have to have all of the features in.01:08
dayouAh, I see, May I stack a few other patches on this? To fix further bugs in octavia-dashboard later.01:09
*** longstaff has joined #openstack-lbaas01:09
johnsomYes, no problem since we will push it to merge in after Q201:10
dayouGot you01:10
johnsomI have one comment so far.  I will keep looking at it for a few more minutes01:10
dayouYes, keep me updated on this01:11
johnsomI have to say though, the details pages look much nicer.  Great work01:12
*** sshank has quit IRC01:13
dayouAlso make the modifying easier later, since now all are resource registry based, if there are changes in api, just need to change some names01:13
*** longstaff has quit IRC01:14
johnsomdayou Ok, that one thing is all I saw.  Just a string a bit long.  It's been that long, but I really noticed it here.01:20
openstackgerritMerged openstack/octavia master: Fix filtering in list API calls  https://review.openstack.org/52268901:21
johnsomOk, time to make dinner.  Thanks folks, I think we are in pretty good shape for Q2 release tomorrow.  I will get a patch going in the morning here.01:23
dayouYes sir, I'll change that.01:23
dayouEnjoy your dinner, BTW!01:24
johnsomdayou, oh, I see the LB uuid wraps to in the drop down.  Maybe a little tweak on that?01:24
johnsomBoth very minor01:24
dayouI'll try to tweak that01:24
johnsomI never know if that is just my browser/system or not.01:25
dayouUUIDs are long, so it might wrap sometimes, I have to start a devstack and repick that, was working on something else.01:27
*** sshank has joined #openstack-lbaas01:40
*** longstaff has joined #openstack-lbaas01:51
*** longstaff has quit IRC02:00
*** longstaff has joined #openstack-lbaas02:00
*** sshank has quit IRC02:02
*** longstaff has quit IRC02:03
*** longstaff has joined #openstack-lbaas02:03
*** longstaff has quit IRC02:03
openstackgerritZhaoBo proposed openstack/octavia master: Extend api to accept qos_policy_id  https://review.openstack.org/45830802:03
openstackgerritZhaoBo proposed openstack/octavia master: Support UDP load balance  https://review.openstack.org/50360602:04
*** oanson has quit IRC02:12
*** jniesz has quit IRC02:12
*** oanson has joined #openstack-lbaas02:12
openstackgerrithuangshan proposed openstack/octavia master: Amphora API Failover call  https://review.openstack.org/52577802:31
openstackgerritHengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059002:35
dayouAdam, there is a possbile solution, I tried on some vms, it works, it's revert back to use eth0 for ubuntu02:38
dayouSo there won't be any suprise, also aligned with your solution for redhat distributions02:38
dayouMaybe we should do the same for fedora also02:39
dayouThey also use predictable interface names02:39
dayouLukily the solution is the same, disable cloud init networking and add net.ifnames=0 biosdevname=0 to kernel boot options02:41
*** tongl has joined #openstack-lbaas02:42
*** SumitNaiksatam_ has joined #openstack-lbaas02:49
rm_workhmmm02:49
rm_workdayou: not sure we want to disable cloud-init networking >_>02:49
dayouOther it would generate it's own network configuration files overwrite ours02:52
rm_worki'm not sure how?02:55
rm_workmine doesn't02:55
rm_workor rather02:55
rm_workmine takes care of the issue02:55
rm_workand then the cloud-init config overwrites it maybe after that?02:55
rm_workit seems like my VMs do initial networking *before* cloud-init runs or something <_<02:56
openstackgerritMerged openstack/neutron-lbaas master: Octavia Proxy Plugin  https://review.openstack.org/41853002:58
openstackgerrithuangshan proposed openstack/octavia master: Check if it is used when creating a load balancer using vip_port_id  https://review.openstack.org/52506903:01
*** tongl has quit IRC03:02
dayouDuring runtime, it will generate /etc/network/interfaces.d/50-cloud-init.cfg on ubuntu.03:26
*** annp has joined #openstack-lbaas03:37
*** cody-somerville has quit IRC03:44
openstackgerritHengqing Hu proposed openstack/octavia master: ignore api-ref/build directory  https://review.openstack.org/52238503:44
openstackgerritHengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059003:53
*** links has joined #openstack-lbaas03:58
*** links has quit IRC04:01
*** links has joined #openstack-lbaas04:01
sapd_hi rm_work, I think we should use context of user (who create a LB) instead of admin user when create listener, because only this user can get the secret,.04:05
*** cody-somerville has joined #openstack-lbaas04:07
*** yamamoto has joined #openstack-lbaas04:12
rm_worksapd_: that will work short term, but not long term04:31
rm_worksapd_: on a failover we won't have that user context04:31
rm_workBUT we can use that user context to set up the ACLs ourselves, which is a trick that we've discussed as a possibility04:32
sapd_But, when use admin user, the worker can't get the secret.04:32
rm_workit can if you set up the ACLs as the user04:32
sapd_we have to set ACL for admin user04:32
rm_workor if you set up the octavia service user as a barbican Admin04:32
rm_workyes04:32
sapd_barbican admin is scoped in project, so we have to set that in all projects04:33
rm_workyou can set up barbican to have a global secret viewer role04:33
rm_workand give that to octavia04:33
rm_workit's not a GOOD idea, but it's possible, and then you don't need ACLs04:33
rm_workbut really we recommend ACLs04:33
*** annp has quit IRC04:41
*** annp has joined #openstack-lbaas04:42
sapd_normally, normal user do not know about admin user-id04:45
*** sapd_ has quit IRC04:48
*** sapd has joined #openstack-lbaas04:50
*** threestrands has joined #openstack-lbaas05:09
*** threestrands has quit IRC05:09
*** tongl has joined #openstack-lbaas05:14
*** Alex_Staf has joined #openstack-lbaas05:17
*** csomerville has quit IRC05:22
*** csomerville has joined #openstack-lbaas05:23
rm_worksapd: it's true :/05:24
rm_worksapd: we were recommending you document it <_<05:24
rm_workor considering making an API call to expose it05:24
rm_workBUT, i think the better option is modifying the barbican driver to do the ACLs for you05:24
rm_workwhich ... maybe I will do tomorrow05:24
rm_workand you can test the patch :P05:24
*** csomerville has quit IRC05:28
*** csomerville has joined #openstack-lbaas05:28
*** SumitNaiksatam_ has quit IRC05:31
sapdrm_work, what patch? please show me! :D05:40
*** yamamoto_ has joined #openstack-lbaas05:50
*** yamamoto has quit IRC05:53
*** tongl has quit IRC05:56
*** yamamoto has joined #openstack-lbaas06:04
*** AlexeyAbashkin has joined #openstack-lbaas06:07
*** yamamoto_ has quit IRC06:07
*** AlexeyAbashkin has quit IRC06:11
*** AlexeyAbashkin has joined #openstack-lbaas06:12
*** salmankhan has joined #openstack-lbaas06:20
*** salmankhan has quit IRC06:24
*** AlexeyAbashkin has quit IRC06:26
*** gcheresh has joined #openstack-lbaas06:30
openstackgerritSanthosh Fernandes proposed openstack/octavia master: [WIP] L3 ACTIVE-ACTIVE Data model impact  https://review.openstack.org/52472206:37
openstackgerritOpenStack Proposal Bot proposed openstack/octavia-dashboard master: Imported Translations from Zanata  https://review.openstack.org/52590806:54
*** rcernin has quit IRC07:02
*** csomerville has quit IRC07:10
*** tongl has joined #openstack-lbaas07:21
*** dokua has quit IRC07:24
*** dokua has joined #openstack-lbaas07:38
*** rcernin has joined #openstack-lbaas07:39
*** yamamoto_ has joined #openstack-lbaas07:42
*** yamamoto has quit IRC07:46
*** kobis has joined #openstack-lbaas07:46
openstackgerritHengqing Hu proposed openstack/octavia-dashboard master: Catch up with horizon framework  https://review.openstack.org/52324907:54
*** dokua has quit IRC08:02
*** tongl has quit IRC08:06
openstackgerritHengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059008:06
*** mnaser has quit IRC08:08
*** mnaser has joined #openstack-lbaas08:11
*** tesseract has joined #openstack-lbaas08:19
*** AlexeyAbashkin has joined #openstack-lbaas08:32
*** AlexeyAbashkin has quit IRC08:38
oansonrm_work, nmagnezi, my patch from yesterday passes gate ( https://review.openstack.org/#/c/525504/ ). And I can't move to pure octavia at the moment ( https://bugs.launchpad.net/kuryr-kubernetes/+bug/1736677 ).08:44
openstackLaunchpad bug 1736677 in kuryr-kubernetes "Add native Octavia driver to support k8s services" [Undecided,New]08:44
oansonAny thoughts on how to proceed?08:44
*** AlexeyAbashkin has joined #openstack-lbaas08:44
rm_workhmmm, i wonder what is different08:45
rm_worknothing should be required to "support the native API"08:45
rm_workit's the same API08:45
rm_workit should "just work"08:45
rm_worki don't remember why the port was disabled to begin with08:45
rm_workwe can ask tomorrow during the meeting if there is time08:46
oansonAs part of this bug, we'll debug my environment to see why it fails.08:46
oansonI am hoping this can be merged as a temporary workaround08:46
nmagnezioanson, will look into that flow08:47
oansonnmagnezi, rm_work, thanks!08:47
nmagnezimade a comment in the patch08:47
nmagneziI wonder why it's created like that in the first place08:47
nmagnezithere must be a reason..08:47
rm_workmaybe08:47
rm_workjohnsom MIGHT know08:47
rm_workI definitely don't08:47
nmagnezirm_work, o/08:47
rm_worki/08:48
nmagnezithat's a new one.. :D08:48
rm_worklol bedtime for me08:48
nmagnezithe dot is the head? :D08:48
oansonnmagnezi, I think admin_state_up is set to True in the HAProxy agent, when it 'binds' the port08:48
rm_workthe dot is me being tired and missing the 'o' key08:48
oansons/binds/plugs/08:48
*** AlexeyAbashkin has quit IRC08:49
rm_workhonestly, my care level for neutron-lbaas is rapidly approaching zero -- i don't know if diving into this too deeply is really worth it, if your patch passes devstack gates, that's good enough for me <_<08:49
*** b_bezak has joined #openstack-lbaas08:49
rm_workwe'll poke people about it tomorrow in the meeting though08:49
rm_workbut you REALLY should look at just switching off n-lbaas to octavia if possible08:49
oansonrm_work, that's a must. I'm guessing neutron-lbaas will be deleted once deprecation period is over.08:50
rm_workyes, though deprecation period hasn't technically started yet08:50
rm_workwe're hoping to mark it deprecated in Queens08:51
oansonAh. I thought it was done in pike08:51
nmagnezirm_work, some ppl still care. we'll get more ppl onboard with Octavia as soon as we add providers support08:51
rm_workbut yeah, you really shouldn't wait, neutron-lbaas is a pile of cobbled together junk IMO <_<08:51
nmagneziwhich I hope will happen as soon as possible08:51
rm_workyes, it's only held together because we need to support providers08:51
nmagnezibecause indeed n-lbaas is on life support atm08:51
rm_workand until we do, it's the only option08:51
nmagnezioanson, how do you use LBaaS exactly? Octavia as an endpoint or as a provider for n-lbaas ?08:54
oansonnmagnezi, I don't know - I am using Kuryr, which calls octavia/lbaas API08:54
oansonI am just trying to support the Dragonflow end.08:54
oansonWhich is the actual wiring to the amphora VMs08:55
nmagnezioanson, dragonflow is an interface driver for Neutron? how does it come into play here?08:55
nmagnezisorry I don't know this project08:55
oansonDragonflow is a Neutron backend - it implements the Neutron API (L2, L3, trunk, etc.)08:56
*** yamamoto_ has quit IRC08:56
nmagnezioanson, so it completely replaces ML2+OVS, right?08:56
oansonYes08:56
numansnmagnezi, Hi, the patch to add OVN driver in lbaas v2 is ready with test cases - https://review.openstack.org/#/c/510921/. Could you please add this to your review queue :)08:57
nmagnezioanson, so aside from a wiring for Octavia's health-manager (which you'll need to do by yourself in dragonflow), I don't think there is something to hold you  back from using Octavia as a separate endpoint08:58
oansonTrue. Only Dragonflow doesn't call Octavia directly08:58
nmagnezioanson, maybe it's time to update dragonlow to use the Octavia client ? :)08:59
nmagnezinumans, np! :-)08:59
oansonnmagnezi, my meaning was, Dragonflow doesn't call LBaaS API at all08:59
*** dokua has joined #openstack-lbaas08:59
numansnmagnezi, thanks08:59
oansonThis is all done via Kuryr, and Kuryr will update the API calls (hence the bug)08:59
*** yamamoto has joined #openstack-lbaas09:04
*** dokua has quit IRC09:04
openstackgerritSanthosh Fernandes proposed openstack/octavia master: Adding exabgp-speaker element to amphora image  https://review.openstack.org/49016409:07
*** AlexeyAbashkin has joined #openstack-lbaas09:14
*** aojea has joined #openstack-lbaas09:56
*** dokua has joined #openstack-lbaas10:01
*** yamamoto has quit IRC10:05
*** dokua has quit IRC10:05
*** yamamoto has joined #openstack-lbaas10:08
*** salmankhan has joined #openstack-lbaas10:10
*** yamamoto has quit IRC10:13
openstackgerritOmer Anson proposed openstack/octavia master: Set VIP port to be enabled  https://review.openstack.org/52601910:13
*** annp has quit IRC10:14
*** bar_ has joined #openstack-lbaas10:24
*** eN_Guruprasad_Rn has joined #openstack-lbaas10:48
*** bar_ has quit IRC10:50
openstackgerritHengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059010:52
*** yamamoto has joined #openstack-lbaas11:01
*** dokua has joined #openstack-lbaas11:02
*** dokua has quit IRC11:06
*** aojea_ has joined #openstack-lbaas11:17
*** aojea has quit IRC11:17
*** yamamoto has quit IRC11:19
openstackgerritCarlos Goncalves proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876711:21
*** links has quit IRC11:34
*** rcernin has quit IRC11:39
*** dokua has joined #openstack-lbaas11:42
*** bar_ has joined #openstack-lbaas11:45
*** kobis has quit IRC11:47
*** links has joined #openstack-lbaas11:48
*** kobis has joined #openstack-lbaas11:50
*** dindin has joined #openstack-lbaas11:52
*** dindin has left #openstack-lbaas11:52
*** AlexeyAbashkin has quit IRC11:58
*** pseudo_ has joined #openstack-lbaas12:01
*** openstackgerrit has quit IRC12:03
*** yamamoto has joined #openstack-lbaas12:05
*** links has quit IRC12:08
*** pseudo_ has quit IRC12:12
*** links has joined #openstack-lbaas12:13
*** openstackgerrit has joined #openstack-lbaas12:21
openstackgerritCarlos Goncalves proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876712:21
*** eN_Guruprasad_Rn has quit IRC12:21
*** issp has quit IRC12:26
openstackgerritCarlos Goncalves proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876712:31
openstackgerritOmer Anson proposed openstack/octavia master: Set VIP port to be enabled  https://review.openstack.org/52601912:45
*** AlexeyAbashkin has joined #openstack-lbaas12:46
*** b_bezak has quit IRC12:48
*** salmankhan has quit IRC12:49
*** salmankhan has joined #openstack-lbaas12:51
*** tesseract has quit IRC12:53
*** tesseract has joined #openstack-lbaas12:57
openstackgerritCarlos Goncalves proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876712:57
*** links has quit IRC13:23
*** eN_Guruprasad_Rn has joined #openstack-lbaas13:28
*** eN_Guruprasad_Rn has quit IRC13:43
openstackgerritHengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images  https://review.openstack.org/52059013:49
*** dayou has quit IRC13:58
*** b_bezak has joined #openstack-lbaas14:01
*** dayou has joined #openstack-lbaas14:06
*** sanfern has quit IRC14:06
*** fnaval has quit IRC14:07
openstackgerritBar RH proposed openstack/python-octaviaclient master: Extend loadbalancer_create valid VIP parameters combinations  https://review.openstack.org/51943914:11
*** salmankhan has quit IRC14:14
*** armax has quit IRC14:17
*** salmankhan has joined #openstack-lbaas14:27
*** gcheresh has quit IRC14:36
*** tesseract has quit IRC14:37
*** tesseract has joined #openstack-lbaas14:44
*** armax has joined #openstack-lbaas14:49
*** chandankumar has joined #openstack-lbaas14:52
chandankumarHello14:52
chandankumarI am volunteering for tempest plugin split Queens community goal.14:52
chandankumarfor octavia project there are bunch of reviews up https://review.openstack.org/#/q/project:openstack/octavia-tempest-plugin14:53
chandankumaragainst seperated tempest plugin14:53
chandankumarMy query is are we using the new tempest plugin? if yes, then we are planning to remove the intree tempest plugin?14:54
chandankumarjohnsom: hello ^^14:54
*** kobis has quit IRC14:55
*** fnaval has joined #openstack-lbaas14:55
*** issp has joined #openstack-lbaas14:57
*** knsahm has joined #openstack-lbaas15:05
*** knsahm has quit IRC15:17
openstackgerritGerman Eichberger proposed openstack/neutron-lbaas master: Adds the missing stats command and fixes status  https://review.openstack.org/52570415:23
*** knsahm has joined #openstack-lbaas15:30
bar_xgerman_, johnsom, please review the quota patch https://review.openstack.org/#/c/518767/ if you can15:31
*** bzhao has quit IRC15:33
*** bbzhao has quit IRC15:33
*** tongl has joined #openstack-lbaas15:52
*** longstaff has joined #openstack-lbaas15:55
*** ianychoi has quit IRC15:56
*** ianychoi_ has joined #openstack-lbaas15:56
*** ianychoi_ is now known as ianychoi15:57
johnsomchandankumar The answer is yes, but sadly the work has stalled a bit.  We need more reviews and to get that stack of patches straightened out.  So, summary, still in plan, but at risk for queens at the current velocity.16:07
johnsombar_ Thanks!  I will look first thing this morning16:07
chandankumarjohnsom: so new tempest plugin is ready? can we consume in octavia ci?16:08
bar_johnsom, thanks. A little heads up, I currently have merge conflict on the amphora+failover client patch16:09
johnsomchandankumar, not ready yet, in progress.  We have added a gates for it in the plugin project, just not yet in main Octavia.  We need more of that to land.16:09
johnsombar_ that is fine, we can straighten that out later16:09
openstackgerritBar RH proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876716:21
openstackgerritBar RH proposed openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266616:22
*** knsahm has quit IRC16:29
openstackgerritBar RH proposed openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876716:31
openstackgerritBar RH proposed openstack/python-octaviaclient master: Extend loadbalancer_create valid VIP parameters combinations  https://review.openstack.org/51943916:34
*** Alex_Staf has quit IRC16:51
*** AlexeyAbashkin has quit IRC16:54
*** sanfern has joined #openstack-lbaas17:07
johnsombar_ stack@devstackpy27-2:~/devstack$ openstack loadbalancer quota set --loadbalancer 100 admin17:17
johnsomMissing required argument. Requires at least one of: --health-monitor, --listener, --loadbalancer, --member, --listener, --pool17:17
*** eN_Guruprasad_Rn has joined #openstack-lbaas17:17
bar_this is probably my fault17:17
johnsomOh, dang, that isn't master, there is a bad chain17:17
bar_yup17:18
johnsomYeah, master works. I'm going to keep checking that.  I bet the others just need a rebase17:18
bar_https://review.openstack.org/#/c/522666/13 won't rebase automatically17:19
johnsomOk, there is a problem with health monitor.  The output shows "health_monitor" but the command is --healthmonitor17:19
johnsomSame with load_balancer and loadbalancer17:20
bar_ah, I saw that, but I was not sure it is a problem17:20
bar_see quota.inc17:20
johnsomYeah, the output needs to match the params.  People use the output formatting as input into other calls.  Plus it's just confusing17:21
bar_cgoncalves, ^^17:21
*** eN_Guruprasad_Rn has quit IRC17:22
johnsomSince we already have --loadbalancer in another command, let's just drop the underscores here17:23
*** yamamoto has quit IRC17:23
bar_johnsom, How much time do I have to fix the rebase conflict?17:25
johnsomUmm, like now-ish.  An hour?  I'm creating the release patch right now.17:26
johnsomSo we need these things cleaned up as soon as we can as they still need reviews....17:26
bar_johnsom, I'm currently occupied with the rebase. I would suggest string.replace('_','') on rows in all take_action that actually display something in quota.py17:30
johnsomOk, I need to finish setting up this patch, then I will take a look at the quota patch17:31
bar_If by 'this patch' you mean Complement Octavia client with a set of features, then patch 14 is dirty - don't try to fix it.17:32
*** aojea_ has quit IRC17:32
johnsomNo, the release patch17:32
*** aojea has joined #openstack-lbaas17:35
*** aojea has quit IRC17:40
*** salmankhan has quit IRC17:47
openstackgerritBar RH proposed openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266617:49
*** salmankhan has joined #openstack-lbaas17:49
openstackgerritBar RH proposed openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266617:55
*** sshank has joined #openstack-lbaas17:57
cgoncalvesbar_: aaaand we're back to the _ vs - vs oneword :D18:05
bar_cgoncalves, totally. I commented on your patch.18:05
johnsomcgoncalves Ha, welcome to community based development....  So, I want to error on the side of consistency.  Were there other comments?18:06
bar_not from my side18:06
johnsomOk, wasn't sure if I was the lone voicer or....18:06
cgoncalvesbar_, johnsom: at this point, instead of workaround with str.replace and what not, I'd rather suggest going first for the consistency effort and then refresh the quota patch18:07
*** tesseract has quit IRC18:07
bar_cgoncalves, it won't help, because the row names will never match the argument names.18:08
johnsomSo, just make load_balancer->loadbalancer and health_manager->healthmanager ?  That is my proposal as it matches how loadbalancer is in listener output18:08
bar_row names originate from json response, while argument names don't have '_'18:08
bar_(=underscores)18:08
johnsomYeah, this all comes from the oddity of the osc rules I think.  Looking for that.18:10
cgoncalvesthe problem is that we have --loadbalancer(s) args elsewhere than quota. also I think --health_monitor or something, can't remember18:11
johnsomThe guidelines are all here: https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html18:12
cgoncalvesand it should be --load-balancer according to osc guidelines and octavia api expects load_balancer. osc translates automatically --load-balancer to api parameter load_balancer18:12
johnsomBut for now, let's just align them to no '_' then review for consistency in Q318:12
cgoncalvesk18:12
johnsomYeah, it looks like it should be '-'18:13
cgoncalves--loadbalancer and --healthmonitor than18:13
johnsomOk. So we know we need to go to '-'18:13
cgoncalvesto be consistent with existing arguments18:13
cgoncalvesyes18:13
johnsomSo, let's do load-balancer and health-monitor for both the option and the show/list output column name18:13
cgoncalvesI had '-' in early patch sets.. ;)18:13
bar_johnsom, whoever wrote the rules had never had the word "loadbalancer" in mind.18:13
bar_ref: "openstack loadbalancer quota set --load-balancer -1"18:14
*** sshank has quit IRC18:14
johnsomYeah, and everyone has an opinion on that...  ha.  I don't care what it is as long as it's consistent18:14
cgoncalvesjohnsom: so --load-balancer and --health-monitor?18:14
bar_It's impossible to remember both loadbalancer and load-balancer in the same command line18:14
johnsomBoy, all of our output is '_' though.18:15
johnsomYeah, let's be broken but consistent.  'loadbalancer' 'healthmonitor'18:15
bar_johnsom, I still +1 the current patch set. I think that is a fix beyond the quota patch.18:15
johnsomlet me look at what we have again.  Just a second.18:16
johnsomSorry for the last minute research/confusion here.18:16
*** sshank has joined #openstack-lbaas18:16
johnsomYeah, ok. Let's leave what is there18:17
*** salmankhan has quit IRC18:17
bar_+!18:17
bar_+118:17
cgoncalves\o/18:18
*** jniesz has joined #openstack-lbaas18:18
bar_https://review.openstack.org/#/c/519439/ needs +Workflow18:18
johnsomcgoncalves FYI, we don't use DocImpact anymore.  The docs are all in the repo now so the doc updates should be part of the patch.  This was a recent change by the docs team.18:19
bar_xgerman_, thx18:19
*** sshank has quit IRC18:19
xgerman_yeah, johnsom wants to release ;-)18:19
cgoncalvesjohnsom: understood18:20
bar_https://review.openstack.org/#/c/522666 is still not good, I will rebase it once those two get merged18:20
johnsomYou can't rebase now?18:20
bar_It had rebase conflict before, currently its parent is master18:21
johnsomWould you like me to rebase it for you?18:21
bar_I can do it if it is needed18:21
bar_or you could, I don't care18:21
*** sshank has joined #openstack-lbaas18:22
johnsomGive me a minute.  I would like to get that in too18:22
bar_I thought it would be more robust to wait for the last patch set of the other two patches, instead of dealing with more conflict18:22
johnsomIt was all working18:22
bar_stats patch broke it earlier today18:23
bar_it had a lot of similar code at the very same files.18:23
*** yamamoto has joined #openstack-lbaas18:24
bar_the current patch set is the product of manual rebase ontop of master18:24
rm_workoanson: i just don't understand what "updates" to the calls need to happen. The API should be 100% backwards compatible. You should just have to switch the URL you're calling18:25
rm_workbar_ / johnsom: usually the solution if you KNOW something else is going to merge first is to just go ahead and rebase it on the end of that chain :)18:28
johnsomRight18:28
johnsomUgh, so it looks like there is a difference in the last patch about the URL path code....18:29
bar_sorry, I didn't have a clue it's going to rebase before mine. stats is more recent...18:29
bar_*to rebase = to merge18:29
*** yamamoto has quit IRC18:30
bar_johnsom, are you referring my patch?18:31
johnsomYeah, you have the right prefix, the quota patch doesn't but somehow gets it????18:32
johnsomAh, you change them all18:33
openstackgerritMerged openstack/python-octaviaclient master: Add Quota client API and OSC support  https://review.openstack.org/51876718:42
openstackgerritMerged openstack/python-octaviaclient master: Extend loadbalancer_create valid VIP parameters combinations  https://review.openstack.org/51943918:46
bar_on it.18:47
rm_workok what's our priority merge list?18:48
rm_workdo we have one put together?18:48
rm_workI have a little bit before lunch/meeting18:48
rm_work(or, possibly lunch after the meeting...)18:48
johnsomrm_work We are done except for this last client patch I am rebasing/fixing tests.  It will need a review/test18:49
rm_workk18:50
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266618:50
johnsomThis is the rebase ^^^18:50
johnsomBut it has some test issues to fix, working on those18:50
openstackgerritMichael Johnson proposed openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266618:53
bar_johnsom, thx18:59
openstackgerritSanthosh Fernandes proposed openstack/octavia master: [WIP] L3 ACTIVE-ACTIVE Data model impact  https://review.openstack.org/52472219:00
*** sshank has quit IRC19:00
johnsombar_ NP, can you give it a quick scan and make sure nothing jumps out at you?19:02
johnsomIt seems to work for me.19:02
*** sanfern has quit IRC19:02
bar_yeah, I'm testing it right now19:02
* rm_work improves test coverage19:09
nmagnezithis channel is becoming crowded19:10
rm_worki wonder if it's possible to tweak coverage gate not to check the coverage compared to some static number, but just to check ... if coverage has gone down19:10
nmagnezime like :)19:10
rm_workyeah we're doing pretty well compared to a lot of channels honestly >_>19:10
rm_workit's nice for us, sad for them maybe19:10
*** sshank has joined #openstack-lbaas19:11
nmagnezithey are invited to join our little corner in openstack :)19:11
*** leitan has joined #openstack-lbaas19:14
*** yamamoto has joined #openstack-lbaas19:26
openstackgerritAdam Harwell proposed openstack/octavia master: Move loading the network driver into the flows  https://review.openstack.org/52579019:29
rm_workxgerman_: ^^ that should make you happy19:29
rm_workcoverage++19:30
*** yamamoto has quit IRC19:31
*** harlowja has quit IRC19:32
xgerman_aweet19:33
xgerman_sweet19:33
rm_workgot the test you wanted and fixed coverage for most of the rest of that file :) thanks for the +219:34
*** harlowja has joined #openstack-lbaas19:36
bar_https://review.openstack.org/#/c/522666/18 lgtm19:38
bar_johnsom, nmagnezi, rm_work, xgerman_ ^19:39
xgerman_rm_work thanks19:40
xgerman_bar_ it looks we have some stats command in that without mention ing it in the commit message -19:42
xgerman_johnsom should we let that slide or…19:42
bar_xgerman_, stats is another patch, that's just rebase.19:43
johnsomxgerman That came in from the stats patch parent19:43
xgerman_k, *grumble* can’t we do better rebases…19:43
*** sshank has quit IRC19:44
johnsomI think you mean can't gerrit do a better job a distinguishing parent patches19:45
xgerman_^^ that19:45
openstackgerritBar RH proposed openstack/octavia master: Fail-proof VIP deallocation task  https://review.openstack.org/52393119:49
*** Kowsalya has joined #openstack-lbaas19:57
openstackgerritAdam Harwell proposed openstack/octavia master: Amphora API Failover call  https://review.openstack.org/52577819:57
*** leitan has quit IRC19:59
rm_work^^ not sure why this was rebased to begin with19:59
*** leitan has joined #openstack-lbaas19:59
johnsom#startmeeting Octavia20:00
openstackMeeting started Wed Dec  6 20:00:15 2017 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: Octavia)"20:00
openstackThe meeting name has been set to 'octavia'20:00
*** b_bezak has quit IRC20:00
johnsomHi folks!20:00
cgoncalveso/20:00
nmagnezio/20:00
longstaffhi20:00
rm_worko/20:00
bar_hi20:00
johnsom#topic Announcements20:00
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"20:00
*** b_bezak has joined #openstack-lbaas20:00
jnieszhi20:01
johnsomOn the top of the announcements list is the milestone 2 release for queens.20:01
johnsomI will be posting our release patch right after the meeting20:01
xgerman_o/20:01
johnsomThank you to everyone for the great work that has gone into this patch!20:01
xgerman_+120:02
johnsomWell, milestone I guess.20:02
rm_workyeah, we still have until Q-3 to finish up remaining features20:02
xgerman_next  last milestone is in 6 weeks!20:02
johnsomThis means, we are in the last segment before feature freeze at milestone 3.20:02
johnsomFeature freeze for milestone 3 is Jan 2220:03
nmagnezii wish we'll get the specs in before that milestone20:04
johnsomWe have a lot of stuff in-flight, so please review patches and vote.20:04
johnsomI certainly hope so...20:04
*** leitan has quit IRC20:04
rm_workit'd have to be specs AND code, no?20:04
rm_workto make Queens20:04
xgerman_yep, code20:04
johnsomWe can still merge specs,20:04
xgerman_+120:04
xgerman_I think they got a bit more relaxed with keeping specs rolling20:05
*** b_bezak has quit IRC20:05
nmagnezi+200 rm_work , but we need those in first.. trying to to be greedy here :)20:05
rm_workheh20:05
johnsomAlso note, the PTG in Dublin is open for registration and the hotel block is available.20:06
johnsomAny other announcements today?20:06
johnsom#topic Brief progress reports / bugs needing review20:07
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"20:07
jniesz#link https://review.openstack.org/#/c/519509/20:07
johnsomI have been working on the driver spec.20:07
johnsom#link https://review.openstack.org/50995720:08
jnieszlooks like we are close on that one, just need one more core : ) Looks at rm_work20:08
johnsomI would like to see some reviews on the QoS patch:20:08
johnsom#link https://review.openstack.org/45830820:08
johnsomThat should pretty much be done.20:08
xgerman_okey20:09
johnsomWe also have a UDP protocol spec in flight that can use some reviews:20:09
johnsom#link https://review.openstack.org/50360620:09
xgerman_#link https://review.openstack.org/#/c/525704/ - watch that space20:09
rm_workyeah i've been having some crazy internal fires, but that just wrapped up ... if someone compiles a list of patches ordered by priority, I will work down the list, otherwise I'll just pick random stuff from this meeting's links I guess20:10
johnsomI have put in the community goals update patch for the tempest plugin (we need to report for MS2).  Those could use some love as well.20:10
johnsomrm_work I will try to put something together20:11
johnsomAny other updates?20:12
nmagnezi+1 , such list would be great to have20:12
jniesz+1 same20:12
johnsomOk, we have a list of other topics on the agenda.  I will go down the list and ask the requester to speak to them.20:13
johnsom#topic (BAR_RH) Members API Improvements Proposal20:13
*** openstack changes topic to "(BAR_RH) Members API Improvements Proposal (Meeting topic: Octavia)"20:13
bar_k20:13
bar_Currently the URL for members show is: rest_method:: GET /v2.0/lbaas/pools/{pool_id}/members/{member-id}20:13
bar_Why not allow to address a member WITHOUT POOL_ID. e.g.: GET /v2.0/octavia/members/{member_id}20:13
bar_That's my proposal pretty much, since member_id is unique20:14
cgoncalves+120:14
xgerman_so basically that saves people from writing tow ids? Or is there another benefit?20:15
rm_workyeah honestly i have been wondering this20:15
johnsomWould it be for a situation where members are shared?20:15
rm_worki think we were considering shared members20:15
nmagnezi#link https://storyboard.openstack.org/#!/story/200131720:15
rm_work^^ yeah that20:15
rm_workbut, our DB model doesn't work for that20:15
johnsomThis decision pre-dates me on the project, so I don't have the historical reasoning20:15
nmagneziI'm in favor of that. but on the other hand I also submitted the story..20:15
rm_worksince it puts pool_id directly in the member table schema20:15
rm_worksooooo20:15
rm_workthis is really a shared-members discussion i think20:16
rm_workschema is easier to change than API20:16
rm_workif we change the API, we're stuck20:16
*** Kowsalya has quit IRC20:16
johnsomWell, for backward compatibility we need to retain the current API path.20:16
xgerman_+120:16
nmagnezirm_work, If members would be shared between the pools we'll need to think about this a bit more. for example an ability to get a list of pool the member is a part of etc20:17
nmagnezii agree with johnsom here20:17
bar_The new API must allow list in the field of pool_ids.20:18
openstackgerritMerged openstack/python-octaviaclient master: Complement Octavia client with a set of features  https://review.openstack.org/52266620:18
bar_if shared-members is an option.20:18
bar_yay!20:18
xgerman_well, the other problem I see is that we treat members as part of the pool and delete them with the pool20:18
nmagnezibar_, awesome job on ^^ :)20:19
bar_nmagnezi, thx20:19
nmagnezixgerman_, right. we actually discussed this in the providers spec review. currently when we delete a pool we cascade and delete members20:20
nmagneziand I think also health monitors20:20
cgoncalvesis there anyone we could ask the historical reasoning for pool_id in GET member?20:20
rm_workumm20:21
rm_workme, johnsom, xgerman_20:21
nmagnezicgoncalves, git log ? :D20:21
rm_worksbalukoff_ :P20:21
rm_workwe made the spec as-is20:21
nmagnezidougwig :P20:21
rm_workyes, heh20:21
cgoncalveshaha!20:22
rm_workdougwig but he is not here for me to highlight T_T20:22
johnsomWe could try to reach out to folks, but most everyone is not on OpenStack anymore.  I think xgerman_ might be the only person that was in Atlanta when that API was designed.20:22
rm_work<<---20:22
rm_workjohnsom: weren't you also?20:22
johnsomNope20:22
johnsomBefore my time20:22
rm_workyeah xgerman_ and me and sbalukoff_ and jorgem20:22
rm_workand dougwig and ...20:22
rm_workevgeny and sam20:22
rm_worki am pretty sure it was for future shared members20:23
cgoncalvesok, they all have got a notification on their irc clients. hopefully they will shed some light later20:23
rm_worki think that's the only reason20:23
rm_workjust sbalukoff_ and i doubt it :P20:24
nmagnezii think that even if we don't get a reply about this, there's a value of looking at this with fresh eyes and decide about it20:24
rm_workso let's table that and call it "Shared Members? Yes/No/Abort/Retry/Fail"20:24
nmagnezirm_work, not sure this is what bar_ had in mind :D20:25
cgoncalvesnmagnezi: +120:25
rm_workYes, but that's what the core of the discussion is20:26
bar_I am aware of that notion, and my API should be established in light of new notion like shared-members.20:26
rm_work"Can we drop the pool-id on the member lookup" equates to "are we going to drop the idea of shared members"20:26
johnsomOk.  Let's think about issues around shared members. (The only reason it matters is to limit multiple health monitors from pinging the members)20:26
rm_workbut, the HMs on different pools may be different ...20:26
rm_worksoooo20:26
rm_workhonestly i think that doesn't even matter20:27
rm_workthey SHOULD all do their own pings20:27
johnsomI think we can consider *adding* a direct member query API.  That might be independent of shared members.20:27
rm_workk. that's a larger discussion we can have offline20:27
rm_workour agenda today is packed20:27
johnsomYep.20:27
nmagnezijohnsom, nothing prevents a user from adding the IP address as a pool member for two different pools, right?20:27
*** yamamoto has joined #openstack-lbaas20:27
johnsombar_ Are you good with the discussion progress so far?  Can we table it?20:27
nmagneziit's just a different member object20:27
rm_workright20:28
johnsomRight20:28
rm_workthe question was do we bother making member objects shared20:28
rm_worki actually vote "no"20:28
rm_workcomplication is not worth the return20:28
johnsomYeah, it gets pretty messy with different protocol pools, etc.20:28
*** beagles has joined #openstack-lbaas20:28
bar_let's continue offline them20:28
bar_*then20:28
*** alee has joined #openstack-lbaas20:28
johnsom#topic (sanfern / rm_work) Changes to DB schema for VRRP ports20:28
*** openstack changes topic to "(sanfern / rm_work) Changes to DB schema for VRRP ports (Meeting topic: Octavia)"20:28
aleerm_work, yo20:29
johnsom#link https://review.openstack.org/#/c/521138/20:29
*** salmankhan has joined #openstack-lbaas20:29
jnieszI am covering for sanfern, since it is 2 am for hi20:29
jnieszm20:29
jnieszthis is from the discussion we had at the PTG about changing the vrrp_ table names20:29
rm_workyeah, i agree with the goal, i love it20:29
rm_workbut20:29
rm_workis this a smart thing to do on the DB-schema side?20:29
rm_workshould we maybe just change the models and leave it at that?20:30
rm_workthe repos can do the translation20:30
aleerm_work, hey --- I think I asked this before but you were out -- is there a doc to describe how to set up octavia with barbican?20:30
rm_workalee: yes -- but hold on, middle of our meeting :P20:30
jnieszI remember the reason was to make it obvious since vrrp was already bad naming and when the user looks in db20:30
aleerm_work, oops sorry :)20:30
*** xgerman_ has quit IRC20:31
*** fyxim has quit IRC20:31
*** kong has quit IRC20:31
*** ianychoi has quit IRC20:31
*** ptoohill- has quit IRC20:31
*** devfaz has quit IRC20:31
johnsomI think there are two issues here:20:31
johnsom1. Admin API output change for amphora field change.20:31
johnsom2. The change to the underlying database schema which would require a full control plane downtime.20:31
rm_work^^ I am concerned about #220:31
rm_workI think even as deep as the Models it would be good to change this stuff20:32
rm_workbut I think between schema/repo we should leave it20:32
rm_workif that's possible20:32
johnsomOn #1, I'm not so concerned about this.  The paint hasn't dried on that admin API patch and we haven't shipped a release with it yet.20:32
rm_workor, i could be wrong20:32
*** yamamoto has quit IRC20:32
rm_workand maybe no one cares about the db schema change20:32
rm_workif all of you guys think it's OK, then I guess that's fine20:32
jnieszfor #2 I think control plane going down for short period of time for planned maintenance upgrade is ok20:33
johnsomIf people are coding directly to the database, shame on them.  I have no problem breaking that.20:33
*** salmankhan has quit IRC20:33
johnsomThe issue comes down to a control plane outage for upgrade right?20:33
rm_workyeah20:34
johnsomDid we drop everyone?  There is a netsplit...20:34
jnieszi'm still here20:34
rm_workand i just seriously thought there were openstack guidelines around db schema changes20:34
nmagnezii'm still here20:35
johnsomOk, cool.20:35
*** aojea has joined #openstack-lbaas20:35
nmagnezii think xgerman got disconnected20:35
jnieszhaven't we had to do schema changes in the past?20:35
johnsomWell, for upgrade downtime there are assertions a team can make and get a governance tag. However, we have not yet made that assertion.20:35
johnsomjniesz So far we have only done additions, no renames20:36
rm_workyeah, no renames or removals20:37
rm_workyet20:37
jnieszwell there is always a time for being first20:37
jniesz: )20:37
rm_workbasically20:37
rm_work#vote?20:37
rm_workI'll abstain20:37
johnsomTo me, as long as we maintain the API and provide a migration path, I don't have a problem with it as we have not asserted rolling upgrade or zero downtime upgrade yet.20:38
johnsomPlease don't abstain, your vote counts.  Especially as you have this deployed.20:38
rm_workright but20:38
jnieszfrom my standpoint I think the naming makes more sense, and we started this patch based on feedback from the PTG20:38
rm_worki would vote no20:38
rm_workbut20:38
rm_worki don't care so much20:38
rm_workah i guess it makes sense just to vote that way, since we don't need unanimity20:39
jnieszwith active/active I think vrrp naming makes less sense than it does now20:39
rm_workit already makes no sense20:39
rm_workmy objection has nothing to do with the renaming20:39
*** aojea has quit IRC20:39
rm_worki am a huge fan :P20:39
nmagneziI feel like i don't know enough about this (sorry for some reason that patch slipped my radar). so maybe I'm the one who needs to abstain20:39
johnsomThe other option is to do a two phase upgrade, one that adds and clones the field, then the operation updates the control plane, then one that removes the old field.20:39
johnsomShould we table this for a week and put it on the next agenda so everyone has time to review?20:40
rm_workmeh20:40
rm_workyeah we have time20:40
rm_workit'll go in quick once we decide, so20:40
rm_worknot super worried20:40
jnieszwould like to get this merged or decided as it has a lot of depen20:41
johnsomOk, we will vote next week about the DB schema change.20:41
jnieszfor example adding frontend network option20:41
rm_workthe vote would be20:41
jnieszin a way it is holding us up from proceeding on other items20:41
rm_work"can we rename fields in our db schema"20:41
rm_workdon't really need to review the specific patch20:41
rm_workif you know your answer to that question nir20:42
johnsomjniesz I would move forward with what you have.  The changes based on this vote should be very minimal.  Every access to the DB has to go through the abstraction layer.20:42
johnsomOk, in the interest of time:20:43
johnsom#topic (rm_work / BAR_RH) Specify management IP addresses per amphora20:43
*** openstack changes topic to "(rm_work / BAR_RH) Specify management IP addresses per amphora (Meeting topic: Octavia)"20:43
johnsom#link https://review.openstack.org/#/c/505158/20:43
jnieszbut any patches for the abstraction layer would get impacted20:44
jnieszthat touched those tables20:44
bar_rm_work?20:44
rm_workSo, there's another approach for this20:44
johnsomjniesz Adding the option would use the abstraction which I don't think is in question here, just what is behind the abstraction20:44
rm_workthat I think is better than mucking with the flows and the actual logic we use20:45
rm_work(also it is true that pre-creating that port is problematic for my install)20:45
rm_workso yes I have a vested interest here20:45
johnsomThis has a long history....  It pre-dates the network namespace and was blocked by the old agent framework being broken.20:45
rm_workthe issue is basically "we want to bind the agent on the amp to the mgmt-ip directly and not listen on 0.0.0.0"20:46
rm_workthe problem is that we need to send the config for the agent at boot time, which is before the IP is assigned20:46
rm_workand there's no way to update it20:46
rm_workSO20:46
*** xgerman_ has joined #openstack-lbaas20:47
*** fyxim has joined #openstack-lbaas20:47
*** kong has joined #openstack-lbaas20:47
*** barjavel.freenode.net changes topic to "(BAR_RH) Members API Improvements Proposal (Meeting topic: Octavia)"20:47
johnsomWe need a config update method, that is for sure.20:47
rm_workthe current solution is: pre-generate the port/IP for the mgmt interface, and bind it on amp boot, so we can send the IP in the pre-generated config20:47
*** ianychoi has joined #openstack-lbaas20:47
*** ptoohill- has joined #openstack-lbaas20:47
*** devfaz has joined #openstack-lbaas20:47
rm_workmy proposal is that we do something simpler that requires a feature we want anyway: add the ability to send an updated config to the amp agent, and then we simply start on 0.0.0.0 and the first connection (which we are trying to do anyway) just sends a new config20:48
rm_workand it restarts on the right interface20:48
xgerman_and I am bacl20:48
rm_workwelcome back xgerman_20:49
nmagnezirm_work, to be frank, i see the binding to 0.0.0.0 as a potential security concern20:49
johnsomrm_work for my background, what is the problem with pre-building the port?20:49
rm_workoh ptoohill was also there in Atlanta IIRC :P20:49
cgoncalvesrm_work: couldn't another approach be leveraging cloud-init? I'm not certain but I guess we can get the IP at that phase and before configuring the agent20:49
rm_workcgoncalves: hmmm I am not sure -- that's an interesting question20:50
rm_workthat could be a better approach than either of the ones i mentioned20:50
xgerman_pretty sure the computer knows it’s IP on the mgmt port20:50
nmagnezirm_work, can't we both listen to a specific ip address and have the config updates you mentioned?20:50
johnsomYeah, there might be an option to have cloud-init set that setting in the config file20:50
rm_worknmagnezi: A) that's what we do now; B) We booted the amp, so it only HAS interfaces we told it to have at boot; C) we still do two-way-cert-auth20:50
johnsomWell, right now it binds to 0.0.0.020:51
rm_workright20:51
johnsomin the default namespace20:51
rm_workso we can have it bound to 0.0.0.0 for all of like .... 1 second20:51
rm_workbecause we're literally polling the address to reach the amp agent20:51
rm_workand if someone else managed to get there first and rebind it somewhere else... who cares, it's a blank amp, and we'll kill it momentarily anyway once we timeout (since our calls won't reach it)20:52
nmagnezibtw that option for amphora agent ip bind also shows at octavia.conf , which does not make any sense. just a side note.20:52
rm_worknmagnezi: err really? lol yeah that makes no sense20:52
nmagnezirm_work, yeah. bar_'s patch handles that as well20:53
rm_worknmagnezi: where is that20:53
*** Kowsalya has joined #openstack-lbaas20:53
rm_worki actually don't see it20:53
xgerman_sorry being late — we can also use the mgmt subnet instead of 0.0.0.020:53
xgerman_why is that now workable?20:53
xgerman_now=not20:53
rm_workxgerman_: that's what we're talking about -- HOW we do that20:53
johnsomThose options were documented there as "amphora agent only" because they show up in the config settings.  That is why they were there.  people were putting up patches saying they were missing.20:53
xgerman_we know the mgmt subnet before booting the amp so we can just set it in the config? it in20:54
rm_workjohnsom: but i really am not seeing them. where do you see them?20:54
xgerman_teh config20:54
nmagnezirm_work, so to answer you: A) that does not mean we should keep doing that B) indeed. but someone later on could update the instance via nova and add interface with dhcp, no? C) indeed. but that does not mean we still need to accept mgmt traffic on all available addresses.20:54
rm_worknmagnezi: there is no later20:54
nmagnezii don't recall any openstack services who bind to *20:54
rm_workwe're saying we rebind it immediately on boot20:54
rm_work[12:48:07]  <rm_work>my proposal is that we do something simpler that requires a feature we want anyway: add the ability to send an updated config to the amp agent, and then we simply start on 0.0.0.0 and the first connection (which we are trying to do anyway) just sends a new config20:55
*** sshank has joined #openstack-lbaas20:55
rm_work^^ the new config binds it to the right IP20:55
xgerman_so a subnet CIDR is not good enough?20:55
jnieszcan't we pass the IP to bind through config drive, and then it binds on boot /start20:55
xgerman_+120:55
nmagnezirm_work, touche20:56
rm_workxgerman_: how do we use that to set the bind?20:56
rm_workjniesz: right the problem is that we don't know the IP until after the boot command is sent20:56
johnsomxgerman_ You can't listen on a subnet, you can only listen (bind) to an address.20:56
xgerman_I can iptable drop them if I want…20:56
rm_workjniesz: that is exactly the current patch's approach -- which requires it to pre-make the port20:56
rm_workwhich i'd like to avoid20:56
nmagnezijniesz, that's what bar_'s patch is doing20:56
*** tongl has quit IRC20:56
johnsomjniesz Yes, technically that comes in via config drive from nova.  That is the cloud-init option that was proposed earlier20:57
rm_workwe're about to be out of time here and i have a hard-stop in 3min T_T20:57
jnieszor need something in the systemd script to read the IP off the interface20:57
johnsomYeah, me too20:57
rm_workmaybe we need to punt this also20:57
johnsomlol20:57
rm_worksince maybe people need to read the existing patch20:57
rm_workand see what it's doing20:57
nmagnezirm_work, maybe it's just becoming a late hour for me me , but i still didn't get why pre-creating that port is an issue O_o20:58
johnsomOk, I will put these on the next agenda too.  I might re-order for fairness of the other topic we didn't get to.20:58
rm_worknmagnezi: in our environment, we can't specify a network/subnet for VMs20:58
rm_workwe have to let them create their own ports20:58
rm_workso we *can't* pre-create a port and then bind it20:58
nmagneziaha.20:58
rm_workIIRC Cern does something similar20:58
rm_workfrom talking with them before20:59
johnsomYeah, I think there are AZ issues with some deployments like that20:59
rm_workyes20:59
rm_workIMO we *cannot* merge this as it is20:59
johnsomOk, thanks folks!20:59
xgerman_yeah, we should avoid pre-creatign the port in case people do fancy SRV-IO stuff20:59
nmagneziwell. can't say it's not a valid usecase.20:59
rm_worki am just trying to be diplomatic :)20:59
nmagnezirm_work, let's discuss this tomorrow20:59
rm_workkk20:59
johnsomSRV-IO is a good example too20:59
nmagnezimaybw we can figure a middle ground20:59
rm_worki mean20:59
rm_worki think you will be OK with my proposal21:00
jnieszspeaking of SR-IOV that has been giving me headaches with the X71021:00
johnsom#endmeeting21:00
*** openstack changes topic to "Welcome to LBaaS / Octavia - Queens development is now open."21:00
rm_workonce i explain better21:00
openstackMeeting ended Wed Dec  6 21:00:05 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-06-20.00.html21:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-06-20.00.txt21:00
openstackLog:            http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-06-20.00.log.html21:00
rm_worknmagnezi: so yeah, tomorrow :)21:00
nmagnezi:-)21:00
rm_worki'll walk through what i'm talking about better21:00
rm_workbbl21:00
nmagnezisorry, gotta drop21:00
*** harlowja has quit IRC21:00
nmagnezijohnsom, i will take the links list from this meeting as top review priority, until we'll have the extended list21:01
johnsomThanks!21:01
*** Kowsalya has quit IRC21:02
*** harlowja has joined #openstack-lbaas21:03
*** bar_ has quit IRC21:03
*** longstaff has quit IRC21:04
*** Kowsalya has joined #openstack-lbaas21:05
*** tongl has joined #openstack-lbaas21:05
xgerman_caught up - didn’t miss much due to the netsplit21:06
*** Kowsalya has quit IRC21:12
*** gcheresh has joined #openstack-lbaas21:12
*** sticker has joined #openstack-lbaas21:19
*** yamamoto has joined #openstack-lbaas21:28
*** gcheresh has quit IRC21:29
*** bzhao has joined #openstack-lbaas21:30
*** bbzhao has joined #openstack-lbaas21:30
*** harlowja has quit IRC21:32
*** yamamoto has quit IRC21:33
*** aojea has joined #openstack-lbaas21:35
*** AlexeyAbashkin has joined #openstack-lbaas21:38
*** openstackgerrit has quit IRC21:38
*** sri_ has quit IRC21:38
*** bar_ has joined #openstack-lbaas21:39
*** aojea has quit IRC21:41
*** aojea has joined #openstack-lbaas21:45
*** aojea has quit IRC21:46
*** aojea has joined #openstack-lbaas21:46
beaglesis the username and project_name in the service_auth section of the configuration supposed to be that of the admin tenant?21:55
*** leitan has joined #openstack-lbaas22:00
johnsombeagles [service_auth] is the account octavia uses to request resources from other services, such as nova/neutron/barbican.  You can use admin or setup an account for octavia and grant the right RBAC permissions for those service to this account.22:00
beaglesjohnsom, ack thanks22:01
*** openstackgerrit has joined #openstack-lbaas22:01
*** sri_ has joined #openstack-lbaas22:01
*** rcernin has joined #openstack-lbaas22:01
*** rcernin has quit IRC22:03
*** rcernin has joined #openstack-lbaas22:03
*** leitan has quit IRC22:05
bar_johnsom, is the vip deallocation patch is pike-backport material?22:08
johnsomPoint me to which one you are talking about?22:08
bar_https://review.openstack.org/#/c/523931/22:08
johnsombar_ Yes, I think that has the potential once it merges22:09
bar_johnsom, cool. Are there more pike deadlines in the near future, or we're already passed that?22:10
johnsombar_ The schedule for the releases is here: https://releases.openstack.org/22:11
johnsomLooks like Pike goes phase II 2/2622:11
bar_got it. thanks22:11
*** sshank has quit IRC22:20
*** yamamoto has joined #openstack-lbaas22:30
*** aojea has quit IRC22:31
*** longstaff has joined #openstack-lbaas22:32
*** aojea has joined #openstack-lbaas22:33
*** sshank has joined #openstack-lbaas22:34
*** yamamoto has quit IRC22:35
*** harlowja has joined #openstack-lbaas22:36
*** AlexeyAbashkin has quit IRC22:43
openstackgerritBar RH proposed openstack/python-octaviaclient master: Add VIP QoS Policy client support  https://review.openstack.org/52621722:51
*** sshank has quit IRC22:54
*** sshank has joined #openstack-lbaas22:57
*** aojea has quit IRC23:02
openstackgerritBar RH proposed openstack/python-octaviaclient master: Allow case-insensitive enteries when selecting from choices  https://review.openstack.org/52579123:09
rm_workSo what were high priority review items? I am going to take a look at the stuff linked in the meeting now i guess23:19
rm_workwhich are ... none23:20
rm_workoh nm there they are23:20
*** openstack has joined #openstack-lbaas23:31
*** ChanServ sets mode: +o openstack23:31
*** yamamoto has joined #openstack-lbaas23:32
*** yamamoto has quit IRC23:37
xgerman_I think with Q-2 being cut the urgency is diminishing until Q-3 ;-)23:42
xgerman_timed out? https://review.openstack.org/#/c/525704/ — is our gate broken?23:42
xgerman_rm_work as the centos user this looks relevant for you, too: https://review.openstack.org/#/c/522626/23:44
xgerman_wonder why nmagnezi isn’t reviewing that…23:44
*** armax has quit IRC23:45
xgerman_ok, timeout fixed itself23:45
rm_workyeah i am aware of it23:47
rm_worki'll be looking23:47
xgerman_cool - thanks23:47

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!