14:00:29 <enikanorov_> #startmeeting neutron lbaas
14:00:30 <openstack> Meeting started Thu Jan 16 14:00:29 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:33 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:36 <enikanorov_> hi
14:00:42 <sbalukoff> Howdy!
14:01:08 <enikanorov_> who's online for lbaas meeting?
14:01:11 <enikanorov_> hi s3wong
14:01:21 * sbalukoff will be lurking
14:01:43 <s3wong> enikanorov: Hello
14:01:52 <enikanorov_> markmcclain: hi
14:01:55 <enikanorov_> avishayb: hi
14:02:01 <avishayb> hi
14:02:21 <enikanorov_> #topic announcements
14:02:30 <markmcclain> enikanorov_: hi
14:02:40 <enikanorov_> not so much to announce this week, actually
14:02:51 <enikanorov_> markmcclain: we'll need you to discuss ssl extension proposal
14:02:59 <markmcclain> ok
14:03:32 <samuelbercovici> hi all
14:03:36 <enikanorov_> so on announcements, we still expecting basic lbaas scenario test to get merged
14:04:11 <enikanorov_> ithe test is ready, we are currently making sure it runs stable
14:04:29 <enikanorov_> after that i'm going to ping temepest cores until we merge it
14:04:37 <enikanorov_> hi Sam
14:04:43 <samuelbercovici> enikanorov_: what is basic lbaas scenario? how is it different than the existing lbaas tests?
14:05:05 <enikanorov_> samuelbercovici: basic scenario is end-to-end test in tempest
14:05:46 <samuelbercovici> aren't there already tests in tempest for lbaas?
14:05:47 <enikanorov_> it merely starting vm instance, starting web services on it, configurin loadbalancer, adding those members and checking that it all works accessing them with floating ip
14:06:05 <enikanorov_> samuelbercovici: those are API tests, they mainly test neutron server responses
14:06:19 <enikanorov_> and they don't care about if it all works behind the scenes
14:06:49 <enikanorov_> our basic scenario represents real-life usage more or less
14:07:20 <samuelbercovici> so in addition to the existing lbaas tempest etsts, this one adds passing traffic?
14:08:04 <enikanorov_> right. and the results can depend on the provider that is used for lbaas (can, but should not)
14:08:16 <samuelbercovici> ok.
14:08:35 <samuelbercovici> please point to the tests so we can try and run it localy
14:08:42 <enikanorov_> sure:
14:09:07 <enikanorov_> #link https://review.openstack.org/#/c/58697
14:09:34 <enikanorov_> #topic third-party testing
14:10:14 <enikanorov_> that was discussed a number of times in ML, and it looks like we already have a few systems set up properly
14:10:21 <enikanorov_> but i'm not sure we have such for lbaas
14:10:30 <enikanorov_> samuelbercovici: any progress from your side on this?
14:10:48 <avishayb> we are (more or less) in the last mile with 3rd party testing..
14:11:01 <Vijay> Eugene:  As you might be already aware, NetScaler CI is LIVE now
14:11:11 <enikanorov_> cool. one of the important requirements is that you provide a way to check logs
14:11:13 <avishayb> however - we did some code fix in order to run it against Radware env,
14:11:41 <avishayb> I meab in the temest test code.
14:11:45 <enikanorov_> Vijay: great
14:11:46 <avishayb> *mean
14:11:56 <enikanorov_> avishayb: what kind of fix?
14:12:11 <Vijay> In Addition, we were able to run the scenario test 58697 with ML2 + VLAN and NetScaler providing LBaaS
14:12:17 <enikanorov_> it doesn't seem right. you may change devstack configuration, but tempest should be trunk
14:12:42 <enikanorov_> Vijay: super! i'd be interested in knowing detail about configuration
14:13:04 <enikanorov_> Vijay: could you write me a short notice about how did you configured whole env?
14:13:05 <avishayb> One of the method (not sure about the name) calls the API but does not wait until the entity that was created is ACTIVE.
14:13:10 <Vijay> sure
14:13:44 <enikanorov_> avishayb: then it looks like tempest bug - please file it and propose a fix
14:14:07 <avishayb> so the test goes on while the entity is PENDING_CREATE. I will gather the details.
14:14:34 <enikanorov_> i see. also, it might be ok for API test
14:14:47 <samuelbercovici> to add on avishayb we want to make sure all tsts pass localy and that we pinned all issues .
14:14:49 <enikanorov_> so it yet unclear, should it be fixed, or the driver needs to be fixed
14:15:02 <samuelbercovici> the next step will be to open bugs on the tempets tests and post the fixes
14:15:16 <enikanorov_> ok
14:15:30 <enikanorov_> any questions on 3rd party testing?
14:15:36 <samuelbercovici> enikanorov_: this should be a fix of the tempest tests
14:16:07 <enikanorov_> samuelbercovici: that's possible
14:16:20 <avishayb> enikanorov_: is there a cetral place where we can store the logs and have a public URL for them?
14:16:35 <samuelbercovici> we should revert to being a voting CI until we get this fixed, otherwise we will fail tests for nothing
14:16:35 <avishayb> *central
14:16:56 <enikanorov_> avishayb: i don't know, honestly
14:17:08 <Vijay> mark: You had marked the NetScaler driver commit on hold till External Testing System is ready.
14:17:18 <Vijay> Now it is up.
14:17:49 <enikanorov_> markmcclain: do you think you can remove -2 from netscaler driver patch since their CI is up?
14:17:49 <samuelbercovici> btw -  is there going to be review on what the CI system do for testing?
14:18:13 <Vijay> link: https://review.openstack.org/#/c/57524/
14:18:17 <enikanorov_> samuelbercovici: i think publicly available logs are the good representation of what CI is doing
14:19:19 <samuelbercovici> enikanorov_: correct. so are public logs mandatory to approve a CI?
14:19:54 <enikanorov_> yes, this is a requirement. afaik currently new CIs are not given a right to vote in gerrit until infra folks approve it
14:20:07 <markmcclain> Vijay: ideally I'd like to see a few more votes from the system before merging
14:20:50 <enikanorov_> removing -2 is not giving +2! :)
14:21:03 <enikanorov_> but it gives the feeling that patch is not hopeless
14:22:09 <enikanorov_> ok, let's move to the next item
14:22:23 <enikanorov_> #topic ssl extension
14:23:03 <enikanorov_> #link https://review.openstack.org/#/c/63510/
14:23:19 <enikanorov_> the patch itself is in a good shape i would say
14:23:38 <enikanorov_> although we had some confusion on choosing the best implementation approach
14:23:48 <enikanorov_> should it be a separate db-plugin
14:23:56 <enikanorov_> or a part of lbaas plugin, e.g. mixin
14:24:10 <enikanorov_> markmcclain: hi
14:24:13 <evgenyf> Yes, I need a review
14:24:34 <evgenyf> Currently it's undependent extension
14:24:53 <evgenyf> Not part of the LbaaS plugin
14:25:23 <evgenyf> I'm working on unit tests implementation for extension
14:25:39 <enikanorov_> I have 2 concerns here, one is that this extension is specific to one provider, another one is that we might not be able to implement it for haproxy
14:25:53 <enikanorov_> markmcclain: i guess you have something to say on this matter
14:26:08 <samuelbercovici> to add some context on the decision to implement as an extension and not on LBaaS.
14:26:42 <markmcclain> yeah…we can't put ssl as a common ext because haproxy does not support it
14:27:14 <markmcclain> hopefully haproxy will finally decide to release instead of carrying a dev branch for 2 yrs
14:27:16 <samuelbercovici> Discussion with markmcclain have pointed to several chalenges in implementing it immediately in ha proxy
14:27:44 <samuelbercovici> 1. ha proxy 1.5 is not ga yet, obvisously this can still be implemented with ha proxy 1.4 + stunnel
14:28:16 <s3wong> haproxy 1.5 is quite ambitious - so it may take some time for all the features to be ready to make it a stable release
14:28:26 <samuelbercovici> 2. the communication channel of the AMQP is currently not secured and it would not be proper to push certificates to HA proxy via unsecured channel
14:28:42 <enikanorov_> yes, this is understood
14:29:08 <enikanorov_> the question would be about how we do it. ssl is desired feature
14:29:19 <evgenyf> The extension is not limited to provider, technically, but provider which does not implement the ssl API will get "UnsupportedExtensionException"
14:29:25 <enikanorov_> but putting it as a common extension is a bit misleading right now
14:29:43 <markmcclain> I agree that ssl is desires
14:29:56 <markmcclain> stunnel+1.4 could be a viable alternative path
14:30:00 <samuelbercovici> 3. markmclain did not approve of storing the private key in the database. ideally this should wait for babican
14:30:10 <markmcclain> which then means we've got to solve the 2nd side of the equation
14:30:27 <enikanorov_> ok, the alternative approach could be:
14:30:37 <enikanorov_> 1) introduce vendor extension framework
14:30:37 <markmcclain> how to transmit and store cert
14:30:42 <enikanorov_> 2) put ssl ext under /radware
14:31:08 <samuelbercovici> all of this lead us to approach this as an extension so we can have the API as "experimental"
14:31:34 <samuelbercovici> the extension by itself was discussed with community and it should be possible to be used by any vendor
14:32:00 <enikanorov_> samuelbercovici: yes, but as i understand that it is a general policy
14:32:05 <samuelbercovici> the implementation will try to check if this is supported by a driver and if so will call the driver
14:32:15 <enikanorov_> to publish the API when it has an opensource backend impl
14:32:45 <samuelbercovici> well, if you look at the many extension that NVP has some of them do not have opensource extension
14:32:57 <markmcclain> if stunnel+1.4 proves viable then I'd consider making an experimental community ext
14:33:18 <samuelbercovici> when we get this implemented with AH proxy, than we can decide to move it as part of the LBaaS api and not an extension
14:33:28 <markmcclain> but we'd have to release with the caveat that cert mgt likely needs lots of auditing
14:33:45 <enikanorov_> yes
14:34:01 <enikanorov_> samuelbercovici: to me whole question is how this extension is presented
14:34:09 <enikanorov_> and how it is configured
14:34:16 <markmcclain> how much interaction have the people here had with the barbican team?
14:34:27 <enikanorov_> if it is a vendor extension, that solves pretty much all of the issues
14:34:39 <markmcclain> enikanorov_: kind of
14:35:00 <markmcclain> CVEs can still be created for vendor extensions
14:35:17 <markmcclain> so we don't want to knowingly release something insecure
14:35:35 <enikanorov_> i'd like to know more about policies around that
14:35:53 <markmcclain> enikanorov_: policies on CVEs or releasing insecure code?
14:36:07 <samuelbercovici> pardon for ignorance, what is CVEs?
14:36:17 <enikanorov_> yes, so we have vendor stuff and opensource stuff
14:36:54 <enikanorov_> markmcclain: and following your words, it looks like responsibility is the same and lays on the team maintaining the project
14:37:11 <markmcclain> samuelbercovici: see http://cve.mitre.org
14:37:35 <markmcclain> it does but when there is code in the master neutron tree (even vendor plugins)
14:38:08 <markmcclain> the CVE burden is shared by the members of the OpenStack security, neutron security, and release management teams
14:38:40 <enikanorov_> in other words, we need to care of vendor code as about other
14:38:57 <markmcclain> correct… I'll be leaning on the vendors to fix their code
14:39:09 <markmcclain> but releasing and managing that fix requires many folks
14:40:24 <enikanorov_> i see. i know samuelbercovici doesn't like to depend on other work/patches,  but then I'd propose to introduce ssl as vendor extension. I think it will not require major change in already written code.
14:40:44 <enikanorov_> I mean, to integrate it via vendor extension framework
14:41:42 <evgenyf> enikanorov_: What you mean by "vendor extension framework"?
14:42:47 <enikanorov_> evgenyf: that was the proposal to add another way extension are loaded. for instance, instead of plugin declaring extension aliases that it supports, it also could ask drivers what extensions they support
14:43:07 <enikanorov_> and it exports extension itself, and not the alias
14:43:18 <enikanorov_> so your driver can directly inject new resources into API layer
14:43:50 <enikanorov_> and it will be visible only when your driver is configured
14:43:55 <evgenyf> I c. Is there any info about this proposal?
14:44:08 <samuelbercovici> enikanorov_: do u have this already implemented?
14:45:12 <enikanorov_> I was implementing it behind the scenes but that items had low priority in my list. now i think i'll move it up, so expect me to post the code at the end of the next week
14:45:38 <samuelbercovici> markmcclain: 10x (about CVEs)
14:45:51 <enikanorov_> evgenyf: there is a blueprint on this
14:46:00 <enikanorov_> let me find the link
14:47:04 <samuelbercovici> enikanorov_: as u already know me ;-) lets work in paralel. we can always fix this
14:47:13 <samuelbercovici> when urs is ready
14:47:20 <enikanorov_> i agree
14:48:11 <samuelbercovici> to return back to the question for markmcclain, is the approach (extension) is acceptable?
14:48:27 <enikanorov_> evgenyf: https://blueprints.launchpad.net/neutron/+spec/lbaas-extensions
14:48:34 <evgenyf> enikanorov_: Thanks
14:48:50 <enikanorov_> evgenyf: apparently it doesn't have much description
14:49:32 <enikanorov_> evgenyf: lets discuss it offline. anyway the idea was to be able to write extensions in the regular way, so I expect your code mostly unaffected
14:51:06 <samuelbercovici> markmcclain: (to use the proper irc syntax). is the approach to introduce SSL temination as an extension, declare as experimantal and when we finished "grilling" it and having a complete opensource solution, move it as part of the API?
14:51:19 <evgenyf> enikanorov_: Ok
14:53:30 <enikanorov_> ok, lets move to l7 rules meanwhile
14:53:33 <enikanorov_> #topic l7 rules
14:53:36 <enikanorov_> avishayb: hi
14:53:41 <avishayb> hi
14:53:58 <avishayb> my current work is here https://review.openstack.org/#/c/61721/12
14:54:27 <avishayb> mainly the DB layer plus some REST
14:54:31 <markmcclain> enikanorov_: sorry… pulled into discussion… I'm still a little unsure of having drivers add resource extensions
14:54:48 <markmcclain> mainly because that creates an uneven API experience
14:55:29 <enikanorov_> in that case we're stuck
14:55:31 <enikanorov_> :)
14:57:10 <enikanorov_> markmcclain: what would be the way to add ssl extension in J then?
14:58:19 <enikanorov_> we have 2 minutes left
14:59:32 <markmcclain> enikanorov_: hopefully haproxy will be available then
14:59:36 <markmcclain> and we can just make it core
14:59:51 <samuelbercovici> but untill then....
15:00:12 <enikanorov_> so will you propose to implement correspoding code for haproxy meanwhile?
15:00:20 <samuelbercovici> also, as said, this can be done with stunnel + 1.4
15:00:46 <enikanorov_> ok. we need to wrap up, we can continue discussion on neutron channel
15:00:53 <enikanorov_> thanks everyone for joining
15:00:55 <enikanorov_> #endmeeting