Friday, 2014-11-21

johnsomThe "Docs" link off of the main Octavia wiki page is broken.  Should it be "">00:25
johnsomOr is there some other incantation that produces nicer docs with github?00:26
dougwigthe incantation would be: use markdown.  :-)00:41
johnsomWell, right now we give folks 40400:42
johnsomThough it is a very nice 404 page...  )00:42
dougwigoh, i clicked your suggestion.00:43
dougwigyeah, i'd go with yours00:43
johnsomThe Docs link from our Octavia wiki is what gives the nice 404 page currently00:48
johnsomOk, I updated it so at least we don't have a dead link.00:58
johnsomToo bad the Glossary doesn't render on github...01:00
*** crc32 has quit IRC01:03
*** xgerman has quit IRC01:07
openstackgerritMichael Johnson proposed stackforge/octavia:  Add Amphora base image creation scripts for Octavia
*** sballe has quit IRC01:58
*** SumitNaiksatam has quit IRC02:06
*** fnaval has quit IRC02:09
*** sbfox has joined #openstack-lbaas02:39
*** sbfox has quit IRC02:47
*** fnaval has joined #openstack-lbaas02:48
*** fnaval has quit IRC02:48
*** sbfox has joined #openstack-lbaas02:49
*** mwang2_ has quit IRC02:57
*** SumitNaiksatam has joined #openstack-lbaas03:00
*** sbfox has quit IRC03:04
*** sbfox has joined #openstack-lbaas03:17
*** SumitNaiksatam has quit IRC03:39
*** SumitNaiksatam has joined #openstack-lbaas03:39
*** SumitNaiksatam has quit IRC03:46
*** sbfox has quit IRC03:49
*** SumitNaiksatam has joined #openstack-lbaas03:50
*** xgerman has joined #openstack-lbaas04:06
*** sbfox has joined #openstack-lbaas04:10
*** sbfox has quit IRC04:35
*** sbfox has joined #openstack-lbaas04:47
*** xgerman has quit IRC05:06
*** ptoohill_ has quit IRC05:52
*** ptoohill has joined #openstack-lbaas06:01
*** ptoohill has quit IRC06:12
*** MasterPiece has joined #openstack-lbaas07:08
*** MasterPiece has quit IRC07:46
*** erikmoe has joined #openstack-lbaas07:54
*** MasterPiece has joined #openstack-lbaas08:47
*** woodster_ has quit IRC09:10
*** SumitNaiksatam has quit IRC09:16
*** SumitNaiksatam has joined #openstack-lbaas09:16
*** kobis has joined #openstack-lbaas09:38
*** kobis has quit IRC09:44
*** MasterPiece has quit IRC10:04
*** sbfox has quit IRC10:18
*** erikmoe has quit IRC10:56
*** erikmoe has joined #openstack-lbaas12:01
*** MasterPiece has joined #openstack-lbaas12:16
*** kobis has joined #openstack-lbaas12:17
*** kobis1 has joined #openstack-lbaas12:25
*** kobis has quit IRC12:25
*** woodster_ has joined #openstack-lbaas13:01
*** erikmoe has quit IRC13:10
*** kobis1 has quit IRC13:25
*** kobis has joined #openstack-lbaas13:26
*** MasterPiece has left #openstack-lbaas13:51
*** codekobe_ has quit IRC14:06
*** codekobe_ has joined #openstack-lbaas14:07
*** busterswt has joined #openstack-lbaas14:10
*** ctracey has quit IRC14:15
*** rm_work has quit IRC14:16
*** rm_work has joined #openstack-lbaas14:17
*** rm_work has quit IRC14:17
*** rm_work has joined #openstack-lbaas14:17
*** ctracey has joined #openstack-lbaas14:17
*** ptoohill has joined #openstack-lbaas14:52
*** ptoohill has quit IRC14:57
*** ptoohill has joined #openstack-lbaas15:02
*** sballe has joined #openstack-lbaas15:12
*** fnaval has joined #openstack-lbaas15:34
openstackgerritSusanne Balle proposed stackforge/octavia: Diagrams for operator and user API sequences
*** TrevorV_ has joined #openstack-lbaas15:41
*** markmcclain has joined #openstack-lbaas15:52
TrevorVjohnsom for some reason I was thinking ":h:i" was just argument separators, my bad h aha15:56
TrevorVha ha***15:56
openstackgerritSusanne Balle proposed stackforge/octavia: Diagrams for operator and user API sequences
*** markmcclain1 has joined #openstack-lbaas15:57
*** markmcclain has quit IRC15:59
*** woodster_ has quit IRC16:00
*** xgerman has joined #openstack-lbaas16:13
*** xgerman has quit IRC16:16
*** sbfox has joined #openstack-lbaas16:18
*** xgerman has joined #openstack-lbaas16:18
*** busterswt has quit IRC16:20
*** kobis has quit IRC16:24
*** kobis has joined #openstack-lbaas16:25
*** sbfox has quit IRC16:27
rm_workadded a link for the rendered docs via to the wiki :)16:34
rm_workwhich should be good until we get our docs gate-job set up with infra16:34
sbalukoffYou bought a domain name for the project?16:35
rm_workptoohill did, yes :P16:39
rm_workI guess I pitched in16:39
*** kobis has quit IRC16:42
*** woodster_ has joined #openstack-lbaas16:56
*** markmcclain1 has quit IRC16:58
*** markmcclain has joined #openstack-lbaas16:58
*** mlavalle has joined #openstack-lbaas17:03
*** markmcclain has quit IRC17:04
johnsomha:ha: NP TrevorV.  I updated the docs for your other comment.  Thanks for the reviews!17:11
*** kobis has joined #openstack-lbaas17:31
*** kobis has quit IRC17:31
TrevorVNo problem :D johnsom17:35
*** sbfox has joined #openstack-lbaas17:52
*** mwang2 has joined #openstack-lbaas18:12
*** kobis has joined #openstack-lbaas18:44
*** kobis has quit IRC18:50
xgermanrm_work drop me a note if you like to host on HP Cloud :-)18:51
*** Youcef has joined #openstack-lbaas18:53
*** kobis has joined #openstack-lbaas19:00
*** SumitNaiksatam has quit IRC19:04
*** kobis has quit IRC19:10
ptoohillxgerman, i'm currently running on one of our instances, and I may still update with a bot and a front page. Though it may become pointless once the gate-job is set up19:23
ptoohillI have a clb in front too :P19:23
*** SumitNaiksatam has joined #openstack-lbaas19:27
*** markmcclain has joined #openstack-lbaas19:38
*** kobis has joined #openstack-lbaas19:41
*** kobis1 has joined #openstack-lbaas19:43
*** kobis has quit IRC19:43
*** markmcclain1 has joined #openstack-lbaas19:47
*** sbfox has quit IRC20:05
bloganxgerman: keep your HP Cloud to yourself!20:06
xgermanin that case...20:07
xgermanquick question about the operator API: we are not doing anything for authentication20:07
bloganxgerman: not yet20:07
TrevorVxgerman I've left that section blank in the api docs I'm writing too20:08
xgermanyeah, I have seen you extract a couple of X values from the header :-)20:08
bloganthat can be a "feature" added in once we are actually ready to do that20:08
xgermanok, that20:08
xgerman's why we don't restrict the queries, etc. with tenant-id20:08
bloganyeah that can be added in as well20:09
blogandb layer can definitely do that20:09
xgermanyep, I am just wrapping my head around that20:09
xgermanalso v1 is what the API working froup wants :-)20:09
xgermanor do they like v1.020:10
bloganthink of it right now as a paint by numbers20:10
bloganthey haven't decided what they like yet20:10
ptoohilli hope they like v1.020:10
xgermanyeah, the operator api says v1 and I would vote for v1.020:11
xgermanso we can iterate better20:11
xgermanjust want to make sure I am not proposing blasphemie20:11
bloganim for either20:11
bloganperiods in a url path, outside of file extensions, seem odd, but i'd be fine with it20:12
a2hillit fairly common syntax though20:12
rm_workkeystone <_<20:16
*** kobis1 has quit IRC20:16
bloganwhat constitues a increment in the minor version vs the major version?20:16
xgermanfor me minor version -> old clients keep somehow working20:17
xgermanmajor verison I need a new client20:17
bloganso adding a new acceptable attribute to a request body would constitute a minor version bump?20:18
bloganor even a new feature that requires a new resource would constitute a minor version bump?20:19
xgermanin my opinion - yes20:20
bloganthe reason i ask is if we always increment the minor, then we are constantly changing the endpoint, so the only way to support all of v1, an operator has to keep all the versions active20:20
bloganall the minor versions20:20
xgermanwell, that's where the proposal with latest came in at the summit20:21
bloganas in version discoverability?20:22
xgermanbut yeah, if we add new capapbilities and the new client goes and hits an old API20:22
*** sbfox has joined #openstack-lbaas20:22
xgermanyeah --20:23
rm_workactually that does sound somewhat troubling20:23
xgermanit's a can of worms20:23
rm_workgiven that, I'd almost rather just do major versions only … what is the point of incrementing if there is no breaking change20:23
xgermannew features20:24
blogancan of worms of versioning all the data models, resources, etc20:24
blogani feel like if used well it would be a good way to actually subtract features out20:24
rm_workxgerman: i don't see the point in versioning the API for a non-breaking new feature...20:24
bloganbut the can of worms does open up20:24
rm_workat least not via something selectable like the URI20:24
rm_worksure, let a user GET /v1 and see some version data20:25
rm_workbut don't make minor versions part of the URI20:25
ptoohillYea, that does make the most sense after thinking about it and the least painful20:25
bloganthere were summit sessions on this, and it is an ongoing discussion20:25
blogansomething we can definitely talk about at the midcycle meetup20:26
ptoohillpure blasphemy20:26
xgermanyeah, I don't think there is a "right" answer20:26
bloganTrevorV: http://rst.ninjs.org20:27
bloganthe only "right" answer is we are all wrong20:27
sbalukoffI think our versioning should be based on Pink Floyd album names, starting with Ummagumma.20:33
sbalukoff(Also, sorry for my lack of visibility / activity the last few days--  have a nasty cold and have been trying to work on a cough-syrup buzz.)20:34
dougwigevery commit constitutes a minor version bump; but minor version bumps should not affect the URI at all.20:47
dougwignon-additive API changes == major version bump.20:47
rm_work^^ this20:48
*** kobis has joined #openstack-lbaas20:51
xgermanwell, as blogan said OpenStack hasn't solved that neither20:58
*** kobis has quit IRC21:00
*** jorgem has joined #openstack-lbaas21:08
blogani think our way to go forward here is to not bump the version in the url, so it simply remains as v1, but show the user the minor version in the body of the GET to /v1, or show the version in a header for every response to the user21:10
rm_workblogan, dougwig, rm_work +121:12
* rm_work just +1'd himself21:12
bloganyou just +1'ed yourself21:12
bloganyou all should do as I say21:13
blogan+1 blogan21:13
dougwigreally, it should be in the payload, but yeah.21:43
dougwigand major is the only one in the URI.21:44
rm_workyeah, seems like a solved problem to me :)21:45
dougwigbut this is openstack.  :)21:48
bloganwhen do we get the dougwig 2.0 bot?21:53
blogani dont like that bot, i feel like its insulting me all the time21:59
dougwigtoo real for you?22:01
bloganyes, its as if it really is you22:02
rm_workuncanny valley22:04
rm_workit needs to be a little more unrealistic22:05
openstackgerritTrevor Vardeman proposed stackforge/octavia: Creation of Octavia API Documentation
bloganxgerman: got a sec to discuss your comments about the network driver interface?22:07
rm_workugh, I got stuck doing this today:
xgermando you liek irc, hangout, or phone?22:07
bloganirc is fine22:07
xgerman(I know you like that the most :-)22:08
rm_workblogan: I will review your network CR now22:08
rm_work ?22:08
bloganrm_work: that is the small one so you'll be able to get through it quick, though some deep thoughts should be made22:08
bloganrm_work: correct22:08
bloganxgerman: you are suggesting the user creates the vip themselves and provides that vip to octavia?22:09
* rm_work currently has a half-drained thoughts pool22:09
rm_workdon't expect any thoughts deeper than like 4'22:09
xgermanyes, currently we have a scheme where libra gets the VIP and if we ever loose it the customers get mad at us since they need to change DNS recors22:09
xgermanso it feels the VIP should belong to the customer22:09
rm_workha, I remember that issue22:09
*** TrevorV_ has quit IRC22:10
xgermanso if they loose it they only have themselves to blame :-)22:10
blogansounds like that would be solved by floating ip though22:10
rm_workyeah, though our solution is starting to look a bit ridiculous22:10
rm_workblogan: well no, the issue being if we create the FLIP for them for their LB, and their LB gets deleted or something… then the FLIP is just gone, no retrieving it22:10
rm_worksince we'd recursively wipe it22:11
xgermanblogan, true but when I look at Horizon when I ask for a nova vm it comes with some 10.x address in some german network22:11
xgermanin a second step I attach a VIP22:11
xgermanI think lbs should work the same way22:11
bloganso you think octavia should do all that orchestration?22:11
rm_workxgerman: I read that as "some Deutsch network" before I realized you meant "some network on my account" >_>22:11
xgermanwell, the user assigns the VIP so our orchestration would be like bolt some LB into a newtork the user specifies and assign some 10.x address22:13
xgermanin that network22:13
rm_workwe could create the VIP on behalf of the user and put it on their account (instead of owned by us) and then not delete VIPs from user accounts when we clean everything else up -- but then we'd risk giving users a ton of extra public VIPs which are a valuable resource and we don't typically charge for directly22:13
xgermanyeah, and we go down the rabbit hole of delete hooks22:14
rm_workthat being a big problem -- I don't think we currently allow for users allocating themselves their own public VIPs22:14
rm_workthere just isn't a way for a user to do that22:14
xgermanok, at HP users can allocate public IPs22:14
bloganxgerman: can they specify which ip?22:14
xgermanno, they get an IP assigned22:15
rm_workit's tough to say for sure though because FLIPs aren't actually available on our deployment yet :P22:15
xgermanbut they are responsible for it22:15
rm_workmaybe when FLIPs go live at RS, the user WILL be able to create their own and be billed on each VIP22:15
xgermanand then they can use that Ip with any 10.x trhey choose22:15
xgerman(in fact I often get ssh errors when I reuse my VIP)22:15
rm_workblogan: yeah, that being the problem -- all they can do is request a VIP/FLIP, and one is generated, kind of like how nova VMs give us their IP after they spin up, but there is no way to say "i'd like this new VM to have the same IP as one of my old VMs"22:16
bloganhonestly this is more of an implementation detail of a particular implementation of the network driver22:16
rm_workblogan: but is an issue for *everyone*, I think22:16
bloganwe can have different implementations that do ownership differently22:16
rm_workthat might be necessary22:16
bloganwell we can allow that22:17
xgermanyeah, I didn't realize we did it a special way over here22:17
bloganwhat we want for an openstack octavia will be what we need to decide on22:17
rm_workbut how much MORE complication will that add?22:17
rm_workfor xgerman's second comment, that's a big difference between how things work in RS cloud and how they work in HP cloud22:17
bloganyeah whatever is cleaning this stuff up/if cleaning this stuff up, will need to know who owns it22:17
xgermanwell, since in our case the user owns it we just give them a quota :-)22:18
blogancan HP vips be re-used on cloud servers? or just on lbs?22:18
bloganessentially being flips22:18
rm_workfor the third (F5) comment, we aren't planning for multi-tenancy to BE an option, are we?22:18
rm_workblogan: servers as well22:18
xgermanwell, right now we don't have that but I envision they can be cloud servers or lbs whatever the user wants22:18
rm_workthey have actual neutron FLIPs available <_<22:19
bloganwouldn't the vip then just be a FLIP?22:19
rm_workwait, they can't? it appears from the libra code that neutron flips work as per the default neutron flip spec22:19
xgerman(have that = lbs in HP's neutron cloud)22:19
rm_workIE, you should be able to assign them to whatever?22:19
rm_workneutron floating-ip-assign22:19
xgermanyeah, in theory but our implentation makes it that the LB owns the VIP and that causes trouble22:20
xgermanso i like to move awya from that22:20
rm_workso HP nova doesn't work with that yet?22:20
rm_workit seems like you were saying it did though, in your comments22:20
bloganso if thats the case, then why don't we just require the user to create a floating ip, and then give us the flip id, and we orchestrate everything from there?22:21
xgermanwell, libra owns the ips and doesn't let the user assign them to anyhting other than the lb -- but I like that changed for Octavia22:21
rm_workyou create a VIP, you spin a server, you attach the VIP -- you can detach the VIP, spin down the server, spin up a new server, and re-use the VIP with another attach?22:21
rm_workoh, you just mean you can't re-use a LB VIP on a Nova server22:21
rm_workbecause of ownership22:21
rm_worknot that it wouldn't work "technically"22:21
rm_workyeah, k22:21
rm_workblogan: that would be the approach to take, yeah22:21
bloganokay, sounded like it was being said to create a vip object, that is essentially the same thing as a flip22:22
xgermanyeah, I always confuse the twom too22:22
rm_workyeah, HP "VIP" is a neutron floating-ip22:23
rm_workaccording to what I saw in Libra22:23
rm_workat least it uses that neutron interface, whatever it happens to be on the backend22:24
rm_workour workflow is now minimum two operations though <_<22:24
rm_workwhich is "unfortunate" but probably necessary22:24
xgermanwell, believe me when you loose a VIP the customer gets really mad22:24
rm_workor, maybe that could be handled by doing some automation in the UI22:24
rm_workfor the 99% case where the customer doesn't care22:25
rm_worka lot of these complications can really be solved pretty easily at the UI layer if it is done right22:25
rm_workwhich makes the Horizon part of Neutron-LBaaS very importanty22:25
xgermanor the 20% the Lb just routes from customer network A to network B22:25
rm_workman, our "create a LB" workflow (for worst case -- TLS Termination) now looks like: Create a FLIP. Create a set of Barbican Secrets and a CertContainer. Allow usage on Barbican Container for LBaaS Service-User. Create a LB with FLIP and CertContainer.22:26
xgermanwell, the user cna choose not to create a FLIP22:26
rm_workthat's 6 operations *minimum* for TLS T_T22:26
rm_workxgerman: ah, so it's optional, and if they don't pass one, WE make one for them?22:26
xgermanthe he can just load balance among his 10.x addresses22:26
*** SumitNaiksatam has quit IRC22:27
rm_workif they don't pass one, there just… isn't one?22:27
rm_workI don't know if that'll work for us22:27
xgermanno, if they don't make  a FLIP they can just load balance in their own network22:27
rm_workwe rely on the FLIP for all of the scaling <_<22:27
rm_workwithout a FLIP there's no way to tie in more than one Amphora22:27
rm_workat least in our design, the FLIP is what branches out from 1-n for n Amphorae22:28
xgermanright, so it seems you would always assign some 10.x Flip and give that to the user so he can then put some real IP on it?22:28
rm_workah, err22:28
rm_workin our system, the FLIP kinda has to be the frontend, I think22:28
rm_workwe wouldn't have any kind of "thing" they could actually create or point to the FLIP if the FLIP was internal22:29
rm_workblogan: ?22:29
rm_workare you following, or AFK/distracted?22:29
xgermanso how would you let somebody load balance among his 10.x addresses aka a one-legged LB22:31
*** SumitNaiksatam has joined #openstack-lbaas22:31
blogani'd assume we would have a flip pointed to a port with a 10.x fixed ip, and that is the "real" vip of the LB22:32
bloganor am i misunderstanding22:32
dougwigthat question becomes, "how in your api do you plumb the amphora in to the member's L2 segments, so you can one-arm the replies?"22:33
xgermanok, I was thinking our lbs would be known to the user by their 10.x and if the user wants a public ip he goes gets one, and asks for the natting22:33
bloganwouldn't that be what floatign ip does though?22:33
xgermanyeah, a floating IP from the public IP range22:34
bloganfloating ip would be teh public ip, and the lb's vip would be a private ip, and just point the flip at the vip22:34
xgermanyeah, and our delivery would stop at providing a private ip22:35
dougwigone-legged has the replies going out direct; that wouldn't work in that scenario.22:35
xgermanthe rest would be up to the user and neutron22:35
blogandougwig: could you explain that to me more, as if I am a 5 year old22:36
dougwigone-arm is essentially LB at the L2 layer.  client goes into the vip, is proxied to the backend member, and the backend member responds directly to the initial client.  saves a bunch of bandwidth/processing from ever touching the LB, at the cost of being able to monkey with the outbound traffic.  i'm not sure how much sense that mode makes in a commodity22:38
dougwigcloud environment.22:38
bloganah so my understanding of one-armed was totally wrong lol22:39
xgermanwell, I said one legged - but I might be misuning the term. For mew it means Lb and nodes are on the same network22:40
* blogan shoots himself22:40
xgermanand LB only has one network connection22:40
bloganxgerman: thats what i was thinking too22:40
xgermanlet's rewrite history :-)22:40
xgermanblogan I gather we are sort of on the same page but got confused by terms22:41
bloganyeah, our current lb offering is not one-appendaged22:42
rm_workblogan: ok but no -- sec22:42
rm_work<blogan> floating ip would be teh public ip, and the lb's vip would be a private ip, and just point the flip at the vip22:42
rm_workthis doesn't work22:42
rm_workthe LB doesn't *have* a single private IP22:42
rm_workunless that is *another FLIP*22:43
xgermanis that an implementation detail?22:43
rm_workbut AFAIK the FLIPpers will all be on the edge22:43
rm_workmeaning, no such thing as a private network FLIP22:43
rm_workxgerman: maybe, maybe not22:43
bloganyeah flips have to be on an "external" network22:43
rm_workblogan: right, so there is no "LB's private VIP"22:43
bloganbut for what we want at RAX, we won't be dong a private vip22:44
bloganhowever a default openstack one would probably use a private vip22:44
rm_workyeah ok22:44
bloganopenstack only allows you to point a flip to one port22:44
rm_workI guess I can see that, but all of these interfaces with nothing concrete behind them besides each deployer's private driver, are starting to make me go a bit nuts22:45
xgermanyeah, also we should cover the case where somebody doesn't want HA and just has ONE amphora22:46
bloganyeah im not sure that has to be decided by the network driver22:47
bloganthat will be the job of some controller job22:47
xgermanyep, but the implementation of our great HA schemes will be behinf that 10.x. address22:48
rm_workyeah so HP will have some middle address handling the scaling22:48
rm_workand RS will have one frontend address handing the scaling22:48
bloganwhich limits us into only public vips22:49
bloganbut they know this22:49
xgermanyeah, we don't like to be limited :-)22:49
xgermanand Bluebox run lvm on some aphora22:49
xgermanwhich would fit the 10.x model also22:49
bloganyeah ours will be the outlier of course22:50
bloganbtw i am off all next week, so I won't be as responsive22:50
bloganbut ill still be responsive22:50
xgermanok, johnsonm is off as well22:51
bloganexcept on thursday in which i will be in a food coma while in a football viewing coma22:51
xgermanalso to switch gears on the network22:51
xgermanthe endgame is probably to be more like AMZNB and give out dns names22:51
xgerman(to also enable datacsnter failovers)22:52
xgermanbut I haven't put too much thought into that22:52
bloganyeah that can be solved for later, it would be a nice feature22:52
*** ptoohill has quit IRC22:53
rm_workyeah that is GLB22:53
bloganmore calls to antoher api22:53
bloganwell GLB can also pick the closest datacenter22:53
rm_workif you want GEO algorithm22:53
rm_workit took me a while to really get it in my head that GLB != Geographic Algorithm, that's just one option22:53
rm_workbut yeah22:53
xgermanyeah, so the user wouldn't see an IP but some dns name22:54
xgermanand then we can do whatever we want with the IP22:54
xgermanif we loose it we just change the A record22:54
*** mestery has quit IRC22:55
*** mestery has joined #openstack-lbaas22:56
rm_workyeah though the possible downtime associated with that for DNS is blegh22:58
xgermanhence we would need some secret sauce (and hence the customers whose public Ip we loose hate us)22:58
*** jorgem has quit IRC23:00
blogani have a feeling hte network driver and all that won't get settled on until the hackathon23:03
bloganwhich is why i am glad we are having the hackathon, bc we need to have high bandwidth decisions made23:04
xgermanand my opinion is not ncessarily what the rest of HP thinks :-)23:04
*** mlavalle has quit IRC23:04
bloganha well im just hoping we can define a generic enough interface that will work for everyone's needs23:05
bloganand if the default openstack implementation of that interface does not work for everyone, they'll have to do their own, which we at RAX have already accepted23:05
bloganwe also will need to think about how we store the resource information so that everything can be retrieved again, which i'm thinking may lead us down the path of having a blob column23:07
bloganwhich i would hate but it might be necessary to achieve what is needed23:07
xgermansame here - no blobs = goodness23:09
bloganalright i am leaving home23:09
blogani mean leaving for home23:09
rm_workwe can do provisional table/column adjustments, for proprietary stuff, I think23:10
rm_workto avoid blobs… blobs == devil23:10
rm_workmost of the SQLAlchemy stuff is pretty magical with regards to not blowing up if you happen to not specify a column somewhere, etc23:11
*** sbfox has quit IRC23:15
openstackgerritStephen Balukoff proposed stackforge/octavia: Specification of reference haproxy amphora API
*** SumitNaiksatam has quit IRC23:31
sbalukoffHoly moly, wall of text!23:34
sbalukoffYes, GLB is (so far) beyond the scope of Octavia. Maybe we'll do that with Octavia v3. Maybe it'll be its own project.23:34
sbalukoffOpenStack will definitely want a GLB solution, but so far I see Octavia being written / suitable for a single-datacenter usage scenario. GLB could be built on top of Octavia, of course, but it doesn't have to be the same project.23:35
*** kobis has joined #openstack-lbaas23:37
sbalukoffAlso, as long as we're using haproxy for our reference, one-legged deployments (ie. direct response from back-end node) doesn't work. haproxy initiates a new session to each back-end host using its own address as the source, and isn't really meant to operate in "transparent" mode or whatever you want to call one-legged.23:37
sbalukoffOtherwise, yes... I see that we're going to have to have some interesting topology discussions given the differences in our environments.23:38
*** kobis has quit IRC23:41

Generated by 2.14.0 by Marius Gedminas - find it at!