Thursday, 2018-10-18

*** Swami has quit IRC00:02
*** hyang has joined #openstack-lbaas00:42
*** hyang has quit IRC00:47
*** abaindur has quit IRC01:22
*** Emine has quit IRC01:22
*** Emine has joined #openstack-lbaas01:23
*** Emine has quit IRC02:23
*** hongbin has joined #openstack-lbaas02:29
*** rcernin has quit IRC03:02
*** jarodwl has joined #openstack-lbaas03:21
*** jarodwl is now known as jarodwl_03:23
*** jarodwl_ is now known as jarodwl__03:23
*** jarodwl__ is now known as jarodwl03:24
*** rcernin has joined #openstack-lbaas03:28
*** ramishra has joined #openstack-lbaas03:35
*** hongbin has quit IRC03:57
*** yamamoto has quit IRC04:34
*** yamamoto has joined #openstack-lbaas04:34
*** yboaron_ has quit IRC04:42
*** Emine has joined #openstack-lbaas06:37
*** yboaron_ has joined #openstack-lbaas06:39
*** Emine has quit IRC06:42
*** rcernin has quit IRC07:07
*** celebdor has joined #openstack-lbaas07:14
*** abaindur has joined #openstack-lbaas07:18
cgoncalvesFYI: issue observed often in octavia-v2-dsvm-scenario-centos-7 job should be fixed now thanks to https://review.openstack.org/#/c/609169/07:30
*** openstackgerrit has quit IRC07:35
*** abaindur has quit IRC07:37
*** abaindur has joined #openstack-lbaas07:37
*** abaindur has quit IRC08:09
*** salmankhan has joined #openstack-lbaas08:54
*** salmankhan has quit IRC08:56
*** salmankhan has joined #openstack-lbaas08:56
*** yamamoto has quit IRC10:11
*** yamamoto has joined #openstack-lbaas10:12
*** yamamoto has quit IRC10:16
*** yamamoto has joined #openstack-lbaas10:16
*** yamamoto has quit IRC11:20
*** yamamoto has joined #openstack-lbaas11:21
*** yamamoto has quit IRC11:25
*** yamamoto has joined #openstack-lbaas12:03
*** salmankhan has quit IRC12:11
*** hvhaugwitz has quit IRC12:19
*** hvhaugwitz has joined #openstack-lbaas12:19
*** yamamoto has quit IRC12:20
*** yamamoto has joined #openstack-lbaas12:20
*** yboaron_ has quit IRC12:29
*** yboaron_ has joined #openstack-lbaas12:29
*** dims has quit IRC12:30
*** dims has joined #openstack-lbaas12:33
*** salmankhan has joined #openstack-lbaas12:49
*** sri_ has joined #openstack-lbaas13:00
*** yboaron_ has quit IRC13:47
*** yboaron_ has joined #openstack-lbaas14:09
johnsomNice! The bionic fix also merged, so we should be in better shape14:49
cgoncalveseven better once https://review.openstack.org/#/c/606741/ merges14:51
cgoncalvesjohnsom, re: centos amps not handling multiple subnets, shouldn't centos job fail in that case in https://review.openstack.org/#/c/611405/ ?14:54
*** openstackgerrit has joined #openstack-lbaas14:54
openstackgerritKamil Sambor proposed openstack/octavia stable/queens: Add config option  https://review.openstack.org/61164214:54
johnsomIt did...14:54
cgoncalvesjohnsom, on the last CI run, but not in the previous (same patch set)14:55
cgoncalveshttp://logs.openstack.org/05/611405/3/check/octavia-v2-dsvm-scenario-centos-7/3084583/testr_results.html.gz14:55
johnsomcgoncalves It also might be indeterminate, as the IPv6 address might get plugged on one pass, IPv4 on another.14:56
*** Swami has joined #openstack-lbaas14:56
*** yamamoto has quit IRC15:21
*** yamamoto has joined #openstack-lbaas15:22
*** yamamoto has quit IRC15:26
openstackgerritMerged openstack/octavia-tempest-plugin master: Raise build_timeout from 60 to 300  https://review.openstack.org/60674115:34
*** yboaron_ has quit IRC15:39
*** yamamoto has joined #openstack-lbaas16:11
*** Swami has quit IRC16:21
xgerman_cgoncalves: where are you with our slides?  Usually I dod them on the flight over but it looks like OpenStack wants to style them?16:25
*** yamamoto has quit IRC16:56
*** yamamoto has joined #openstack-lbaas16:56
*** celebdor has quit IRC17:09
cgoncalvesxgerman_, I haven't started yet. we should do it a bit in advance if we want to record a demo17:11
*** ramishra has quit IRC17:11
xgerman_yeah + there is some pressure form the foundation…17:12
*** hyang has joined #openstack-lbaas17:26
*** yamamoto has quit IRC17:33
*** salmankhan has quit IRC17:47
*** fnaval has joined #openstack-lbaas18:11
*** yamamoto has joined #openstack-lbaas18:14
*** salmankhan has joined #openstack-lbaas18:17
*** salmankhan has quit IRC18:23
*** salmankhan has joined #openstack-lbaas18:31
*** salmankhan has quit IRC18:40
openstackgerritMichael Johnson proposed openstack/octavia master: Bring up secondary IPs on member networks  https://review.openstack.org/61146019:06
*** hyang has quit IRC19:23
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Add an active/standby scenario test  https://review.openstack.org/58468119:41
openstackgerritMichael Johnson proposed openstack/octavia master: Remove deprecated API settings  https://review.openstack.org/60081919:42
cgoncalvesis there any task other than the controller.worker.tasks.network_tasks.AllocateVIP that creates the VIP port?20:01
cgoncalvesfor some reason, on a composable role deployment (api running in one node, hm, cw and hk on another), the worker is telling that the VIP was already created so it then tries to GET it from neutron20:03
cgoncalveswhich then fails because it indeed doesn't exist. looking deeper, I see also in worker log that a 198.51.100.1 VIP port was presumably created20:04
xgerman_it’s the only one as I know… but user can post their own port so in that case we would get it from newton20:04
cgoncalves198.51.100.1 is defined in noop_driver. I checked and all services are set to load the AAP driver20:04
cgoncalvesxgerman_, I am passing --vip-subnet-id20:04
xgerman_k, then logs…20:05
cgoncalveshttp://cgoncalves.pt/trash/openstack/octavia/worker-fd6c1976-8294-43f3-8133-2ca948fbbaa8.log20:15
cgoncalvesAllocate_vip port_id 0d662ae9-3e2c-493a-b153-24d2bf3b6b89, subnet_id 900a07fe-90f4-49d7-9185-2699696c5b7b,ip_address 198.51.100.1 execute20:15
cgoncalvessubnet_id is correct one, ip address is not. subnet is 192.168.1.0/2420:16
johnsomThe API creates the VIP, so we can return the assigned IP in the API response20:17
cgoncalvesoh! in that case... :D20:19
cgoncalvesall 3 controllers running o-api do not have network_driver set20:19
johnsomThere you go.... You are getting noop networking20:20
cgoncalvesmixed network drivers, yay!20:20
cgoncalvesjohnsom, confirmed, works now. remind me to pay you whatever is your favorite drink next time ;)20:30
johnsomlol, no worries20:30
cgoncalvessee?! another tripleo assignment for me :/20:32
johnsomJust say no man.... You have more important things to be working on...  Grin20:32
johnsomThere, you have fulfilled your tripleo time for the year, now you can go back to Octavia....20:33
johnsomgrin20:33
cgoncalvesI wish it would work like that20:34
*** salmankhan has joined #openstack-lbaas20:35
*** salmankhan has quit IRC20:35
*** openstackgerrit has quit IRC20:36
*** salmankhan has joined #openstack-lbaas20:36
xgerman_cgoncalves: just make triple o call out to OSA20:39
*** openstackgerrit has joined #openstack-lbaas20:41
openstackgerritGerman Eichberger proposed openstack/octavia master: Refactor the pluggin of the VIP  https://review.openstack.org/60447920:41
*** pcaruana has quit IRC20:44
cgoncalvesxgerman_, not a bad idea. I could then re-assign all bugs to you20:53
xgerman_or johnsom20:54
cgoncalvesactually, in this case, it is an issue in puppet-octavia20:54
cgoncalvesxgerman_, you're my favorite for OSA20:54
xgerman_puppet… the Chief Product Officer there used to be our VP at HP… so if you need me to @him on one of my tweets to compalin20:57
*** abaindur has joined #openstack-lbaas21:01
johnsomI could just drive up the road and pay them a visit....21:07
xgerman_yeah, make them buy you beer :-)21:07
*** abaindur_ has joined #openstack-lbaas22:15
*** abaindur has quit IRC22:18
lxkonghi guys, if the first amp failover failed during the lb failover proces, will octavia continue to do handle the second amp?22:21
lxkongfor stable/queens22:21
*** abaindur has joined #openstack-lbaas22:22
johnsomYes, the secondary amphora will continue to operate and would be failed over should it also fail.22:22
*** abaindur_ has quit IRC22:22
johnsomNote, you may need a current version of Octavia queens for that. I think we back ported the dual-down amp failover fix.22:24
lxkongyeah, i saw that and we met with the issue22:24
lxkongboth amp are gone22:24
lxkongdue to db connection issue22:24
johnsomWe backported a fix for that too22:24
lxkongjohnsom: in that case, it can not be recovered, right?22:25
lxkongthere is no records in amp db table22:25
johnsomIf the amp records got purged, yeah, you have to recreate it22:26
johnsomThis was the db patch: https://review.openstack.org/#/c/602431/22:27
lxkonghmm....22:27
lxkongwe are doomed22:28
johnsomYou have a lot down like that?22:28
lxkongwe have some customers using lb for their production business :-(22:28
johnsomIf you are highly motivated I think there is a way to fake up amp records to get a amp failover to work.22:29
johnsomThe person you want to talk with is not online for a few weeks though.22:30
johnsomLet me think about it for a minute.22:30
lxkongi see we need the old amp information to restore the instance, but it's gone22:32
johnsomYeah, I would try faking up amphora records if you don't have a backup to use22:32
*** rcernin has joined #openstack-lbaas22:33
johnsomSo, do this for the fields: id = new uuid, compute id = new uuid, status = ERROR, lb_id = the load balancer ID you are recovering, lb_network_ip = random IP, vrrp_ip = random IP, ha_ip = the LB VIP IP, vrrp_port_id = random UUID, ha_port_id = try random uuid, role = STANDALONE or one MASTER and one BACKUP, cert_expiration = 2020 date, cert_busy = 0, vrrp_interfance NULL, vrrp_id 1, vrrp_priority Null or 100,22:36
johnsomcached_zone nova22:36
johnsomThen fire a failover22:37
lxkongi'm wondering if it failed for the first amp, why not we stopping the whole failover process for the lb?22:38
johnsomWell, it only fails over an amp if it detects that the amp is failed, so if only one was down, it would have only tried the first and stopped marking it ERROR. However, if the other is detected as failed, it will try it as well.22:39
lxkongwell, when something happened for the db connection, i think it's highly likely that both are marked down22:41
johnsomYeah, it was likely that the DB was unreachable for over 60 seconds (or your failover interval), and when you brought the DB back online, the next health check saw amps that had not reported in for over 60 seconds and started attempting to failover the amps.22:42
johnsomOr your DB went read only for a while22:44
*** abaindur_ has joined #openstack-lbaas23:04
*** abaindur has quit IRC23:05
*** abaindur_ has quit IRC23:07
*** abaindur has joined #openstack-lbaas23:08
*** abaindur_ has joined #openstack-lbaas23:11
*** abaindur has quit IRC23:12
*** fnaval has quit IRC23:14
*** abaindur has joined #openstack-lbaas23:16
*** hyang has joined #openstack-lbaas23:18
*** abaindur_ has quit IRC23:19
*** salmankhan has quit IRC23:22
*** hyang has quit IRC23:22
*** abaindur_ has joined #openstack-lbaas23:22
*** abaindur has quit IRC23:23

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