14:00:37 <enikanorov> #startmeeting neutron lbaas
14:00:38 <openstack> Meeting started Thu Feb 13 14:00:37 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:41 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:51 <obondarev> hi
14:01:15 <evgenyf> hi
14:01:19 <sballe> hi
14:01:20 <s3wong> Hello
14:01:24 <edhall> hi
14:01:26 <sbalukoff> Howdy!
14:01:27 <samuelbercovici> hi
14:01:41 <enikanorov> #link https://wiki.openstack.org/wiki/Network/LBaaS
14:01:45 <vjay> hi
14:01:48 <enikanorov> here's the agenda
14:02:12 <enikanorov> i was expecting markmcclain to join to discuss the instance proposal once again
14:02:49 <obondarev> seems he's not around
14:02:50 <enikanorov> aldo i'm glad to have sbalukoff here who has some ideas on how to improve our object model
14:03:09 <enikanorov> so while Mark is not here let's start with other items
14:03:29 <enikanorov> let's start with L7
14:03:38 <sbalukoff> Ok
14:03:58 <enikanorov> samuelbercovici: can we get an update on l7? may be avishay could join?
14:04:50 <samuelbercovici> avishay should be joining soon
14:04:57 <obondarev> sbalukoff: do you want to join and review https://review.openstack.org/#/c/61721/ which is the current proposal
14:04:58 <avishayb_> hi
14:05:04 <samuelbercovici> lets start with SSL as evegenyf is already online
14:05:10 <enikanorov> ok then
14:05:20 <samuelbercovici> i see that avishay has joined
14:05:46 <sbalukoff> obondarev: Sure; Not sure I can do that during this meeting, eh.
14:06:05 <enikanorov> sbalukoff: sure thing
14:06:33 <samuelbercovici> lets take the instance discussion on ML if possible
14:06:35 <obondarev> sbalukoff: I meant not during the meeting of course :)
14:07:39 <enikanorov> samuelbercovici: i think Mark had some particular concerns. As for instance discussion on ML i found that what sbalukoff is suggesting is mostly reflected by the proposed instance model
14:08:06 <enikanorov> ok, evgenyf: want to update on SSL API/DB stuff
14:08:06 <enikanorov> ?
14:08:26 <samuelbercovici> ok. will add my comments in ML
14:08:50 <evgenyf> new SSL patch is having all tests (REST, DB) and comments addressing. It doesn't pass the gate, having troubles with tempest test (create_vip), in process of fixing it
14:09:29 <enikanorov> evgenyf: i've briefly looked at those failures, it seems that currently ssl attributes are mandatory while they should not be
14:09:38 <enikanorov> so regular non-ssl tests can't pass
14:09:39 <evgenyf> had issue with other neutron unit test that failed when my tests were added. bug was opened, fixed as part of the patch
14:09:49 <evgenyf> right
14:10:01 <evgenyf> I guess the problem is with extended attributes
14:10:18 <samuelbercovici> enikanorov: did you get response on how to secure the AMQP traffic for HA proxy implementation?
14:11:06 <evgenyf> enikanorov: anyhow, I'm on it
14:11:08 <enikanorov> samuelbercovici: not much. I got response from russellb, that we could just use secure messaging
14:11:29 <enikanorov> that's an option that doesn't require much of action from our side
14:11:41 <enikanorov> e.g. no specific code to care about security
14:11:44 <samuelbercovici> enikanorov: was markmcclain oj with this?
14:11:50 <samuelbercovici> oj==ok
14:12:47 <enikanorov> he was not on the thread, i think in general the solution is the best, the only problem that infra is not using secure messaging and i'm not sure that is a typical deployment scenario
14:13:16 <enikanorov> secure messaging is configured at cloud level, not for particular process, i guess
14:13:37 <enikanorov> so that puts lbaas into dependent position
14:13:51 <samuelbercovici> enikanorov: you have mentioned that mark mentioned security concerns. As far as I recall, all of them were around securing the channel. are u aware on any other ocncerns?
14:14:54 <enikanorov> well, i think the concern is mostly theoretical: we need to design security features carefully and put more effort into it
14:15:11 <iwamoto> I had an impression that secure messaging stuff has a long way to go. Is there remarkable progress recently?
14:15:13 <enikanorov> i didn't have a chance to discuss it with him in more details
14:15:30 <sbalukoff> You could always do a public key exchange across the rabbit queue for sending encrypted messages. This would secure the message from eavesdroppers who do have access to the queue. But that seems like a lot of work when the real solution should be to secure the channel.
14:16:09 <enikanorov> sbalukoff: yes, that is an option that would require us to write that additional code
14:16:19 <sbalukoff> Yep. No thank you. :)
14:16:30 <enikanorov> that's kinda what we'd like to avoid :)
14:17:05 <samuelbercovici> iwamoto: do you have more specific details on issues on exisitng capabilities?
14:17:05 <enikanorov> meanwhile i've started to work on cli for ssl
14:17:30 <sbalukoff> Does anyone know how far off delivery of an encrypted rabbit queue is in reality?
14:17:51 <samuelbercovici> sbalukoff: +1 and also for other implementations
14:18:00 <sbalukoff> It might be the only option available to us if we want to securely deliver SSL before then.
14:18:01 <samuelbercovici> 0mq for example
14:18:22 <sbalukoff> Oh yes-- there are a lot of reasons the queue should be secured in general.
14:19:50 <sbalukoff> So, whose chain can we rattle to get progress on getting a secure rabbit queue?
14:20:37 <enikanorov> sbalukoff: afaik there is a guide on how to set it up for the openstack
14:21:01 <sbalukoff> Oh! Ok, so cloud admins have the capability of delivering this already?
14:21:30 <enikanorov> http://docs.openstack.org/security-guide/content/ch038_transport-security.html
14:22:04 <sbalukoff> Then? well, it seems like cheating but we could carry forward with SSL and put a huge warning label on it that says 'DO NOT USE UNLESS YOU HAVE A SECURE RABBIT QUEUE' eh.
14:22:49 <sbalukoff> (Sorry, I got the impression from iwamoto's statement above that secure messaging wasn't going to be a possibility any time soon.)
14:22:51 <enikanorov> i had an impression that that's what we don't want to do
14:23:43 <enikanorov> ok, let's move forward
14:23:52 <enikanorov> L7
14:23:55 <sbalukoff> Huh. Ok. Is it possible for us to detect whether the queue is secured and return errors if SSL operations are attempted with an insecure queue?
14:23:58 <sbalukoff> Ok.
14:24:25 <enikanorov> avishayb_: obondarev: hi
14:24:28 <obondarev> ok returning to L7: I left some comments on the review, would be great if anybody could also join, as now it seems only a discussion between Avishay and me :)
14:24:38 <avishayb_> hi
14:25:07 <avishayb_> I will post some question in ML - so it will not be just the 2 of us :-)
14:25:23 <sbalukoff> obondarev: One note on that: Did you see the mailing list traffic on this subject over the last few days?
14:25:24 <iwamoto> samuelbercovici, sbalukoff: I thought we were talking about bp trusted-messaging
14:25:55 <obondarev> sbalukoff: yeah, sure
14:26:35 <sbalukoff> I should probably clarify my intent with what I've been saying there:  I think there's a difference between reviewing at the code level and reviewing at a design level. I also think it's more important to get the design right before getting the code right. This is why I've been concentrating on the design level.
14:27:16 <obondarev> sbalukoff: fair enough
14:27:17 <avishayb_> L7: while Oleg review the patch, I am adding support for ordering the L7plicies for a vip.
14:27:25 <avishayb_> *policies
14:27:30 <sbalukoff> So, while I've seen that review link previously, I have not yet dove into the code because I think a design-level discussion is more appropriate first. :)
14:28:15 <sbalukoff> (Unless I'm totally mistaken here-- I don't see a good way to hold a design-level discussion using the review link you gave.)
14:28:33 <sbalukoff> And please forgive my newbishness: I'm still figuring out how the whole blueprint system works.
14:28:41 <samuelbercovici> sbalukoff: yes, design level discussions would be mostly appreciated
14:29:19 <obondarev> sbalukoff: so do you have any major concerns on the current design?
14:29:54 <sbalukoff> Anyway, after our last bit of correspondence, the one I have has to do with the default pool stuff. And I'd like a clarification: Are the features we're discussing with L7 slated for icehouse, or for Juno?
14:30:17 <sbalukoff> (Otherwise, the L7 design seems good to me.)
14:30:23 <sballe> obondarev, could you give me a pointer to the design/blueprint?
14:31:16 <obondarev> sballe: sure, https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
14:31:25 <sballe> obondarev, THX
14:32:27 <obondarev> one concern that I have currently is whether we should define a closed set of l7 rule types, compare types and l7 policy actions
14:32:48 <enikanorov> i've not managed yet to look over l7 discussion on ML, i'll join it as well
14:33:20 <sbalukoff> obonarev: Aah! Yes, deciding what L7 rules we'll support and in what format is important. For what it's worth, the model proposed would cover the 90% use case of our customer base, so I have less concerns there.
14:33:39 <sbalukoff> obodarev: Do you have a specific rule in mind that would not fit the mold as proposed?
14:34:35 <obondarev> sbalukoff: I just want all types be defined as constants
14:34:50 <obondarev> the model is fine
14:35:18 <obondarev> for example we have a closed set for health monitors types
14:35:47 <obondarev> so for l7 I wand kind of same approach
14:36:12 <sbalukoff> Seems reasonable to me.
14:37:08 <enikanorov> ok, any more questions to discuss on l7?
14:37:13 <avishayb_> lets dive into the details in the ML - I will present the types and the optional values there.
14:37:23 <sbalukoff> Does anyone have that clarification: Is the L7 proposal we're discussing for Icehouse or Juno?
14:37:34 <enikanorov> sbalukoff: Icehouse
14:37:34 <obondarev> avishayb_: thanks!
14:37:54 <sbalukoff> Ok, so we're going to get this in before the 18th? Cool.
14:38:01 <enikanorov> we're trying
14:38:21 <obondarev> we don't need to merge it till 19th
14:38:21 <sbalukoff> (I still think we need a better solution to the default pool problem.)
14:38:24 <obondarev> 18th*
14:38:42 <obondarev> 18th is proposal deadline
14:38:52 <sbalukoff> Ok.
14:39:04 <samuelbercovici> sbalukoff: already have the api in review, we need the ha proxy code to be committed before 18th.
14:39:29 <obondarev> that's a challenge :)
14:39:39 <samuelbercovici> enikanorov: afaik, the code needs to be commited by 18th, then we can have a few more weeks to get it approved
14:39:55 <enikanorov> posted on gerrit, you mean
14:40:00 <enikanorov> yes, that's correct
14:40:44 <samuelbercovici> so wee need a code mybe still wip for ha proxy by 18 feb
14:40:49 <samuelbercovici> correct?
14:40:55 <enikanorov> exactly
14:41:08 <obondarev> I'll try to get something for haproxy untill 18th
14:41:46 <samuelbercovici> now, the last items would be cli and horizon support.
14:41:52 <obondarev> and we should agree on the final l7 design asap
14:41:53 <samuelbercovici> horizon might not be mandatory
14:42:11 <enikanorov> i can take the cli part as well
14:42:34 <samuelbercovici> so the goal is to have all moving part with initial commit by 18th feb\
14:42:46 <enikanorov> i think for the cli there is no such deadline
14:42:47 <samuelbercovici> can we try and do the same for SSL?
14:43:09 <enikanorov> samuelbercovici: no, i don't think so, the feature is more complex and harder to test
14:43:12 <samuelbercovici> enikanorov: can you check with the power at be :-)
14:43:42 <samuelbercovici> about the cli
14:43:54 <enikanorov> yes, I'll ask
14:44:14 <enikanorov> i think client patches are simpler and don't require much discussions
14:44:21 <obondarev> what I want to mention here is that even if we propose everything we want untill 18th this would'n mean that core reviewers will have enough time to review all of the patches
14:45:04 <obondarev> I'm even not speaking about merging here
14:45:17 <samuelbercovici> obondarev: i have seen that you got nominated to core. is it approved?
14:45:33 <obondarev> voiting will last till Saturday
14:46:09 <samuelbercovici> ok, you hopefully be one. and then we go hunting for a 2nd
14:46:45 <obondarev> hah :)
14:47:04 <obondarev> I don't think everything is so easy here :)
14:47:34 <samuelbercovici> samuelbercovici: i am optimistic by nature
14:47:57 <enikanorov> ok. let's hope for the best
14:47:58 <obondarev> good for you :)
14:48:15 <enikanorov> any other items to discuss?
14:48:42 <s3wong> Is haproxy HA going to be ready for Icehouse?
14:48:57 <obondarev> s3wong: I don't think so
14:49:01 <enikanorov> s3wong: no
14:49:14 <obondarev> it will be planned for Juno
14:49:27 <s3wong> obondarev: OK
14:49:48 <sbalukoff> Ok.. er.. that's sort of a contradiction of what I asked above. But Ok, that's the clarification I was after. :)
14:50:04 <enikanorov> sbalukoff: can you explain?
14:50:23 <sbalukoff> Oh, sorry, I asked whether the L7 proposal we were discussing was for Icehouse or Juno.
14:50:26 <sbalukoff> You said Icehouse.
14:50:37 <sbalukoff> Then just now, we're saying L7 won't be ready for Icehouse.
14:50:47 <sbalukoff> Oh!
14:50:51 <sbalukoff> Sorry, misread.
14:50:58 <sbalukoff> Nevermind-- you were just talking about HA.
14:51:01 <sbalukoff> D'oh! My bad!
14:51:04 <obondarev> well, the last item we were discussing is haproxy HA
14:51:08 <obondarev> ok
14:51:23 <sbalukoff> Carry on!
14:51:25 <enikanorov> sbalukoff: l7 was initially planned for I, that's why we actively working on it right now
14:51:38 <enikanorov> realistically it still has low chances to get in I
14:52:01 <sbalukoff> Ok, well, I certainly don't want to delay that work.
14:52:07 <sballe> I am trying to find all the designs and I am having trouble navigating the Wiki. https://wiki.openstack.org/wiki/Neutron/LBaaS seems out of date.
14:52:18 <sbalukoff> The L7 model as proposed is a huge step in the right direction.
14:52:33 <sballe> How do I find the latest designs? I have found l7 and SSL but not sure where to fidn the rest
14:53:08 <obondarev> sballe: did you try to search blueprints first?
14:53:25 <enikanorov> sballe: in addition to the wiki page you can use etherpad page
14:53:30 <enikanorov> let me find the link
14:53:36 <sballe> yes I have all the blueprints: https://blueprints.launchpad.net/neutron?searchtext=lbaas
14:53:41 <enikanorov> sballe: etherpad.openstack.org/p/icehouse-neutron-lbaas
14:53:46 <obondarev> sballe: usually blueprints have links to designs
14:53:56 <enikanorov> sballe: https://etherpad.openstack.org/p/icehouse-neutron-lbaas
14:53:59 <sballe> thx
14:54:17 <sballe> I will get to the designs that way :-)
14:55:02 <obondarev> sballe: you can also be a volunteer to bring main LBaaS wiki up to date :)
14:55:19 <obondarev> just kidding :)
14:55:23 <sballe> :)
14:55:27 <enikanorov> no, really, you can be!
14:55:56 <sballe> let me think about it. :)
14:55:58 <enikanorov> ok, let's wrap up then if there's no more items to discuss
14:56:26 <enikanorov> #endmeeting