| *** vivek-eb_ has quit IRC | 00:01 | |
| *** vivek-ebay has joined #openstack-lbaas | 00:01 | |
| *** vivek-eb_ has joined #openstack-lbaas | 00:04 | |
| *** vivek-ebay has quit IRC | 00:04 | |
| *** jorgem has quit IRC | 00:07 | |
| *** SumitNaiksatam has quit IRC | 00:28 | |
| *** Gayathri has joined #openstack-lbaas | 01:01 | |
| *** Gayathri has quit IRC | 01:02 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 01:04 | |
| *** xgerman has quit IRC | 01:10 | |
| *** fnaval_ has quit IRC | 02:00 | |
| *** vivek-eb_ has quit IRC | 02:04 | |
| *** fnaval has joined #openstack-lbaas | 02:17 | |
| *** sbalukoff has quit IRC | 02:58 | |
| *** crc32 has joined #openstack-lbaas | 03:49 | |
| *** crc32 has quit IRC | 03:57 | |
| *** vivek-ebay has joined #openstack-lbaas | 03:57 | |
| *** SumitNaiksatam has quit IRC | 04:21 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 04:21 | |
| *** amotoki_ has quit IRC | 04:29 | |
| *** cipcosma has joined #openstack-lbaas | 05:05 | |
| *** rohara has quit IRC | 05:11 | |
| *** vivek-eb_ has joined #openstack-lbaas | 05:14 | |
| *** fnaval has quit IRC | 05:14 | |
| *** vivek-ebay has quit IRC | 05:16 | |
| *** vivek-ebay has joined #openstack-lbaas | 05:28 | |
| *** vivek-eb_ has quit IRC | 05:32 | |
| *** vivek-ebay has quit IRC | 05:32 | |
| blogan | ping sbalukoff | 05:43 |
|---|---|---|
| blogan | and he's not here | 05:43 |
| blogan | nvm | 05:43 |
| *** sbalukoff has joined #openstack-lbaas | 05:47 | |
| blogan | ping sbalukoff | 05:48 |
| *** kobis has joined #openstack-lbaas | 06:08 | |
| *** kobis has quit IRC | 06:09 | |
| *** sbalukoff has quit IRC | 07:09 | |
| *** rohara has joined #openstack-lbaas | 07:10 | |
| *** kobis has joined #openstack-lbaas | 07:33 | |
| *** ptoohill_ has quit IRC | 07:33 | |
| *** ptoohill_ has joined #openstack-lbaas | 07:43 | |
| *** woodster_ has quit IRC | 08:00 | |
| *** cipcosma has quit IRC | 08:46 | |
| *** cipcosma has joined #openstack-lbaas | 10:54 | |
| *** kbyrne has joined #openstack-lbaas | 11:28 | |
| *** vivek-ebay has joined #openstack-lbaas | 13:34 | |
| *** vivek-ebay has quit IRC | 13:50 | |
| *** vivek-ebay has joined #openstack-lbaas | 13:51 | |
| *** vivek-eb_ has joined #openstack-lbaas | 14:00 | |
| *** rm_you has quit IRC | 14:01 | |
| *** vivek-ebay has quit IRC | 14:01 | |
| *** vivek-eb_ has quit IRC | 14:10 | |
| *** vivek-ebay has joined #openstack-lbaas | 14:20 | |
| *** vivek-eb_ has joined #openstack-lbaas | 14:54 | |
| *** fnaval has joined #openstack-lbaas | 14:56 | |
| *** vivek-ebay has quit IRC | 14:57 | |
| *** vivek-eb_ has quit IRC | 14:58 | |
| *** Putns has joined #openstack-lbaas | 15:01 | |
| *** jschwarz_ has joined #openstack-lbaas | 15:04 | |
| *** jschwarz_ is now known as jschwarz | 15:04 | |
| *** vivek-ebay has joined #openstack-lbaas | 15:14 | |
| *** ptoohill_ has quit IRC | 15:19 | |
| *** ptoohill_ has joined #openstack-lbaas | 15:35 | |
| *** ptoohill_ has quit IRC | 15:35 | |
| *** ptoohill_ has joined #openstack-lbaas | 15:39 | |
| sballe | blogan: ping | 15:39 |
| *** fnaval has quit IRC | 15:42 | |
| *** ptoohill_ has quit IRC | 15:45 | |
| dougwig | morning all | 15:47 |
| *** mlavalle has joined #openstack-lbaas | 15:47 | |
| sballe | morning | 15:49 |
| *** ptoohill_ has joined #openstack-lbaas | 15:50 | |
| sballe | dougwig: I am suddenly drawing a blank on how Neutron LBaaS V2 is working. Is it using the lbaas-agent the same way it was used in lbaas v1? Which mean that it can be placed on any node and doesn't have to be on the network node? | 15:51 |
| *** ptoohill_ has quit IRC | 15:52 | |
| dougwig | the lbaas-agent is only used by the haproxy driver. lbaas itself runs on the neutron node, the lbaas agent can go anywhere. and v2's haproxy ref driver will be similar, unless it's octavia. | 15:52 |
| sballe | dougwig: thanks for confirming this. | 15:53 |
| *** ptoohill_ has joined #openstack-lbaas | 15:56 | |
| *** xgerman has joined #openstack-lbaas | 16:00 | |
| *** fnaval has joined #openstack-lbaas | 16:06 | |
| *** fnaval has quit IRC | 16:06 | |
| *** fnaval has joined #openstack-lbaas | 16:07 | |
| *** vivek-ebay has quit IRC | 16:10 | |
| *** kobis has quit IRC | 16:10 | |
| *** cipcosma has quit IRC | 16:11 | |
| *** mlavalle_ has joined #openstack-lbaas | 16:12 | |
| *** Putns_ has joined #openstack-lbaas | 16:14 | |
| *** TrevorV_ has joined #openstack-lbaas | 16:18 | |
| *** mlavalle has quit IRC | 16:18 | |
| *** TrevorV has quit IRC | 16:18 | |
| *** Putns has quit IRC | 16:18 | |
| *** TrevorV_ is now known as TrevorV | 16:18 | |
| *** Putns_ is now known as Putns | 16:19 | |
| *** mikedillion has joined #openstack-lbaas | 16:28 | |
| *** SumitNaiksatam has quit IRC | 16:33 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 16:34 | |
| RamaKrishna | Hi mlavalle_ | 16:44 |
| mlavalle_ | RamaKrishna: hi, looking at your email right now. Give me a few minutes | 16:44 |
| RamaKrishna | Sure and Thanks mlavalle_ | 16:48 |
| *** Youcef has joined #openstack-lbaas | 16:50 | |
| mlavalle_ | RamaKrishna: you are getting a 404, which means the Neutron API didn't find the resource you are trying to do a POST against. You are trying to create a member of the loadbalancer. It is the member resource that it is not finding | 16:58 |
| mlavalle_ | RamaKrishna: this can be due to either of 2 reasons: | 16:58 |
| RamaKrishna | ok | 16:59 |
| mlavalle_ | RamaKrishna: you loadbalancer environment is not set up properly in devstack. I don't think this is the case, though, because by the moment the test fails, you already created a loadbalancer, a health monitor and a pool | 17:00 |
| mlavalle_ | RamaKrishna: the other reason is that ther was a change in the api. I think this is the most likely explanation. I recommend checking with the dev team the latest version of the api | 17:01 |
| mlavalle_ | RamaKrishna: please remeber that I finished work on this script in mid-August, so I am pretty sure things have changed since then | 17:03 |
| RamaKrishna | Thanks mlavalle | 17:03 |
| RamaKrishna | Appreciate your help | 17:03 |
| mlavalle_ | RamaKrishna: if you get the documentation of the lastest version of the api, and it indeed changed, I will walk you through the process of changing the rest client in tempest to support the change | 17:04 |
| RamaKrishna | Ok. Meanwhile I will try to run the API's manually to see if all of them work and as per specs.. then we can debug | 17:05 |
| mlavalle_ | :-) | 17:05 |
| *** Putns has quit IRC | 17:10 | |
| *** TrevorV_ has joined #openstack-lbaas | 17:13 | |
| *** mikedillion has quit IRC | 17:40 | |
| *** vivek-ebay has joined #openstack-lbaas | 18:15 | |
| *** sbalukoff has joined #openstack-lbaas | 18:22 | |
| *** mikedillion has joined #openstack-lbaas | 18:33 | |
| *** ptoohill_ has quit IRC | 18:41 | |
| *** ptoohill_ has joined #openstack-lbaas | 18:41 | |
| *** ptoohill_ has quit IRC | 18:41 | |
| *** ptoohill_ has joined #openstack-lbaas | 18:49 | |
| *** openstackgerrit has quit IRC | 18:50 | |
| *** openstackgerrit has joined #openstack-lbaas | 18:50 | |
| *** jschwarz has quit IRC | 18:56 | |
| *** ptoohill_ has quit IRC | 19:05 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:10 | |
| *** ptoohill_ has quit IRC | 19:10 | |
| *** crc32 has joined #openstack-lbaas | 19:12 | |
| *** jorgem has joined #openstack-lbaas | 19:12 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:14 | |
| *** ptoohill_ has quit IRC | 19:17 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:17 | |
| *** ptoohill_ has quit IRC | 19:17 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:18 | |
| *** ptoohill_ has quit IRC | 19:19 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:21 | |
| *** TrevorV_ has quit IRC | 19:23 | |
| blogan | reminder: https://etherpad.openstack.org/p/lbaas-kilo-meetup | 19:24 |
| *** ptoohill_ has quit IRC | 19:25 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:25 | |
| *** ptoohill_ has quit IRC | 19:25 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:26 | |
| *** ptoohill_ has quit IRC | 19:27 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:27 | |
| *** ptoohill_ has quit IRC | 19:28 | |
| *** ptoohill_ has joined #openstack-lbaas | 19:28 | |
| *** woodster_ has joined #openstack-lbaas | 19:32 | |
| *** jorgem has quit IRC | 19:38 | |
| *** openstackgerrit has quit IRC | 20:04 | |
| *** openstackgerrit has joined #openstack-lbaas | 20:04 | |
| *** TrevorV_ has joined #openstack-lbaas | 20:44 | |
| *** SumitNaiksatam has quit IRC | 20:44 | |
| *** vivek-ebay has quit IRC | 20:45 | |
| *** ptoohil__ has joined #openstack-lbaas | 20:48 | |
| *** ptoohill_ has quit IRC | 20:48 | |
| *** jorgem has joined #openstack-lbaas | 20:49 | |
| *** ptoohil__ has quit IRC | 20:52 | |
| *** ptoohill_ has joined #openstack-lbaas | 20:52 | |
| *** ptoohil__ has joined #openstack-lbaas | 20:54 | |
| *** ptoohill_ has quit IRC | 20:54 | |
| *** mikedillion has quit IRC | 21:08 | |
| *** vivek-ebay has joined #openstack-lbaas | 21:19 | |
| RamaKrishna | Hi mlavalle | 21:34 |
| blogan | ping sbalukoff | 22:14 |
| sbalukoff | pong | 22:14 |
| sbalukoff | What up, yo? | 22:14 |
| blogan | happen to read my comments on reviews? | 22:15 |
| blogan | mainly: https://review.openstack.org/#/c/121233/ | 22:15 |
| sbalukoff | I saw you commented, am planning on responding, but my day is going somewhat slowly. | 22:16 |
| blogan | i know the feeling | 22:16 |
| blogan | except my brain is going somewhat slowly as well | 22:16 |
| sbalukoff | Anyway, later this afternoon / evening, I anticipate responding there, unless there's something you need resolved immediately? | 22:17 |
| blogan | nah thats fine, the other one is https://review.openstack.org/#/c/130424 | 22:17 |
| blogan | but i expect you'll respond to all that you can | 22:17 |
| sbalukoff | Oh, I will. | 22:25 |
| * sbalukoff cackles maniacly. | 22:25 | |
| sbalukoff | maniacally? | 22:25 |
| sbalukoff | Dang, I can never spell that correctly. | 22:25 |
| blogan | muneyeuhcly | 22:26 |
| *** cipcosma has joined #openstack-lbaas | 22:28 | |
| dougwig | i'd encourage y'all to make time for flavors before monday (the meetup). | 22:29 |
| sbalukoff | Working on that right now, actually. | 22:32 |
| *** cipcosma has quit IRC | 22:37 | |
| xgerman | dougwig I was making time to celebrate the spin-off | 22:38 |
| xgerman | but flavor , oh well, if that's the way you want us to have fun :-) | 22:39 |
| dougwig | there's two flavor specs now. i especially need operator input on the second. | 22:39 |
| xgerman | two? | 22:39 |
| xgerman | they multiplied... | 22:40 |
| xgerman | link? | 22:40 |
| dougwig | https://review.openstack.org/#/c/102723/7 | 22:40 |
| dougwig | https://review.openstack.org/#/c/139155/ | 22:40 |
| xgerman | ok, I -1'd the first one... | 22:40 |
| dougwig | saw that, thanks. | 22:41 |
| *** SumitNaiksatam has joined #openstack-lbaas | 22:43 | |
| openstackgerrit | Trevor Vardeman proposed stackforge/octavia: Creation of Octavia API Documentation https://review.openstack.org/136499 | 22:52 |
| *** TrevorV_ has quit IRC | 22:52 | |
| dougwig | can someone take a peek at my driver spec? it's short. https://review.openstack.org/#/c/138930/ | 22:57 |
| xgerman | +1'd | 23:01 |
| *** jorgem has quit IRC | 23:04 | |
| dougwig | xgerman: ty | 23:04 |
| dougwig | xgerman: hacky? hacky!? :-) | 23:05 |
| *** vivek-ebay has quit IRC | 23:06 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:06 | |
| *** vivek-ebay has quit IRC | 23:07 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:07 | |
| *** ptoohil__ has quit IRC | 23:14 | |
| *** vivek-ebay has quit IRC | 23:18 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:18 | |
| *** mlavalle_ has quit IRC | 23:19 | |
| *** mlavalle has joined #openstack-lbaas | 23:24 | |
| dougwig | sbalukoff: there's the anal probe commentary that i've been missing! | 23:37 |
| sbalukoff | Haha! | 23:37 |
| sbalukoff | Wow, that bad, eh? | 23:37 |
| sbalukoff | I'm sorry | 23:37 |
| sbalukoff | But yes, once again (and this should be no surprise): I'm an asshole. | 23:38 |
| dougwig | nah, that was exactly the dialogue I wanted in the open. | 23:40 |
| blogan | sounds like lbaas needs extensions | 23:45 |
| dougwig | the problem i'm trying to solve is the customer that's willing to place a multi-million dollar order "if you let my end users select whichever SSL cipher they want, but only within the next two months." (timeline too short for the community and/or tiny obscure feature) or the fact that I would like to let operators turn on DDoS in front of their LB's, but | 23:46 |
| dougwig | *there is no open-source solution for that*, and won't be for some time (no open-source alternative.) the crap I have to resort to today helps no one, least of all the operators. | 23:46 |
| sbalukoff | dougwig: I agree. We need you to be able to do that. | 23:47 |
| blogan | i understand it and I have concerns that sbalukoff put much more eloquently than i could have | 23:47 |
| sbalukoff | I just want some guidance on where the line is drawn... | 23:47 |
| dougwig | heh, me too. :) | 23:47 |
| sbalukoff | I expect new features to always be exposed by vendors in the manner you've described first, but eventually many of those should make it into the base feature seet. | 23:47 |
| sbalukoff | set. | 23:47 |
| dougwig | i just know the line isn't at either extreme. | 23:47 |
| blogan | and one reason for neutron's extensions is this isn't it? some extensions enable attributes/feature through the API that some drivers cant do | 23:48 |
| dougwig | sbalukoff: i agree. how do we word that in a way that makes everyone comfortable? the second proposal is really just better integration hooks, and who doesn't like integration hooks? | 23:49 |
| sbalukoff | dougwig: Agreed. | 23:49 |
| sbalukoff | Um.... | 23:49 |
| sbalukoff | It might be worth saying that you expect new features will get added by vendors quickly after they become market-viable... and that as more vendors (and especially open-source solutions) support these new features fully, the expectation is that these will be rolled into the base feature set for the service, through community development and support. | 23:50 |
| sbalukoff | And to emphasize this, perhaps we should make it rule that if the base feature set covers a certain functionality, then vendors shouldn't duplicate this using the flavor metadata extension you're describing. | 23:51 |
| sbalukoff | As a best practice. | 23:51 |
| sbalukoff | And, as German pointed out somewhere, that anything defined in the base feature set trumps anything set via extension. | 23:51 |
| sbalukoff | That would make me more comfortable. What do you think? | 23:51 |
| dougwig | i certainly agree with that last. for the first, i'd expect that user demand should drive what we/the community devs prioritize for adding to the community bucket, right? | 23:52 |
| dougwig | that last being the 'best practice' thing. | 23:52 |
| sbalukoff | dougwig: Well, yes... but there needs to be an open-source alternative for it to become part of the base feature set in any case. | 23:52 |
| sbalukoff | That's sort of an OpenStack mantra, right? | 23:52 |
| sbalukoff | That all the base features are completely open source? | 23:53 |
| dougwig | i'd be happy listing german's recommendation as an rfc style *SHOULD*. there's a technical limitation in that the driver gets to pick which it prefers, and the drivers aren't always completely in tree. | 23:53 |
| sbalukoff | I'm OK with that. | 23:54 |
| dougwig | sbalukoff: of course. but it could have an open source alternative that no one wants; do we add it just because some vendor/operator might do it somewhere? i'd think not. if there's demand, then absolutely. | 23:54 |
| sbalukoff | I think you and I are violently agreeing on this, dougwig. | 23:54 |
| dougwig | i think we mostly are, but i'm trying to suss out how to word this in a way that doesn't get the reaction you just had. a reaction that *equally* applies to the original flavor proposal (the question of exposing unsupported features is in both; the second just allows another set of them in.) | 23:55 |
| sbalukoff | You're right, it does apply to both... hmmm... | 23:56 |
| sbalukoff | Well, again, I think lampshading the problem and explaining the intentions of our decision here, and how we expect it to play out practically are key here. | 23:57 |
| sbalukoff | And you can do that by saying directly, that the trade-off we're trying to solve is the ability for vendors to add new features / extensions quickly versus vendor lock-in. | 23:57 |
| dougwig | we should focus on the philosophy of that in the first spec; the second is really just a tweak (IMO). | 23:57 |
| sbalukoff | That this seems like the best alternative we can go for with the recommendation that popular features get rolled into the base service feature set. | 23:58 |
| sbalukoff | dougwig: That's fine with me. | 23:58 |
| sbalukoff | If you have time to write that up, I'll review it whenever you let me know. I know time is of the essence here with the Neutron mid-cycle meet-up next week. | 23:58 |
| dougwig | this blurb wasn't clear enough? "The first alternative is to do nothing. This results in what many vendors are | 23:59 |
| dougwig | 172+ doing today, which is to brew up proprietary neutron solutions in order to | 23:59 |
| dougwig | 173+ expose more advanced features. This results in inconsistent solutions for | 23:59 |
| dougwig | 174+ operators, more difficulty tracking trunk, and vendor lock-in." | 23:59 |
| sbalukoff | It wasn't, per se: I'd like to see acknowlegements of this particular solution's short-comings, and explanation that these are "less bad" than the short-comings of the alternatives, and that's why we're going with this. | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!