| johnsom | The "Docs" link off of the main Octavia wiki page is broken. Should it be "https://github.com/stackforge/octavia/tree/master/doc"> | 00:25 |
|---|---|---|
| johnsom | ? | 00:25 |
| johnsom | Or is there some other incantation that produces nicer docs with github? | 00:26 |
| dougwig | the incantation would be: use markdown. :-) | 00:41 |
| johnsom | Well, right now we give folks 404 | 00:42 |
| johnsom | Though it is a very nice 404 page... ) | 00:42 |
| dougwig | really? | 00:42 |
| dougwig | https://github.com/stackforge/octavia/blob/master/doc/source/design/version0.5/component-design.rst | 00:42 |
| dougwig | oh, i clicked your suggestion. | 00:43 |
| dougwig | yeah, i'd go with yours | 00:43 |
| johnsom | The Docs link from our Octavia wiki https://wiki.openstack.org/wiki/Octavia is what gives the nice 404 page currently | 00:48 |
| johnsom | Ok, I updated it so at least we don't have a dead link. | 00:58 |
| johnsom | Too bad the Glossary doesn't render on github... | 01:00 |
| *** crc32 has quit IRC | 01:03 | |
| *** xgerman has quit IRC | 01:07 | |
| openstackgerrit | Michael Johnson proposed stackforge/octavia: Add Amphora base image creation scripts for Octavia https://review.openstack.org/132904 | 01:14 |
| *** sballe has quit IRC | 01:58 | |
| *** SumitNaiksatam has quit IRC | 02:06 | |
| *** fnaval has quit IRC | 02:09 | |
| *** sbfox has joined #openstack-lbaas | 02:39 | |
| *** sbfox has quit IRC | 02:47 | |
| *** fnaval has joined #openstack-lbaas | 02:48 | |
| *** fnaval has quit IRC | 02:48 | |
| *** sbfox has joined #openstack-lbaas | 02:49 | |
| *** mwang2_ has quit IRC | 02:57 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 03:00 | |
| *** sbfox has quit IRC | 03:04 | |
| *** sbfox has joined #openstack-lbaas | 03:17 | |
| *** SumitNaiksatam has quit IRC | 03:39 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 03:39 | |
| *** SumitNaiksatam has quit IRC | 03:46 | |
| *** sbfox has quit IRC | 03:49 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 03:50 | |
| *** xgerman has joined #openstack-lbaas | 04:06 | |
| *** sbfox has joined #openstack-lbaas | 04:10 | |
| *** sbfox has quit IRC | 04:35 | |
| *** sbfox has joined #openstack-lbaas | 04:47 | |
| *** xgerman has quit IRC | 05:06 | |
| *** ptoohill_ has quit IRC | 05:52 | |
| *** ptoohill has joined #openstack-lbaas | 06:01 | |
| *** ptoohill has quit IRC | 06:12 | |
| *** MasterPiece has joined #openstack-lbaas | 07:08 | |
| *** MasterPiece has quit IRC | 07:46 | |
| *** erikmoe has joined #openstack-lbaas | 07:54 | |
| *** MasterPiece has joined #openstack-lbaas | 08:47 | |
| *** woodster_ has quit IRC | 09:10 | |
| *** SumitNaiksatam has quit IRC | 09:16 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 09:16 | |
| *** kobis has joined #openstack-lbaas | 09:38 | |
| *** kobis has quit IRC | 09:44 | |
| *** MasterPiece has quit IRC | 10:04 | |
| *** sbfox has quit IRC | 10:18 | |
| *** erikmoe has quit IRC | 10:56 | |
| *** erikmoe has joined #openstack-lbaas | 12:01 | |
| *** MasterPiece has joined #openstack-lbaas | 12:16 | |
| *** kobis has joined #openstack-lbaas | 12:17 | |
| *** kobis1 has joined #openstack-lbaas | 12:25 | |
| *** kobis has quit IRC | 12:25 | |
| *** woodster_ has joined #openstack-lbaas | 13:01 | |
| *** erikmoe has quit IRC | 13:10 | |
| *** kobis1 has quit IRC | 13:25 | |
| *** kobis has joined #openstack-lbaas | 13:26 | |
| *** MasterPiece has left #openstack-lbaas | 13:51 | |
| *** codekobe_ has quit IRC | 14:06 | |
| *** codekobe_ has joined #openstack-lbaas | 14:07 | |
| *** busterswt has joined #openstack-lbaas | 14:10 | |
| *** ctracey has quit IRC | 14:15 | |
| *** rm_work has quit IRC | 14:16 | |
| *** rm_work has joined #openstack-lbaas | 14:17 | |
| *** rm_work has quit IRC | 14:17 | |
| *** rm_work has joined #openstack-lbaas | 14:17 | |
| *** ctracey has joined #openstack-lbaas | 14:17 | |
| *** ptoohill has joined #openstack-lbaas | 14:52 | |
| *** ptoohill has quit IRC | 14:57 | |
| *** ptoohill has joined #openstack-lbaas | 15:02 | |
| *** sballe has joined #openstack-lbaas | 15:12 | |
| *** fnaval has joined #openstack-lbaas | 15:34 | |
| openstackgerrit | Susanne Balle proposed stackforge/octavia: Diagrams for operator and user API sequences https://review.openstack.org/132130 | 15:36 |
| *** TrevorV_ has joined #openstack-lbaas | 15:41 | |
| *** markmcclain has joined #openstack-lbaas | 15:52 | |
| TrevorV | johnsom for some reason I was thinking ":h:i" was just argument separators, my bad h aha | 15:56 |
| TrevorV | ha ha*** | 15:56 |
| openstackgerrit | Susanne Balle proposed stackforge/octavia: Diagrams for operator and user API sequences https://review.openstack.org/132130 | 15:57 |
| *** markmcclain1 has joined #openstack-lbaas | 15:57 | |
| blogan | h:a:h:a | 15:59 |
| *** markmcclain has quit IRC | 15:59 | |
| *** woodster_ has quit IRC | 16:00 | |
| *** xgerman has joined #openstack-lbaas | 16:13 | |
| *** xgerman has quit IRC | 16:16 | |
| *** sbfox has joined #openstack-lbaas | 16:18 | |
| *** xgerman has joined #openstack-lbaas | 16:18 | |
| *** busterswt has quit IRC | 16:20 | |
| *** kobis has quit IRC | 16:24 | |
| *** kobis has joined #openstack-lbaas | 16:25 | |
| *** sbfox has quit IRC | 16:27 | |
| rm_work | added a link for the rendered docs via octavia.io to the wiki :) | 16:34 |
| rm_work | which should be good until we get our docs gate-job set up with infra | 16:34 |
| sbalukoff | octavia.io? | 16:34 |
| sbalukoff | You bought a domain name for the project? | 16:35 |
| rm_work | ptoohill did, yes :P | 16:39 |
| rm_work | I guess I pitched in | 16:39 |
| a2hill | :P | 16:39 |
| *** kobis has quit IRC | 16:42 | |
| *** woodster_ has joined #openstack-lbaas | 16:56 | |
| *** markmcclain1 has quit IRC | 16:58 | |
| *** markmcclain has joined #openstack-lbaas | 16:58 | |
| *** mlavalle has joined #openstack-lbaas | 17:03 | |
| *** markmcclain has quit IRC | 17:04 | |
| johnsom | ha:ha: NP TrevorV. I updated the docs for your other comment. Thanks for the reviews! | 17:11 |
| *** kobis has joined #openstack-lbaas | 17:31 | |
| *** kobis has quit IRC | 17:31 | |
| TrevorV | No problem :D johnsom | 17:35 |
| *** sbfox has joined #openstack-lbaas | 17:52 | |
| *** mwang2 has joined #openstack-lbaas | 18:12 | |
| *** kobis has joined #openstack-lbaas | 18:44 | |
| *** kobis has quit IRC | 18:50 | |
| xgerman | rm_work drop me a note if you like to host octavia.io on HP Cloud :-) | 18:51 |
| *** Youcef has joined #openstack-lbaas | 18:53 | |
| *** kobis has joined #openstack-lbaas | 19:00 | |
| *** SumitNaiksatam has quit IRC | 19:04 | |
| *** kobis has quit IRC | 19:10 | |
| ptoohill | xgerman, 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 up | 19:23 |
| ptoohill | I have a clb in front too :P | 19:23 |
| *** SumitNaiksatam has joined #openstack-lbaas | 19:27 | |
| *** markmcclain has joined #openstack-lbaas | 19:38 | |
| *** kobis has joined #openstack-lbaas | 19:41 | |
| *** kobis1 has joined #openstack-lbaas | 19:43 | |
| *** kobis has quit IRC | 19:43 | |
| *** markmcclain1 has joined #openstack-lbaas | 19:47 | |
| *** sbfox has quit IRC | 20:05 | |
| blogan | xgerman: keep your HP Cloud to yourself! | 20:06 |
| xgerman | in that case... | 20:07 |
| xgerman | quick question about the operator API: we are not doing anything for authentication | 20:07 |
| xgerman | ? | 20:07 |
| blogan | xgerman: not yet | 20:07 |
| TrevorV | xgerman I've left that section blank in the api docs I'm writing too | 20:08 |
| xgerman | yeah, I have seen you extract a couple of X values from the header :-) | 20:08 |
| blogan | that can be a "feature" added in once we are actually ready to do that | 20:08 |
| xgerman | ok, that | 20:08 |
| xgerman | 's why we don't restrict the queries, etc. with tenant-id | 20:08 |
| blogan | yeah that can be added in as well | 20:09 |
| blogan | db layer can definitely do that | 20:09 |
| xgerman | yep, I am just wrapping my head around that | 20:09 |
| xgerman | also v1 is what the API working froup wants :-) | 20:09 |
| xgerman | ? | 20:10 |
| xgerman | or do they like v1.0 | 20:10 |
| blogan | think of it right now as a paint by numbers | 20:10 |
| blogan | they haven't decided what they like yet | 20:10 |
| ptoohill | i hope they like v1.0 | 20:10 |
| xgerman | yeah, the operator api says v1 and I would vote for v1.0 | 20:11 |
| xgerman | so we can iterate better | 20:11 |
| xgerman | just want to make sure I am not proposing blasphemie | 20:11 |
| blogan | nah | 20:11 |
| blogan | im for either | 20:11 |
| blogan | periods in a url path, outside of file extensions, seem odd, but i'd be fine with it | 20:12 |
| a2hill | it fairly common syntax though | 20:12 |
| xgerman | yep | 20:13 |
| rm_work | keystone <_< | 20:16 |
| *** kobis1 has quit IRC | 20:16 | |
| blogan | what constitues a increment in the minor version vs the major version? | 20:16 |
| xgerman | for me minor version -> old clients keep somehow working | 20:17 |
| xgerman | major verison I need a new client | 20:17 |
| blogan | so adding a new acceptable attribute to a request body would constitute a minor version bump? | 20:18 |
| blogan | or even a new feature that requires a new resource would constitute a minor version bump? | 20:19 |
| xgerman | in my opinion - yes | 20:20 |
| blogan | the 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 active | 20:20 |
| blogan | all the minor versions | 20:20 |
| xgerman | well, that's where the proposal with latest came in at the summit | 20:21 |
| blogan | as in version discoverability? | 20:22 |
| xgerman | but yeah, if we add new capapbilities and the new client goes and hits an old API | 20:22 |
| *** sbfox has joined #openstack-lbaas | 20:22 | |
| xgerman | yeah -- | 20:23 |
| rm_work | actually that does sound somewhat troubling | 20:23 |
| xgerman | it's a can of worms | 20:23 |
| rm_work | given that, I'd almost rather just do major versions only … what is the point of incrementing if there is no breaking change | 20:23 |
| rm_work | ? | 20:24 |
| xgerman | new features | 20:24 |
| blogan | can of worms of versioning all the data models, resources, etc | 20:24 |
| blogan | i feel like if used well it would be a good way to actually subtract features out | 20:24 |
| rm_work | xgerman: i don't see the point in versioning the API for a non-breaking new feature... | 20:24 |
| blogan | but the can of worms does open up | 20:24 |
| rm_work | at least not via something selectable like the URI | 20:24 |
| rm_work | sure, let a user GET /v1 and see some version data | 20:25 |
| rm_work | but don't make minor versions part of the URI | 20:25 |
| ptoohill | Yea, that does make the most sense after thinking about it and the least painful | 20:25 |
| blogan | there were summit sessions on this, and it is an ongoing discussion | 20:25 |
| blogan | something we can definitely talk about at the midcycle meetup | 20:26 |
| ptoohill | pure blasphemy | 20:26 |
| xgerman | yeah, I don't think there is a "right" answer | 20:26 |
| blogan | TrevorV: http://rst.ninjs.org | 20:27 |
| blogan | the only "right" answer is we are all wrong | 20:27 |
| sbalukoff | Heh! | 20:33 |
| sbalukoff | I think our versioning should be based on Pink Floyd album names, starting with Ummagumma. | 20:33 |
| xgerman | ;-) | 20:34 |
| 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 |
| dougwig | every commit constitutes a minor version bump; but minor version bumps should not affect the URI at all. | 20:47 |
| dougwig | non-additive API changes == major version bump. | 20:47 |
| rm_work | ^^ this | 20:48 |
| *** kobis has joined #openstack-lbaas | 20:51 | |
| xgerman | well, as blogan said OpenStack hasn't solved that neither | 20:58 |
| *** kobis has quit IRC | 21:00 | |
| *** jorgem has joined #openstack-lbaas | 21:08 | |
| blogan | i 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 user | 21:10 |
| rm_work | yep | 21:12 |
| rm_work | blogan, dougwig, rm_work +1 | 21:12 |
| * rm_work just +1'd himself | 21:12 | |
| blogan | you just +1'ed yourself | 21:12 |
| rm_work | yes-sir-e-bob | 21:13 |
| blogan | you all should do as I say | 21:13 |
| blogan | +1 blogan | 21:13 |
| dougwig | really, it should be major.minor.build in the payload, but yeah. | 21:43 |
| dougwig | and major is the only one in the URI. | 21:44 |
| rm_work | yeah, seems like a solved problem to me :) | 21:45 |
| dougwig | but this is openstack. :) | 21:48 |
| sbalukoff | Heh! | 21:52 |
| blogan | when do we get the dougwig 2.0 bot? | 21:53 |
| dougwig | doesdouglikeit.com | 21:53 |
| blogan | i dont like that bot, i feel like its insulting me all the time | 21:59 |
| dougwig | too real for you? | 22:01 |
| blogan | yes, its as if it really is you | 22:02 |
| rm_work | uncanny valley | 22:04 |
| rm_work | it needs to be a little more unrealistic | 22:05 |
| openstackgerrit | Trevor Vardeman proposed stackforge/octavia: Creation of Octavia API Documentation https://review.openstack.org/136499 | 22:06 |
| blogan | xgerman: got a sec to discuss your comments about the network driver interface? | 22:07 |
| xgerman | yep | 22:07 |
| rm_work | ugh, I got stuck doing this today: https://review.openstack.org/136498 | 22:07 |
| xgerman | do you liek irc, hangout, or phone? | 22:07 |
| blogan | irc is fine | 22:07 |
| xgerman | ok | 22:07 |
| xgerman | (I know you like that the most :-) | 22:08 |
| blogan | lol | 22:08 |
| rm_work | blogan: I will review your network CR now | 22:08 |
| rm_work | https://review.openstack.org/#/c/135495/ ? | 22:08 |
| blogan | rm_work: that is the small one so you'll be able to get through it quick, though some deep thoughts should be made | 22:08 |
| blogan | rm_work: correct | 22:08 |
| blogan | xgerman: 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 pool | 22:09 | |
| rm_work | don't expect any thoughts deeper than like 4' | 22:09 |
| xgerman | yes, 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 recors | 22:09 |
| xgerman | so it feels the VIP should belong to the customer | 22:09 |
| rm_work | ha, I remember that issue | 22:09 |
| *** TrevorV_ has quit IRC | 22:10 | |
| xgerman | so if they loose it they only have themselves to blame :-) | 22:10 |
| blogan | sounds like that would be solved by floating ip though | 22:10 |
| rm_work | yeah, though our solution is starting to look a bit ridiculous | 22:10 |
| rm_work | blogan: 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 it | 22:10 |
| rm_work | since we'd recursively wipe it | 22:11 |
| xgerman | blogan, true but when I look at Horizon when I ask for a nova vm it comes with some 10.x address in some german network | 22:11 |
| xgerman | in a second step I attach a VIP | 22:11 |
| xgerman | I think lbs should work the same way | 22:11 |
| blogan | so you think octavia should do all that orchestration? | 22:11 |
| rm_work | xgerman: I read that as "some Deutsch network" before I realized you meant "some network on my account" >_> | 22:11 |
| xgerman | well, 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 address | 22:13 |
| xgerman | in that network | 22:13 |
| rm_work | we 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 directly | 22:13 |
| xgerman | yeah, and we go down the rabbit hole of delete hooks | 22:14 |
| rm_work | that being a big problem -- I don't think we currently allow for users allocating themselves their own public VIPs | 22:14 |
| blogan | yep | 22:14 |
| rm_work | there just isn't a way for a user to do that | 22:14 |
| xgerman | ok, at HP users can allocate public IPs | 22:14 |
| rm_work | AFAIK | 22:14 |
| blogan | xgerman: can they specify which ip? | 22:14 |
| xgerman | no, they get an IP assigned | 22:15 |
| rm_work | it's tough to say for sure though because FLIPs aren't actually available on our deployment yet :P | 22:15 |
| xgerman | but they are responsible for it | 22:15 |
| rm_work | maybe when FLIPs go live at RS, the user WILL be able to create their own and be billed on each VIP | 22:15 |
| rm_work | *FLIP | 22:15 |
| xgerman | and then they can use that Ip with any 10.x trhey choose | 22:15 |
| xgerman | (in fact I often get ssh errors when I reuse my VIP) | 22:15 |
| rm_work | blogan: 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 |
| blogan | honestly this is more of an implementation detail of a particular implementation of the network driver | 22:16 |
| rm_work | blogan: but is an issue for *everyone*, I think | 22:16 |
| blogan | we can have different implementations that do ownership differently | 22:16 |
| rm_work | that might be necessary | 22:16 |
| blogan | well we can allow that | 22:17 |
| xgerman | yeah, I didn't realize we did it a special way over here | 22:17 |
| blogan | what we want for an openstack octavia will be what we need to decide on | 22:17 |
| rm_work | but how much MORE complication will that add? | 22:17 |
| rm_work | for xgerman's second comment, that's a big difference between how things work in RS cloud and how they work in HP cloud | 22:17 |
| blogan | yeah whatever is cleaning this stuff up/if cleaning this stuff up, will need to know who owns it | 22:17 |
| xgerman | well, since in our case the user owns it we just give them a quota :-) | 22:18 |
| blogan | can HP vips be re-used on cloud servers? or just on lbs? | 22:18 |
| blogan | essentially being flips | 22:18 |
| rm_work | for the third (F5) comment, we aren't planning for multi-tenancy to BE an option, are we? | 22:18 |
| rm_work | blogan: servers as well | 22:18 |
| xgerman | well, right now we don't have that but I envision they can be cloud servers or lbs whatever the user wants | 22:18 |
| rm_work | they have actual neutron FLIPs available <_< | 22:19 |
| blogan | wouldn't the vip then just be a FLIP? | 22:19 |
| rm_work | wait, they can't? it appears from the libra code that neutron flips work as per the default neutron flip spec | 22:19 |
| xgerman | (have that = lbs in HP's neutron cloud) | 22:19 |
| rm_work | IE, you should be able to assign them to whatever? | 22:19 |
| rm_work | neutron floating-ip-assign | 22:19 |
| xgerman | yeah, in theory but our implentation makes it that the LB owns the VIP and that causes trouble | 22:20 |
| rm_work | ah | 22:20 |
| xgerman | so i like to move awya from that | 22:20 |
| rm_work | so HP nova doesn't work with that yet? | 22:20 |
| rm_work | it seems like you were saying it did though, in your comments | 22:20 |
| blogan | so 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 |
| xgerman | well, libra owns the ips and doesn't let the user assign them to anyhting other than the lb -- but I like that changed for Octavia | 22:21 |
| rm_work | you 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_work | oh, you just mean you can't re-use a LB VIP on a Nova server | 22:21 |
| rm_work | because of ownership | 22:21 |
| xgerman | yep | 22:21 |
| rm_work | not that it wouldn't work "technically" | 22:21 |
| rm_work | yeah, k | 22:21 |
| rm_work | blogan: that would be the approach to take, yeah | 22:21 |
| blogan | okay, sounded like it was being said to create a vip object, that is essentially the same thing as a flip | 22:22 |
| xgerman | yeah, I always confuse the twom too | 22:22 |
| rm_work | yeah, HP "VIP" is a neutron floating-ip | 22:23 |
| rm_work | according to what I saw in Libra | 22:23 |
| rm_work | at least it uses that neutron interface, whatever it happens to be on the backend | 22:24 |
| rm_work | our workflow is now minimum two operations though <_< | 22:24 |
| rm_work | which is "unfortunate" but probably necessary | 22:24 |
| xgerman | well, believe me when you loose a VIP the customer gets really mad | 22:24 |
| rm_work | or, maybe that could be handled by doing some automation in the UI | 22:24 |
| rm_work | for the 99% case where the customer doesn't care | 22:25 |
| rm_work | a lot of these complications can really be solved pretty easily at the UI layer if it is done right | 22:25 |
| rm_work | which makes the Horizon part of Neutron-LBaaS very importanty | 22:25 |
| xgerman | or the 20% the Lb just routes from customer network A to network B | 22:25 |
| rm_work | man, 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 |
| xgerman | well, the user cna choose not to create a FLIP | 22:26 |
| rm_work | that's 6 operations *minimum* for TLS T_T | 22:26 |
| rm_work | xgerman: ah, so it's optional, and if they don't pass one, WE make one for them? | 22:26 |
| xgerman | the he can just load balance among his 10.x addresses | 22:26 |
| rm_work | oh | 22:27 |
| *** SumitNaiksatam has quit IRC | 22:27 | |
| rm_work | if they don't pass one, there just… isn't one? | 22:27 |
| rm_work | I don't know if that'll work for us | 22:27 |
| xgerman | no, if they don't make a FLIP they can just load balance in their own network | 22:27 |
| rm_work | we rely on the FLIP for all of the scaling <_< | 22:27 |
| rm_work | without a FLIP there's no way to tie in more than one Amphora | 22:27 |
| rm_work | at least in our design, the FLIP is what branches out from 1-n for n Amphorae | 22:28 |
| xgerman | right, 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_work | ah, err | 22:28 |
| rm_work | well | 22:28 |
| rm_work | in our system, the FLIP kinda has to be the frontend, I think | 22:28 |
| rm_work | we wouldn't have any kind of "thing" they could actually create or point to the FLIP if the FLIP was internal | 22:29 |
| rm_work | blogan: ? | 22:29 |
| rm_work | are you following, or AFK/distracted? | 22:29 |
| blogan | distracted | 22:30 |
| blogan | darts | 22:30 |
| blogan | dartstracted | 22:30 |
| xgerman | lol | 22:30 |
| xgerman | so how would you let somebody load balance among his 10.x addresses aka a one-legged LB | 22:31 |
| *** SumitNaiksatam has joined #openstack-lbaas | 22:31 | |
| blogan | i'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 LB | 22:32 |
| blogan | or am i misunderstanding | 22:32 |
| dougwig | that 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 |
| xgerman | ok, 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 natting | 22:33 |
| blogan | wouldn't that be what floatign ip does though? | 22:33 |
| xgerman | yeah, a floating IP from the public IP range | 22:34 |
| 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 vip | 22:34 |
| xgerman | yeah, and our delivery would stop at providing a private ip | 22:35 |
| dougwig | one-legged has the replies going out direct; that wouldn't work in that scenario. | 22:35 |
| xgerman | the rest would be up to the user and neutron | 22:35 |
| blogan | dougwig: could you explain that to me more, as if I am a 5 year old | 22:36 |
| dougwig | one-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 commodity | 22:38 |
| dougwig | cloud environment. | 22:38 |
| blogan | ah so my understanding of one-armed was totally wrong lol | 22:39 |
| xgerman | well, I said one legged - but I might be misuning the term. For mew it means Lb and nodes are on the same network | 22:40 |
| * blogan shoots himself | 22:40 | |
| xgerman | and LB only has one network connection | 22:40 |
| blogan | xgerman: thats what i was thinking too | 22:40 |
| xgerman | let's rewrite history :-) | 22:40 |
| xgerman | blogan I gather we are sort of on the same page but got confused by terms | 22:41 |
| blogan | yeah, our current lb offering is not one-appendaged | 22:42 |
| rm_work | blogan: ok but no -- sec | 22: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 vip | 22:42 |
| rm_work | this doesn't work | 22:42 |
| rm_work | the LB doesn't *have* a single private IP | 22:42 |
| rm_work | unless that is *another FLIP* | 22:43 |
| xgerman | is that an implementation detail? | 22:43 |
| rm_work | but AFAIK the FLIPpers will all be on the edge | 22:43 |
| rm_work | meaning, no such thing as a private network FLIP | 22:43 |
| rm_work | xgerman: maybe, maybe not | 22:43 |
| blogan | yeah flips have to be on an "external" network | 22:43 |
| rm_work | blogan: right, so there is no "LB's private VIP" | 22:43 |
| blogan | but for what we want at RAX, we won't be dong a private vip | 22:44 |
| rm_work | exactly. | 22:44 |
| blogan | however a default openstack one would probably use a private vip | 22:44 |
| rm_work | ugh | 22:44 |
| rm_work | yeah ok | 22:44 |
| blogan | openstack only allows you to point a flip to one port | 22:44 |
| rm_work | I 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 nuts | 22:45 |
| xgerman | yeah, also we should cover the case where somebody doesn't want HA and just has ONE amphora | 22:46 |
| blogan | yeah im not sure that has to be decided by the network driver | 22:47 |
| blogan | that will be the job of some controller job | 22:47 |
| xgerman | yep, but the implementation of our great HA schemes will be behinf that 10.x. address | 22:48 |
| rm_work | yeah so HP will have some middle address handling the scaling | 22:48 |
| rm_work | and RS will have one frontend address handing the scaling | 22:48 |
| xgerman | potentially | 22:49 |
| blogan | which limits us into only public vips | 22:49 |
| rm_work | yep | 22:49 |
| blogan | but they know this | 22:49 |
| xgerman | yeah, we don't like to be limited :-) | 22:49 |
| xgerman | and Bluebox run lvm on some aphora | 22:49 |
| xgerman | which would fit the 10.x model also | 22:49 |
| blogan | yeah ours will be the outlier of course | 22:50 |
| rm_work | T_T | 22:50 |
| blogan | btw i am off all next week, so I won't be as responsive | 22:50 |
| blogan | but ill still be responsive | 22:50 |
| xgerman | ok, johnsonm is off as well | 22:51 |
| blogan | except on thursday in which i will be in a food coma while in a football viewing coma | 22:51 |
| xgerman | also to switch gears on the network | 22:51 |
| xgerman | the endgame is probably to be more like AMZNB and give out dns names | 22:51 |
| xgerman | (to also enable datacsnter failovers) | 22:52 |
| blogan | glb | 22:52 |
| xgerman | but I haven't put too much thought into that | 22:52 |
| blogan | yeah that can be solved for later, it would be a nice feature | 22:52 |
| *** ptoohill has quit IRC | 22:53 | |
| rm_work | yeah that is GLB | 22:53 |
| blogan | more calls to antoher api | 22:53 |
| blogan | well GLB can also pick the closest datacenter | 22:53 |
| rm_work | if you want GEO algorithm | 22:53 |
| rm_work | it took me a while to really get it in my head that GLB != Geographic Algorithm, that's just one option | 22:53 |
| rm_work | but yeah | 22:53 |
| xgerman | yeah, so the user wouldn't see an IP but some dns name | 22:54 |
| xgerman | and then we can do whatever we want with the IP | 22:54 |
| xgerman | if we loose it we just change the A record | 22:54 |
| *** mestery has quit IRC | 22:55 | |
| *** mestery has joined #openstack-lbaas | 22:56 | |
| rm_work | yeah though the possible downtime associated with that for DNS is blegh | 22:58 |
| xgerman | yep | 22:58 |
| xgerman | hence we would need some secret sauce (and hence the customers whose public Ip we loose hate us) | 22:58 |
| *** jorgem has quit IRC | 23:00 | |
| blogan | i have a feeling hte network driver and all that won't get settled on until the hackathon | 23:03 |
| blogan | which is why i am glad we are having the hackathon, bc we need to have high bandwidth decisions made | 23:04 |
| xgerman | agreed | 23:04 |
| xgerman | and my opinion is not ncessarily what the rest of HP thinks :-) | 23:04 |
| *** mlavalle has quit IRC | 23:04 | |
| blogan | ha well im just hoping we can define a generic enough interface that will work for everyone's needs | 23:05 |
| blogan | and 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 accepted | 23:05 |
| blogan | we 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 column | 23:07 |
| blogan | which i would hate but it might be necessary to achieve what is needed | 23:07 |
| xgerman | same here - no blobs = goodness | 23:09 |
| blogan | alright i am leaving home | 23:09 |
| blogan | i mean leaving for home | 23:09 |
| blogan | laters | 23:09 |
| xgerman | l8ter | 23:10 |
| rm_work | we can do provisional table/column adjustments, for proprietary stuff, I think | 23:10 |
| rm_work | to avoid blobs… blobs == devil | 23:10 |
| rm_work | most of the SQLAlchemy stuff is pretty magical with regards to not blowing up if you happen to not specify a column somewhere, etc | 23:11 |
| *** sbfox has quit IRC | 23:15 | |
| openstackgerrit | Stephen Balukoff proposed stackforge/octavia: Specification of reference haproxy amphora API https://review.openstack.org/126801 | 23:20 |
| *** SumitNaiksatam has quit IRC | 23:31 | |
| sbalukoff | Holy moly, wall of text! | 23:34 |
| sbalukoff | Yes, 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 |
| sbalukoff | OpenStack 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-lbaas | 23:37 | |
| sbalukoff | Also, 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 |
| sbalukoff | Otherwise, 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 IRC | 23:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!