Thursday, 2015-12-10

bloganDivya: ah yeah i vaguely remember that.  and saw that this could possibly be an issue and put that comment, but just kept it bc of v100:00
bloganDivya: sounds like you hit that condition my note was concerned about?00:01
*** Divya has quit IRC00:01
*** madhu_ak has joined #openstack-lbaas00:01
*** madhu_ak_ has quit IRC00:02
*** Divya has joined #openstack-lbaas00:06
Divyablogan: sorry lost my connection ...00:06
Divyablogan: shouldn't we delay the actual db delete until driver actually finishes the delete ..00:07
*** manishg has joined #openstack-lbaas00:09
*** chlong has quit IRC00:09
*** madhu_ak has quit IRC00:11
*** madhu_ak_ has joined #openstack-lbaas00:11
*** Divya has quit IRC00:11
*** Divya has joined #openstack-lbaas00:14
*** crc32 has quit IRC00:20
Divyablogan: ping i am sorry i lost my connection again .. and missed any messages you sent .. sorry to bother you ...00:21
bloganDivya: yeah thast why i put that comment there as a TODO, but was tryint o get v1 parity adn didn't have time to fully test that out00:21
bloganDivya: if you want to change that up and test it out, be my guest00:24
bloganDivya: just be aware that the CI doesn't run against that driver now00:24
*** ianbrown has quit IRC00:25
*** fnaval has joined #openstack-lbaas00:27
*** ianbrown has joined #openstack-lbaas00:28
*** fnaval has quit IRC00:28
*** manishg has quit IRC00:30
*** minwang2 has quit IRC00:31
Divyablogan: thanks logan .. sure would like to work on that change .. should i create a bug for liberty then?00:35
Divyablogan: so the fix should be to have the agent trigger the db delete right?00:39
*** manishg has joined #openstack-lbaas00:39
*** diogogmt has quit IRC01:02
*** chlong has joined #openstack-lbaas01:05
*** Aish has left #openstack-lbaas01:06
*** yuanying_ has joined #openstack-lbaas01:09
*** yuanying_ has quit IRC01:09
*** yuanying has quit IRC01:11
*** ajmiller_ has quit IRC01:22
*** chlong has quit IRC01:23
*** yuanying has joined #openstack-lbaas01:23
openstackgerritMerged openstack/neutron-lbaas: Automatically generate neutron LBaaS configuration files
*** ianbrown has quit IRC01:31
*** ianbrown has joined #openstack-lbaas01:31
*** ianbrown has quit IRC01:33
*** ianbrown has joined #openstack-lbaas01:33
*** bharathm has quit IRC01:36
*** manishg has quit IRC01:41
*** armax has quit IRC01:43
*** yamamoto has joined #openstack-lbaas01:43
*** ianbrown has quit IRC01:44
*** ianbrown has joined #openstack-lbaas01:44
*** yamamoto has quit IRC01:49
*** madhu__ak_ has joined #openstack-lbaas01:50
bana_knot able to ssh to amphora, any idea?01:51
*** yamamoto has joined #openstack-lbaas01:54
*** madhu_ak_ has quit IRC01:54
*** yamamoto has quit IRC01:54
*** madhu__ak_ has quit IRC01:57
*** rcernin has quit IRC02:01
*** bana_k has quit IRC02:06
*** davidlenwell has quit IRC02:10
*** davidlenwell has joined #openstack-lbaas02:13
*** bana_k has joined #openstack-lbaas02:18
*** ianbrown has quit IRC02:20
*** ianbrown has joined #openstack-lbaas02:21
*** ianbrown has quit IRC02:27
*** ianbrown has joined #openstack-lbaas02:28
*** diogogmt has joined #openstack-lbaas02:33
*** chlong has joined #openstack-lbaas02:44
*** ianbrown_ has joined #openstack-lbaas02:44
*** ianbrown has quit IRC02:45
*** ianbrown_ has quit IRC02:47
*** ianbrown_ has joined #openstack-lbaas02:47
*** bana_k has quit IRC02:52
*** manishg has joined #openstack-lbaas03:09
*** yamamoto has joined #openstack-lbaas03:10
*** yuanying has quit IRC03:19
*** sbalukoff has quit IRC03:35
*** yuanying has joined #openstack-lbaas03:37
*** yuanying has quit IRC04:02
*** davidlenwell has quit IRC04:06
*** yuanying has joined #openstack-lbaas04:06
*** davidlenwell has joined #openstack-lbaas04:09
*** bana_k has joined #openstack-lbaas04:23
*** amotoki has quit IRC04:25
*** ianbrown_ has quit IRC04:38
*** ianbrown__ has joined #openstack-lbaas04:39
*** manishg has quit IRC04:44
*** ianbrown__ has quit IRC04:45
*** ianbrown__ has joined #openstack-lbaas04:45
*** neelashah has joined #openstack-lbaas04:46
*** crc32 has joined #openstack-lbaas04:46
*** sbalukoff has joined #openstack-lbaas04:51
*** armax has joined #openstack-lbaas05:11
*** crc32 has quit IRC05:17
*** amotoki has joined #openstack-lbaas05:30
*** manishg has joined #openstack-lbaas05:37
*** prabampm has joined #openstack-lbaas05:46
*** bana_k has quit IRC05:46
*** blogan_ has joined #openstack-lbaas05:51
*** numans has joined #openstack-lbaas05:52
*** neelashah has quit IRC05:55
*** manishg has quit IRC05:57
*** bana_k has joined #openstack-lbaas06:20
*** chlong has quit IRC06:28
openstackgerritMerged openstack/octavia: Refactor BarbicanAuth to allow for configurable auth method
*** chlong has joined #openstack-lbaas06:49
*** armax has quit IRC06:57
*** EvgenyF has joined #openstack-lbaas06:59
*** [1]evgenyf has joined #openstack-lbaas06:59
*** chlong has quit IRC07:04
*** rcernin has joined #openstack-lbaas07:11
*** chlong has joined #openstack-lbaas07:20
*** nmagnezi has joined #openstack-lbaas07:31
*** blogan_ has quit IRC07:51
*** chlong has quit IRC08:05
*** mhickey has joined #openstack-lbaas08:18
*** numans has quit IRC08:37
*** bana_k has quit IRC08:41
*** jschwarz has joined #openstack-lbaas09:02
*** yuanying has quit IRC09:10
openstackgerritStephen Balukoff proposed openstack/octavia: Add spec for active-active
*** eranra has joined #openstack-lbaas09:20
*** eranra has quit IRC09:22
*** eranra has joined #openstack-lbaas09:22
*** openstackgerrit has quit IRC09:32
*** openstackgerrit has joined #openstack-lbaas09:33
*** [1]evgenyf has quit IRC10:49
*** EvgenyF has quit IRC10:49
*** ianbrown__ has quit IRC10:52
*** ianbrown__ has joined #openstack-lbaas10:52
*** ianbrown__ has quit IRC11:01
*** ianbrown__ has joined #openstack-lbaas11:02
*** ianbrown__ has quit IRC11:11
*** ianbrown__ has joined #openstack-lbaas11:11
*** yamamoto has quit IRC11:15
*** rtheis has joined #openstack-lbaas12:21
*** prabampm has quit IRC12:27
*** doug-fish has joined #openstack-lbaas12:32
*** EvgenyF has joined #openstack-lbaas12:40
*** [1]evgenyf has joined #openstack-lbaas12:40
openstackgerritOpenStack Proposal Bot proposed openstack/neutron-lbaas: Updated from global requirements
openstackgerritOpenStack Proposal Bot proposed openstack/octavia: Updated from global requirements
*** openstackgerrit has quit IRC12:47
*** openstackgerrit has joined #openstack-lbaas12:48
*** yamamoto has joined #openstack-lbaas12:59
*** yamamoto_ has joined #openstack-lbaas13:01
*** yamamoto has quit IRC13:05
*** ducttape_ has joined #openstack-lbaas13:13
*** yamamoto_ has quit IRC13:14
*** yamamoto has joined #openstack-lbaas13:15
*** ducttape_ has quit IRC13:24
*** ducttape_ has joined #openstack-lbaas13:25
*** ducttape_ has quit IRC13:32
openstackgerritBo Chi proposed openstack/neutron-lbaas: Change status to INACTIVE if admin_state_up if false
*** enikanorov has quit IRC13:47
*** enikanorov has joined #openstack-lbaas13:49
*** sc68cal has quit IRC13:58
*** sc68cal has joined #openstack-lbaas14:01
*** sc68cal has quit IRC14:01
*** sc68cal has joined #openstack-lbaas14:01
*** eranra has quit IRC14:08
*** yamamoto has quit IRC14:17
*** yamamoto has joined #openstack-lbaas14:20
*** neelashah has joined #openstack-lbaas14:20
*** yamamoto has quit IRC14:22
*** alejandrito has joined #openstack-lbaas14:22
*** yamamoto has joined #openstack-lbaas14:24
*** [1]evgenyf has quit IRC14:25
*** EvgenyF has quit IRC14:26
*** yamamoto has quit IRC14:26
*** yamamoto has joined #openstack-lbaas14:38
*** amotoki has quit IRC15:02
*** ducttape_ has joined #openstack-lbaas15:03
*** manishg has joined #openstack-lbaas15:09
*** prabampm has joined #openstack-lbaas15:21
*** TrevorV|Home has joined #openstack-lbaas15:21
openstackgerritMerged openstack/neutron-lbaas: Updated from global requirements
*** kobis has quit IRC15:27
*** manishg has quit IRC15:28
*** kobis has joined #openstack-lbaas15:31
*** eranra has joined #openstack-lbaas15:38
*** TrevorV|Home has quit IRC15:41
*** armax has joined #openstack-lbaas15:45
openstackgerritMartin Hickey proposed openstack/neutron-lbaas: Remove Neutron LBaaS static example configuration files
*** armax has quit IRC15:50
*** TrevorV|Home has joined #openstack-lbaas15:50
*** eranra_ has joined #openstack-lbaas15:55
*** armax has joined #openstack-lbaas15:55
*** kobis has quit IRC15:57
*** eranra has quit IRC15:58
*** eranra_ has quit IRC16:02
*** eranra_ has joined #openstack-lbaas16:02
*** kobis has joined #openstack-lbaas16:02
*** jschwarz_ has joined #openstack-lbaas16:08
*** eranra_ has quit IRC16:09
*** jschwarz has quit IRC16:10
*** armax has quit IRC16:11
*** manishg has joined #openstack-lbaas16:15
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: (WIP) XFF
*** yamamoto_ has joined #openstack-lbaas16:17
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: Add support X-Forwarded-For header
*** ajmiller has joined #openstack-lbaas16:18
*** yamamoto has quit IRC16:18
openstackgerritKobi Samoray proposed openstack/neutron-lbaas: (WIP) Add support X-Forwarded-For header
*** manishg has quit IRC16:32
*** manishg has joined #openstack-lbaas16:35
mhickeyHey All. I am getting an error in 'gate-devstack-bashate' as follows: "ERROR: InvocationError: '/bin/bash -c find /home/jenkins/workspace/gate-devstack-bashate ........". Anyone got any idea whats up?16:41
*** rcernin has quit IRC16:42
johnsommhickey What patch?16:46
mhickeyjohnsom: Hey.
ajmillermhickey 2015-12-10 14:12:51.661 | [E] E001: Trailing Whitespace: '        iniset $NEUTRON_CONF_DIR/neutron_lbaas.conf service_providers service_provider $DEFAULT_LB_PROVIDER '16:48
ajmiller2015-12-10 14:12:51.661 |  - /home/jenkins/workspace/gate-devstack-bashate/lib/neutron-legacy : L106916:48
ajmiller2015-12-10 14:12:51.661 | [E] E001: Trailing Whitespace: '        '16:48
ajmiller2015-12-10 14:12:51.661 |  - /home/jenkins/workspace/gate-devstack-bashate/lib/neutron-legacy : L107016:48
johnsommhickey Yep.  If you dig into the log there are some errors reported:
ajmillerbashate isn't necessarily very friendly, you need to scroll back up to see the actual errors.16:49
*** ducttape_ has quit IRC16:49
mhickeyjohnsom, ajmiller: ok, I see it now. thanks16:50
mhickeyBTW, what is bashate?16:50
johnsomIt is a syntax test suite for bash scripts.  It's like pep8 for bash scripts16:52
*** xiaohhui has quit IRC16:52
mhickeyjohnsom: ok, kewl. Damn you bashate! :)16:52
mhickeyjohnsom: thanks! :)16:53
*** jschwarz__ has joined #openstack-lbaas16:53
*** xiaohhui has joined #openstack-lbaas16:54
*** kobis has quit IRC16:55
*** jschwarz_ has quit IRC16:56
*** bana_k has joined #openstack-lbaas16:58
*** manishg has quit IRC17:00
*** armax has joined #openstack-lbaas17:03
*** minwang2 has joined #openstack-lbaas17:05
*** ducttape_ has joined #openstack-lbaas17:07
*** kobis has joined #openstack-lbaas17:09
*** manishg has joined #openstack-lbaas17:11
*** ig0r_ has joined #openstack-lbaas17:11
*** manishg_ has joined #openstack-lbaas17:12
*** manishg has quit IRC17:16
*** kobis has quit IRC17:17
*** diogogmt has quit IRC17:20
*** prabampm has quit IRC17:20
*** ianbrown__ has quit IRC17:20
*** ianbrown__ has joined #openstack-lbaas17:21
*** diogogmt has joined #openstack-lbaas17:21
*** manishg_ has quit IRC17:22
*** kobis has joined #openstack-lbaas17:28
blogankobis: ping17:32
openstackgerritMerged openstack/octavia: Updated from global requirements
kobisblogan: hey17:35
blogankobis: hey ptoohill brought up a good point about the xff headers17:35
blogankobis: why not just insert it all the time?17:36
ptoohillIs there ever a specific reason to not send the header if its available?17:36
*** crc32 has joined #openstack-lbaas17:36
kobisbecause xff header insertion requires termination of the tcp connection17:36
ptoohillAnd if the user select termination is that not enough 'go ahead' to insert it?17:37
kobiswhile i'm not sure that this applies to haproxy (or vmware Edge appliance…), most of the commercial LBs won't terminate the TCP connection unless there's an L7 operation17:37
kobisthat has a major impact on performance17:37
ptoohilladding a header does?17:37
kobisin most cases, yes17:38
ptoohilloh, so you want the user to specific termination as well as the xff header17:38
kobisthink of a LB which is implemented as a router or switch (e.g F5, Radware)17:39
kobisthey won't terminate the session unless they have to17:39
bloganis there a number of people wanting this? to basically be able to turn it off?17:40
ptoohillThats fair i suppose, i still dont see the one off header value in the api as worthwhile, but thats just me17:40
kobisI believe that any L7 operation will force termination - I guess that Radware does that implicitly - but we can ask Radware17:40
kobisor maybe dougwig17:40
*** manishg has joined #openstack-lbaas17:40
ptoohillmaybe we can make it wore generic somehow? not sure of a better solution ATM though :/17:40
dougwigyeah, as soon as you modify, you're in a different ballgame.17:41
*** mhickey has quit IRC17:41
dougwigyou're in l3 land instead of l2.17:41
blogani was assuming the rfe was saying to enable it in all drivers when i saw it, not that it was going to be toggleable feature through the api17:41
dougwigwell, l4.17:41
sbalukoffHey folks! When you get a chance, we'd love feedback on this:
kobisyour'e actually in l7 land :)17:41
dougwigheh, fine, l7.17:41
sbalukoff(That's the new active-active spec)17:41
kobisnow i'd love to come up with generic API for this17:42
dougwigl2/l3 load-balancing can be **FAST**. you don't want to subtract that just due to removing a toggle, i think.17:42
ptoohillhaproxy seems to do it with ease, but thats the extent of my understand on this. Im ok with it going in, i would really like to find a better way to do this with potential to add other things to it, but again i dont have a better solution so i suppose this is ok to me17:42
kobisL2-L3 is just passing packets around (in L3 you have to update TTL and change MAC addresses…)17:42
bloganbefore we add something like this that is kind of a slippery slope of a bunch of toggleable things, i'd like to know if there's a lot of end users wanting this17:42
*** diogogmt has quit IRC17:43
kobishaproxy is different as it always terminates the client side socket17:44
ptoohillfair enough, if this gets in we can utilize it also, i just really dont like the idea of the one off17:45
blogankobis: still, have you had a lot of requests for this? bc yours is the first for me17:45
kobiscould a —special-header=xff,blabla,whatever be any better?17:46
ptoohilli would like that more17:46
ptoohillthat way its future proof17:46
ptoohillthough that would require additional parsin in the driver, but not too bad i wouldnt think17:46
kobisthat'll work as long as these all are togglables17:46
kobistherefore it's not future proof…17:46
*** diogogmt has joined #openstack-lbaas17:47
ptoohilltough solving for these types of features17:47
bloganim concerned about the slippery slope17:47
ptoohillim ok the way it is honestly, i dont know of other headers off hand now a better way to do it besides maybe a list17:48
bloganadd this little thing, then this little thing, then this little thing, and then boom you've got a very complicated api with complicated validation17:48
kobisI dunno - if something is common enough to fit into the APIs of most LBs, I guess that it's cool to have in LBaaS API which is a generaization of the above17:48
ptoohilli agree, but do we have a list of header like this?17:48
kobisbut that's my view of things17:48
ptoohilli guess im not sure how to solve for this because in both our 1.0 rackspace product as well as lbaasv2 haproxy its done by default17:49
kobisXFF is the very common - you basically cannot audit your clients without it17:49
kobisat the app level17:49
ptoohillyea, we require this header also, i understand its needs, we just do it by default17:49
blogankobis: i don't disagree, just worried about the balance of it all, then again most users will use a UI and not the API so my worries abotu the complexity of an API are probably not as important17:49
kobisany commercial LB is facing these UI difficulties - this is solvable by addition of HTTP/HTTPS specific panel, L7 features or whatever17:51
kobisor you can always drop the UI support for this :)17:51
blogankobis: does your driver have it on by default? or is it off?17:52
kobisptoohill: you do use haproxy so there are no extra penalties for you by adding xff in any case. you cannot assume that everyone uses haproxy though17:52
ptoohillwe also use another product that does somethign similar to what you describe, and thats by default17:52
ptoohillim not negating your reasonings17:52
kobisas of now it is off. cost of having it on my default: 30sec17:52
ptoohilli just feel that if the user configures that type of lb they would expect that feature17:52
ptoohilli dont see a NEED for it to be toggable, but thats from my experience17:53
johnsomWe also have the request for the timeouts to be exposed, not sure if that ties into this sort of thing or not.  I usually see these all as options on the LB and pools17:53
ptoohillthats a big hit, and makes sense why you would want it17:53
*** yamamoto_ has quit IRC17:54
blogankobis: 30 seconds for what?17:54
kobishaving xff on by default :)17:54
blogankobis: i know but 30 seconds added on top of what?17:55
blogani mean what takes 30 seconds longer17:55
kobisblogan: having xff on by default in vmware driver is 30sec of work really. yet I don't think that this is a good approach.17:55
crc3230 seconds per request?17:56
kobisblogan: nah I meen that it's 30sec of coding, to have this working...17:56
blogankobis: ohhhh lol17:56
kobisnot 30sec at runtime…. that would be one worthless LB :)17:56
blogankobis: whats the performance penalty for having it on?17:56
*** manishg has quit IRC17:56
blogankobis: lol you had me worried and i was like ther'es absolutely no way17:56
kobisit doesn't matter much what's the performance for the vmware LB - but in general for an lbaas-implementing driver17:57
ptoohillbut would your users configuring that type of lb ever expect it to not be there?17:57
*** manishg has joined #openstack-lbaas17:58
ptoohillIf the performance hit isnt a big deal, and most users want/need this why not do it by default17:58
ptoohillim missing the link here17:58
*** SumitNaiksatam has joined #openstack-lbaas17:58
ptoohilli thought adding this caused 30sec build time or something17:58
kobisi have a couple of requests for having an option to enable this17:58
crc32I thought he meant 30 seconds per HTTP request.17:58
ptoohillok, thats a fair usecase imo then17:59
kobisI haven't tried to sell them the idea of having this by default as you guys do17:59
ptoohillor yea that crc3217:59
ptoohilli guess i just dont see why they wouldnt want the header in this type of config17:59
ptoohillso it makes sense for default17:59
*** madhu_ak has joined #openstack-lbaas17:59
ptoohillbut if users want to toggle it then it makes sense17:59
blogani gotta go to a meeting, i've expressed my concerns but in the end its somethign every LB out there supports, soooo i dont know17:59
johnsomI have heard one person ask for turning this off, but I think it was to work around another vendor's bug.17:59
kobisbut from my experience (working for Radware for a long while), users don't want this by default as it has performance impact (major one with Radware and likes)18:00
ptoohillThats fair then and i do understand that18:00
blogani suspect our users will be different than thsoe users, but i have no proof18:00
sbalukoffblogan +118:00
ptoohillmaybe we can come up with another solution to the one off and im be 100% with it, otherwise, this makes sense and since i dont have idea for other idears/solution im on board18:00
bloganok i gotta go18:01
blogangood discussions though18:01
crc32would it be reasonable to have the operator speify if XFF is on or off by default via a conf file?18:01
ptoohillcrc32: the users are requesting it, that was going to be another suggestion if that wasnt the case18:01
kobiseh, what if I have one listener serving my GIFs, hauling lots of traffic, and another serving the login page?18:02
johnsomI think it's better to expose it to the user than have it in the conf.  Coming up with a non-one off solution would be good.18:02
kobisso I have to choose between penalizing listener A because I need XFF for listener B?18:02
*** jschwarz__ has quit IRC18:03
kobisI suggest that we'll take a couple of days to thing, of maybe a better solution18:03
ptoohillI still see it different because of haproxy, that gets added to the backend configuration, so pool A with x members can have the xff while the other pool does not18:04
ptoohilljust a little bit of disconnect :D18:04
kobisthe patches aren't merged yet, so we have time :)18:04
crc32so I'm suggesting the user be allowed to specify it in the api request but if they don't then the operator can specify the default.18:04
*** nmagnezi has quit IRC18:04
kobiscrc32: a user has no access to the conf file18:04
crc32operater meaning rackspace or whoever is hosting the driver.18:05
ptoohilli think hes saying so the operator can send it by default or not regardless of users selection type thing18:05
kobisso he needs someone to turn on xff for him - that's not a very user friendly approach18:05
crc32operator = cloud hosting provider.18:05
ptoohillThat way, in our example, its always on by default18:05
ptoohillbut the user could specify to disable18:05
johnsomcrc32 yeah, that is fair.  There should be a default.  Having it in the conf would let the operator decide what the right default is for their deployment.  I.e. HAproxy is probably default on, others might be better default off18:05
ptoohilltype thing18:05
dougwigIf it's just a config tweak without Api, use flavors18:07
dougwigSec rebooting18:07
ptoohilloh, interesting idea18:08
*** bana_k has quit IRC18:08
kobisnever looked at flavors really - doesn't that mean that each LB can either have xff on or off?18:09
crc32no kobis I'm saying that since you prefer it to be off you can specify that in your enviornment. The end customer can always override your default.18:09
kobisthey can override only if they have access to the LB itself18:09
crc32kobis: Yea I thought thats what I said.18:10
kobisif they have access to the LB itself, they could have configured the listener top to bottom - why bother with lbaas in the 1st place :(18:10
johnsomflavors is a good idea for the default.  Not sure it meets the customer need otherwise.18:13
crc32kobis: ok so I'm not sure what problem your solving for. Anyways I got to run.18:13
*** bana_k has joined #openstack-lbaas18:13
dougwigIf prefer to see an extended feature map in the Api, personally.  I know lots who are unhappy with the limited feature set.18:13
dougwigAnd always doing the insertion hurts things like dsr. Of course you can keep 1 or 10g stuffed even at l7.  But...18:14
*** amit213 has quit IRC18:14
kobisdougwig: i tend to agree. if a feature is common enough among LBs, why not have it in the API?18:15
*** amit213 has joined #openstack-lbaas18:15
dougwigblogan: I'm not sure how we quantify your demand desires. Everyone that shows up is a vendor or huge operator.  :)18:15
kobisand there's no sense in deprecating the LB performance regardless of capabilities18:15
kobisdougwig: even if your LB does 80G. so your customer paid for 80G - why force him into L7 processing to avoid a config flag?18:17
kobisor deprecate a useful feature?18:17
dougwigkobis: I'm agreeing with you on that point.18:19
kobisi'd try to come up with a more generic solution for header insertion - but most headers require value setting18:21
kobise.g Cookie: <value> or such18:21
kobiswhile xff value is set by the LB - it's the requests source IP18:22
openstackgerritMerged openstack/octavia: Expose project_id in octavia api
openstackgerritMerged openstack/neutron-lbaas: Send project_id/tenant_id to octavia api
dougwigblogan: so you'd be opposed to a bunch of optional toggles on the create call?18:27
dougwigotoh, i can see the argument against, since a lot of these toggles are for fitting LB's into legacy environments with existing servers, and a cloud shouldn't have those issues.18:28
dougwigblogan: performance penalty is an order of magnitude, at least.18:29
ptoohillblogan wont be back for a couple of hours18:30
ptoohillfor a 'meeting'18:30
kobisall i can come up with is either something like —set-header which accepts a list, or a specific flag for xff18:34
*** crc32 has quit IRC18:34
rm_workwe also do XFP in our v1 product... is that a real thing we might need too?18:34
kobisthe 1st one is more flexible but can be abused by using it to some other toggles…18:34
ptoohillTrue, forgot about that one18:35
kobisXFP is not as commonly used AFAIK18:35
rm_workwe also do that by default :P18:35
ptoohillbut its still something the users may want to enable18:35
ptoohillslash disable18:35
kobisas XFF is mandatory for any auditing18:35
rm_workI don't know what our vendor is doing then, I didn't even realize we were introducing a performance hit, since we already were doing termination...18:35
ptoohillWe had a requirement for XFP from users which is why we used it18:35
kobis_might_ is a key here….18:36
ptoohillyea, thats what i was thinking too rm_work18:36
rm_workI wonder if we turned off XFF/XFP by default if our product would go an order of magnitude faster :P18:36
kobisonce might goes _wants_… than yeah, we have this discussion again, i guess18:36
ptoohillI dont think it would, we had it disabled prioir to enabling it without much gain/hit18:36
rm_workcause that'd be hilarious18:37
xgermanwell, can we handle that XFP, XFF stuff with blogans new Get-me-a-LB API?18:37
*** sbalukoff has quit IRC18:37
xgermanhave a big advanced feature json18:37
*** bharathm has joined #openstack-lbaas18:38
xgermanjust throwing that out there… since I agree having PUT …/XFF/TRUE is lame18:38
xgermanand you would need the json blob anyway for get-me-a-lb18:39
rm_workoh btw I think is good to go18:41
rm_workand is waiting for testing, does HP have the ability to spin this up? I don't actually have any idea how VRRP works18:42
ptoohillcan this not be tested in devstack?18:42
rm_workand looks like it shouldn't cause any problems18:42
ptoohillI hope it can, my patches have had to be reworked several times to make things work with devstack18:42
rm_workptoohill: can it? can I just switch vrrp to enabled and have it "just work"? :P18:42
ptoohilli hope so18:43
xgermanyes, you can just do that18:43
ptoohilli havnt actually ran it, but will once im done with this rework18:43
xgermanthough it’s called toology18:43
rm_workhmm alright, might give that a shot after I push up the CR i'm working on now18:43
ptoohilltoology is their new album18:43
*** sbalukoff has joined #openstack-lbaas18:43
* ptoohill tool fans????????????????????18:43
xgermanthe testing is more that you fire up an lb and then cause havoc by let’s say nova remove the master18:44
johnsomrm_work Grin, that is my patch.  I spun it up.  grin18:44
ptoohillso, call delete on the active vm would work?18:44
ptoohilldelete via nova18:44
rm_workand basically you'd be watching to see if a new one came up and tried to take back over?18:44
xgermanpreempt actually makes sure that the new amhora doesn’t become master - so you need to make sure heartbeat/failover runs18:44
ptoohillah, but thats still in wip?18:45
ptoohillthe failover stuff18:45
xgermanjohnsom did I misrepresent your patch?18:45
xgermanptoohill correct18:45
rm_workfrom what I understood already, that was an accurate assessment18:45
johnsomVRRP/Active/Standby spins up two amps.  so, failover is in seconds.  This is different from failover flow to hot spare, which is a different patch still being worked on18:46
rm_worki just wasn't sure if it "just worked" in devstack magically18:46
rm_workgood that it does18:46
xgermanwe demoed it :-)18:46
xgermanyep, watch the Video...18:46
johnsomA test would be turn on Active/Standby, build LB, curl the VIP, kill one of the two amps, curl the vip.18:46
johnsomrm_work you are killing me.  Yes, I demoed it in Tokyo18:47
rm_workin the Octavia hands-on?18:47
rm_workI didn't make it to the other one18:47
johnsomNo the LBaaS talk18:47
rm_workso I would have missed it18:47
xgermanyou didn;t watch the video? shame on you!18:47
rm_workI was in a Barbican round-table trying to push my split-key thing18:48
rm_workI did not T_T18:48
rm_workI kinda assumed I knew about LBaaS, guess I was wrong :P18:48
johnsomThe noprempt setting in that patch means that if haproxy is stopped on master, and the backup becomes active (normal active/standy), then later the master haproxy comes up again, the backup will still have the IP and be responding.  Basically it won't fail back to the master until the backup fails18:48
rm_workspeaking of, I THOUGHT everyone understood the split-key thing and why I was pushing it and agreed that it would be at least "OK", but like two weeks later everyone seems to have forgotten the details T_T18:49
rm_workjohnsom: so i might want to SSH into the master and stop HAProxy18:49
rm_workand then start it again after it fails over18:49
rm_worknot actually delete the VM18:49
xgermanyeah, until that failover stuff works better18:50
johnsomYes.  ssh service haproxy<uuid> stop is a good way to test this18:50
johnsomDeleting via nova makes it hard for the master to come back up until I get the failover flow fixed.  WIP patch for that, bug fixing.18:51
rm_workk, still busy trying to test the barbican workflow stuff, but i'll see if I can get to testing that, uhh... probably next week <_<18:51
rm_workhmm, maybe tomorrow18:51
rm_workwill see18:51
*** bana_k has quit IRC18:52
rm_workabout to push the sibling patch to the Barbican Auth refactor that just merged in Octavia, for Neutron-LBaaS18:52
rm_workand try to get the code a LITTLE closer together18:52
*** harlowja has quit IRC18:56
*** harlowja has joined #openstack-lbaas18:56
*** bana_k has joined #openstack-lbaas19:02
*** manishg has quit IRC19:02
*** TrevorV|Home has quit IRC19:04
rm_workwoo this works today:
rm_worksince we don't appear to have a docs job on octavia?19:09
rm_workI thought we did but don't see it19:09
ptoohilldoes the docs job host it somewhere if we were to have one?19:10
johnsomYes, you can click on the docs job and get a rendered version19:11
ptoohilloh, nice19:11
*** SumitNaiksatam has quit IRC19:17
*** SumitNaiksatam has joined #openstack-lbaas19:18
*** SumitNaiksatam has quit IRC19:18
*** ducttape_ has quit IRC19:19
*** pai15 has joined #openstack-lbaas19:29
*** manishg has joined #openstack-lbaas19:34
*** ducttape_ has joined #openstack-lbaas19:37
*** pai15 has quit IRC19:41
openstackgerritMerged openstack/octavia: Rename tenant_id in the network models to project_id
rm_worknice, we're down to a single page of open CRs19:52
johnsomYeah, we have been doing pretty good with that19:53
johnsomBugs are a different story19:53
*** rcernin has joined #openstack-lbaas20:01
*** minwang2 has quit IRC20:03
*** armax has quit IRC20:09
*** neelashah has quit IRC20:10
*** TrevorV has joined #openstack-lbaas20:12
openstackgerritPhillip Toohill proposed openstack/octavia: Updates for containers functionality
*** mixos has joined #openstack-lbaas20:23
*** mixos has quit IRC20:38
*** TrevorV has quit IRC21:04
*** TrevorV has joined #openstack-lbaas21:17
xgermanall johnsom’s leadership...21:19
xgermanthat previous PTL was a slacker...21:19
*** armax has joined #openstack-lbaas21:31
*** mixos has joined #openstack-lbaas22:01
*** johnsom has quit IRC22:08
*** johnsom has joined #openstack-lbaas22:08
*** shakamunyi has quit IRC22:12
*** shakamunyi has joined #openstack-lbaas22:15
*** minwang2 has joined #openstack-lbaas22:23
openstackgerritPhillip Toohill proposed openstack/octavia: Adding new network driver for containers
openstackgerritPhillip Toohill proposed openstack/octavia: Updates for containers functionality
*** mixos has quit IRC22:29
*** TrevorV has quit IRC22:37
*** Aish has joined #openstack-lbaas22:41
*** rcernin has quit IRC22:45
*** rtheis has quit IRC22:49
*** alejandrito has quit IRC22:49
*** madhu_ak_ has joined #openstack-lbaas22:50
*** madhu_ak has quit IRC22:54
*** crc32 has joined #openstack-lbaas22:56
*** armax has quit IRC23:00
*** armax has joined #openstack-lbaas23:01
*** yuanying has joined #openstack-lbaas23:18
*** manishg has quit IRC23:30
*** ducttape_ has quit IRC23:37

Generated by 2.14.0 by Marius Gedminas - find it at!