Tuesday, 2019-06-11

*** rcernin_ has quit IRC00:41
*** rcernin has joined #openstack-lbaas00:41
*** yamamoto has joined #openstack-lbaas00:46
*** ricolin has joined #openstack-lbaas01:10
openstackgerritAdam Harwell proposed openstack/python-octaviaclient master: Allow creating/showing LBs with Additional VIPs  https://review.opendev.org/66447301:23
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023901:24
*** yamamoto has quit IRC01:48
rm_workWtf02:09
rm_workMessages from my desktop client aren't going through, damnit02:09
rm_workI thought I was just being ignored all day lol02:09
rm_worktest02:10
rm_workok great now it works lol02:10
rm_workwas asking if we had DDT support in tempest, i thought we did at some point, but i can't find it in the tempest docs.... so i assumed it isn't possible and just manually wrote a bunch of tests02:12
rm_workand some other stuff that doesn't matter i guess :D02:12
rm_workthough i also discovered everything is continuing to fail on my stuff until https://review.opendev.org/#/c/664385/ merges02:12
rm_workwhich is ... going to be a while, the gate is failing due to something above it in the merge queue, and some other random unrelated nova failures <_<02:13
rm_workand apparently it takes like 3 hours for one of the tests to finish T_T02:13
*** sapd1_x has joined #openstack-lbaas02:14
*** hongbin has joined #openstack-lbaas02:25
*** yamamoto has joined #openstack-lbaas02:50
johnsomYeah, didn't hear from you all day.03:19
johnsomDDT was a HUGE failure in neutron-lbaas, we long since deleted them.03:19
rm_workyeah k03:31
rm_workwell i WAS talking :D03:31
rm_workbut most of it was asking dumb questions or just opinions that i decided the path for myself when no one answered lol03:32
rm_worklike the ridiculous thing i did for the NETNS_NAME so it wasn't different from our constants >_>03:32
rm_workline 6: https://review.opendev.org/#/c/660239/31/elements/haproxy-octavia/post-install.d/21-configure-netns03:33
rm_worki asked if you thought it was INSANE but no answer -> did it :D03:33
rm_worki was gonna just import it and print the var, but because i can't guarantee having octavia-lib installed, and we added an import from it in the *constants* file, I can't03:36
rm_workso it was 1) use ast; 2) patch the import somehow (mock?) so it didn't explode03:37
rm_workalternatively i could do it the other way, have a file with the name in it, and have both the script and constants.py load up the file03:38
*** psachin has joined #openstack-lbaas03:40
*** ramishra has joined #openstack-lbaas03:59
*** hongbin has quit IRC04:01
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023904:24
*** gcheresh has joined #openstack-lbaas04:25
*** gcheresh has quit IRC04:46
*** luksky has joined #openstack-lbaas05:09
*** luksky has quit IRC05:25
*** gcheresh has joined #openstack-lbaas05:29
openstackgerritLingxian Kong proposed openstack/octavia-tempest-plugin master: Support more params for lb client initialization  https://review.opendev.org/66449705:46
openstackgerrittonybrad proposed openstack/octavia master: Change the requirement to releases.openstack.org  https://review.opendev.org/66449905:50
*** threestrands has joined #openstack-lbaas05:52
*** threestrands has quit IRC05:53
*** gcheresh_ has joined #openstack-lbaas06:17
*** gcheresh has quit IRC06:17
*** gcheresh has joined #openstack-lbaas06:21
*** gcheresh_ has quit IRC06:21
*** gcheresh has quit IRC06:33
*** gcheresh_ has joined #openstack-lbaas06:34
*** yamamoto has quit IRC06:40
*** pcaruana has joined #openstack-lbaas06:55
*** yamamoto has joined #openstack-lbaas06:58
*** rpittau|afk is now known as rpittau07:08
*** rcernin has quit IRC07:08
*** tesseract has joined #openstack-lbaas07:08
*** ramishra has quit IRC07:13
*** dayou has quit IRC07:23
*** ramishra has joined #openstack-lbaas07:30
openstackgerritAdam Harwell proposed openstack/octavia-lib master: Additional VIPs is also relevant in provider_base  https://review.opendev.org/66451007:33
rm_workerg, missed that somehow, was it new recently? :/07:35
rm_workeither that or just forgot to update it07:35
rm_workit's not FUNCTIONALLY relevant07:35
*** dayou has joined #openstack-lbaas07:37
*** yboaron has joined #openstack-lbaas07:42
openstackgerritAnn Taraday proposed openstack/octavia master: Use retry for AmphoraComputeConnectivityWait  https://review.opendev.org/66279108:00
openstackgerritAnn Taraday proposed openstack/octavia master: Use retry for AmphoraComputeConnectivityWait  https://review.opendev.org/66279108:19
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023908:20
*** dayou has quit IRC08:28
*** yboaron has quit IRC08:33
*** yboaron has joined #openstack-lbaas08:33
*** dayou has joined #openstack-lbaas08:41
openstackgerritAdam Harwell proposed openstack/octavia-lib master: Additional VIPs is also relevant in provider_base  https://review.opendev.org/66451008:43
*** rcernin has joined #openstack-lbaas09:03
*** dayou has quit IRC09:18
*** tobberydberg has quit IRC09:22
*** tobberydberg has joined #openstack-lbaas09:31
*** dayou has joined #openstack-lbaas09:31
*** yamamoto has quit IRC09:32
*** yamamoto has joined #openstack-lbaas09:37
rm_workjohnsom: that's an interesting one i haven't seen before: http://logs.openstack.org/62/664462/1/check/octavia-v2-dsvm-noop-api/589dc76/controller/logs/screen-o-api.txt.gz#_Jun_11_09_19_39_53270109:45
rm_workjust happened to see it while scrolling through09:45
*** salmankhan has joined #openstack-lbaas09:45
*** salmankhan has quit IRC09:45
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023909:57
*** yamamoto has quit IRC10:03
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023910:05
*** yamamoto has joined #openstack-lbaas10:07
openstackgerritGregory Thiemonge proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023910:10
*** pcaruana has quit IRC10:19
*** yamamoto has quit IRC10:24
*** yamamoto has joined #openstack-lbaas10:56
*** yamamoto has quit IRC11:00
*** pcaruana has joined #openstack-lbaas11:09
*** rcernin has quit IRC11:43
*** yamamoto has joined #openstack-lbaas11:56
*** yamamoto has quit IRC12:04
*** ccamposr has joined #openstack-lbaas12:15
*** goldyfruit has quit IRC12:17
*** ccamposr__ has quit IRC12:18
*** ricolin_ has joined #openstack-lbaas12:27
openstackgerritGregory Thiemonge proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023912:28
*** ricolin has quit IRC12:29
*** boden has joined #openstack-lbaas12:47
*** goldyfruit has joined #openstack-lbaas13:26
*** yamamoto has joined #openstack-lbaas13:29
*** pcaruana has quit IRC14:04
openstackgerritAnn Taraday proposed openstack/octavia master: Use retry for AmphoraComputeConnectivityWait  https://review.opendev.org/66279114:08
*** yamamoto has quit IRC14:15
*** yamamoto has joined #openstack-lbaas14:16
*** yamamoto has quit IRC14:16
*** pcaruana has joined #openstack-lbaas14:30
*** yamamoto has joined #openstack-lbaas14:30
*** pcaruana has quit IRC14:31
*** pcaruana has joined #openstack-lbaas14:31
bodenhi johnsom... if you get a few min to chat, pls let me know. thx14:38
*** Vorrtex has joined #openstack-lbaas14:40
*** spatel has joined #openstack-lbaas14:42
spatelcan i have multiple flavor for amphora instances?14:43
*** happyhemant has joined #openstack-lbaas14:44
*** yamamoto has quit IRC14:45
*** kklimonda has quit IRC14:47
*** yamamoto has joined #openstack-lbaas14:49
johnsomspatel You can create as many flavors as you like, but a load balancer can only have one at a time.14:49
spatelcan i deploy small flavor for dev and large flavor for production right?  or only i can pick one and have to stick with it?14:50
johnsomYou cannot change the flavor of a load balancer after it is created.  However you can certainly have a "small" and "large" flavor as options.14:52
*** yamamoto has quit IRC14:53
*** gcheresh_ has quit IRC14:58
johnsomboden Hi15:00
*** yboaron_ has joined #openstack-lbaas15:00
*** devfaz has quit IRC15:00
bodenjohnsom hi... so after some munking around I think our preferred route is what I mentioned yesterday; a way for the provider to signify they want the related objects populated in the provider calls15:00
bodennot sure what you think about that?15:00
bodenI'm working on some stub patches to at least "show" what I'm talking about15:01
*** devfaz has joined #openstack-lbaas15:01
bodenis it worth me getting those patches up so we can at least look at the code, or do you flat out think this isn't a good approach?15:02
johnsomboden So you want to pass a fully populated load balancer object tree to the provider driver?15:02
johnsomYou don't see a potential need for a query interface?15:02
*** yboaron has quit IRC15:02
bodenjohnsom so for example a Listener data model would include a loadbalancer that's populated by the controller for providers who want it (false by default)....15:03
bodenI think the query interface woudl work, but honestly using listener processes over sockets seems to add complexity to debug/management15:04
johnsomHmm, I don't think the code would be that bad to implement.15:05
johnsomHere are a couple of thoughts:15:06
johnsom1. I think the query option could be useful for other driver needs, such as re-sync where the driver checks the appliance configuration vs. the expected.15:07
johnsom2. How do we decided what to send with each object? For example, pools could have parents of LB or listener, etc.15:07
spateljohnsom: thanks!!15:07
johnsomI think we we go down the path of optionally sending more information, we might as well send the whole thing.15:08
johnsomI'm just wondering if we won't want to later do the query option anyway.15:09
johnsomIf your concern is mostly about the work to implement the query interface, I can offer to help with that.15:10
johnsomMostly I just want to discuss this so we come up with the best solution.15:11
*** yamamoto has joined #openstack-lbaas15:15
*** yamamoto has quit IRC15:15
*** yamamoto has joined #openstack-lbaas15:16
bodenjohnsom valid points.. our main concern is just now we are adding more sockets/listeners/processes/etc. and that adds complexity to how we manage, debug, etc. octavia deployments... if there was some well defined db interface it wouldn't be a concern, it just seems we are increasing the management footprint here15:17
*** pcaruana has quit IRC15:17
johnsomYeah, the downside is the added socket for sure. Otherwise, the code is relatively simple and maintains the separation/abstraction for the drivers.15:18
*** gcheresh_ has joined #openstack-lbaas15:19
bodenjohnsom I know some distros manage sockets, etc. and have "hooks" to help debug using existing openstack messaging... while I know the custom protocol is straight forward; it adds a new dimension to distro tools, etc.15:19
johnsomWe only had the two methods defined in the driver specification, so that is how I implemented it, but I wish I had done the socket a bit different. We still have the opportunity to do that however.15:20
*** yamamoto has quit IRC15:20
bodenjohnsom in that respect it would probably be easier for us just to use teh SDK client since it's more "well defined" and known to such tools15:20
*** sapd1_x has quit IRC15:21
johnsomThe unix domain sockets was selected to maintain a level of security. We considered doing a REST API, but we struggled to figure out how to authenticate the drivers.15:21
*** yamamoto has joined #openstack-lbaas15:22
bodenjohnsom sorry I'm not bashing on the current approach... I'm just trying to find some middle ground to not impact distro tooling too much15:22
*** yamamoto has quit IRC15:22
johnsomHmm, well, I think both are "well defined" and documented.15:22
johnsomboden How about this, I will look at what it would take to leverage one of the existing sockets to provide the query interfaces.  That way there would be no additional overhead for the distros/packagers than we already have.15:24
*** yamamoto has joined #openstack-lbaas15:26
*** yamamoto has quit IRC15:26
bodenjohnsom that may work, but I need to some investigation to confirm15:30
johnsomboden Ok, let me spend some time today and see if I can get an example posted for tomorrow.15:31
*** gcheresh_ has quit IRC15:37
openstackgerritGregory Thiemonge proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023915:37
openstackgerritGregory Thiemonge proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023915:40
*** pcaruana has joined #openstack-lbaas15:43
*** spatel has quit IRC15:46
*** luksky has joined #openstack-lbaas15:47
*** pcaruana has quit IRC15:55
*** yboaron_ has quit IRC16:03
*** tesseract has quit IRC16:18
*** spatel has joined #openstack-lbaas16:31
*** kklimonda has joined #openstack-lbaas16:32
*** yamamoto has joined #openstack-lbaas16:36
*** yamamoto has quit IRC16:42
*** pcaruana has joined #openstack-lbaas16:49
*** rpittau is now known as rpittau|afk16:55
*** spatel has quit IRC16:56
*** spatel has joined #openstack-lbaas16:56
*** luksky has quit IRC16:59
*** luksky has joined #openstack-lbaas17:05
*** ramishra has quit IRC17:07
*** luksky has quit IRC17:12
*** ccamposr__ has joined #openstack-lbaas17:16
*** ccamposr has quit IRC17:18
*** gcheresh_ has joined #openstack-lbaas17:52
*** KeithMnemonic has joined #openstack-lbaas18:10
openstackgerritMichael Johnson proposed openstack/octavia master: Add project_id to all of the provider objects  https://review.opendev.org/66345918:14
*** ricolin_ has quit IRC18:38
*** pcaruana has quit IRC18:39
rm_workjohnsom: blegh https://review.opendev.org/#/c/664473/18:46
rm_worknot sure how i missed that? though not in a hurry for a release or anything as it's not functionally breaking, works fine without the ABC updated18:46
rm_workerr18:47
rm_workdamnit wrong patch18:47
rm_workhttps://review.opendev.org/#/c/664510/18:47
johnsomAh, yeah, opps. I missed it too.18:49
johnsomI will be working on octavia-lib today too, so we can probably release in the next few days.18:49
rm_work1.2.1? :D18:52
*** gcheresh_ has quit IRC19:03
*** psachin has quit IRC20:02
*** ccamposr has joined #openstack-lbaas20:20
*** rouk has joined #openstack-lbaas20:21
roukjohnsom: is it a known bug that the openstack loadbalancer cli eats --insecure arg?20:22
*** ccamposr__ has quit IRC20:22
roukjust seems to be flavorprofile subcommand doesnt listen20:23
johnsomrouk: no, but that is also not out code, it is provided by openstackclient.  What are you seeing?20:31
johnsomOut->our20:31
roukthe following command doesnt obey --insecure, try it out. openstack --insecure loadbalancer flavorprofile create --name small --provider amphora --flavor-data '{"loadbalancer_topology":"ACTIVE_STANDBY", "compute_flavor":"1ed40309-f600-4f93-930f-d2bc39ca59cd"}'20:32
rouk--insecure on like... openstack --insecure server list, no problem, but that line, its not happy.20:33
johnsomJust to clarify, you have octavia api in https and this flag is not allowing the connection?20:34
roukyep, cert verify fail20:34
johnsomAre the certificates on the nova api and octavia api the same?20:35
roukyes.20:35
roukboth self sign in this particular lab setup20:35
johnsomHmm, —insecure is on openstack command and handled before our code runs.  This is odd20:36
roukyeah, thats why im confused, i specified it in the right order, it shouldnt be getting eaten20:36
johnsomWould you be ok pasting a —debug output from that?20:36
roukquestion before i do, "Provider 'amphora' reports error: SSL exception connecting to XXX" during flavor add, is this some kind of internal failure? the client is complaining, but amphra provider is serverside...20:38
johnsomHmm, that is an internal error to the provider driver20:40
johnsomI wonder what it is calling for a flavor add20:40
roukhttps://gist.github.com/adiana-tc/55a4bf0f088da5ac30a035540c04cf3820:41
rouklemme know when you got it20:42
johnsomI can see that paste, thanks20:42
roukany ideas?20:43
johnsomYeah, give me a minute to research20:43
johnsomThat error is not a CLI side error, that is a API process error20:44
roukyeah, i noticed once i read through the debug, all the calls got properly passed --insecure on the clientside20:44
johnsomI *think* Octavia is trying to contact the Nova API to validate a nova flavor and getting the SSL error.20:45
johnsomBut let me confirm20:45
roukso if the theory is right, i should be able to remove my nova flavor reference and have it work20:45
roukyep, youre correct.20:46
johnsomrouk So, this section: https://docs.openstack.org/octavia/latest/configuration/configref.html#nova20:47
roukgot it.20:47
johnsomin the octavia.conf is not setup correctly for the nova API. Either it needs "insecure" or you need to provide a ca_certificate_file20:47
roukyep, can do20:48
johnsomWhile you are there, you might want to check the other service sections too20:49
roukyeah, setting insecure on neutron too, its a lab env and theres no outside access, just want to protect transit into the lab.20:49
johnsomYep20:49
rouki can verify CAs on the clientside and thats enough for me.20:50
*** boden has quit IRC21:05
*** luksky has joined #openstack-lbaas21:09
*** Vorrtex has quit IRC21:11
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023921:21
openstackgerritAdam Harwell proposed openstack/python-octaviaclient master: Allow creating/showing LBs with Additional VIPs  https://review.opendev.org/66447321:28
*** luksky has quit IRC21:35
openstackgerritAdam Harwell proposed openstack/python-octaviaclient master: Allow creating/showing LBs with Additional VIPs  https://review.opendev.org/66447321:36
openstackgerritAdam Harwell proposed openstack/python-octaviaclient master: Allow creating/showing LBs with Additional VIPs  https://review.opendev.org/66447321:38
*** spatel has quit IRC21:39
rm_workrouk: you could also add the self-signing (or whatever) CA for your other services to the list of accepted CAs on the octavia host, and that is a much cleaner solution (at least it verifies it's YOUR self-signed cert and not a MITM)21:40
rm_workthen you don't need to use insecure mode for those in the octavia.conf21:41
*** ccamposr has quit IRC22:06
*** rcernin has joined #openstack-lbaas22:10
rm_workjohnsom: lol our network noop driver is so bad22:30
rm_workdoing some fixes now to try to get it to be not quite as painful...22:30
rm_workat least tracking what it has returned and being consistent about it, and having the things that return actually have the expected IDs, lolol22:31
rm_workhilarious example: https://github.com/openstack/octavia/blob/master/octavia/network/drivers/noop_driver/driver.py#L164-L16822:31
rm_workget_subnet ... passed a subnet_id... returns a subnet object with a new random ID XD22:32
rm_worknot sure if any of this will actually help the real issue i'm running into with these tests though T_T22:33
johnsomYeah, I have fought with that noop driver myself.22:51
*** goldyfruit has quit IRC23:14
*** goldyfruit has joined #openstack-lbaas23:40
*** ianychoi has quit IRC23:48
*** ianychoi has joined #openstack-lbaas23:48
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023923:55
openstackgerritAdam Harwell proposed openstack/octavia master: Allow multiple VIPs per LB  https://review.opendev.org/66023923:55
openstackgerritMichael Johnson proposed openstack/octavia master: Amphora logging  https://review.opendev.org/62483523:55
openstackgerritMichael Johnson proposed openstack/octavia-tempest-plugin master: Save amphora logs in gate  https://review.opendev.org/62640623:58
openstackgerritMichael Johnson proposed openstack/octavia master: Amphora logging  https://review.opendev.org/62483523:59

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