14:02:28 <enikanorov> #startmeeting nuetron lbaas
14:02:29 <openstack> Meeting started Thu Nov 28 14:02:28 2013 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:33 <openstack> The meeting name has been set to 'nuetron_lbaas'
14:02:39 <openstack> enikanorov: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
14:02:49 <enikanorov> ok, let it be nuetron :0
14:02:56 <enikanorov> #topic announcements
14:03:14 <Vijay_> hi
14:03:21 <enikanorov> we're currently working on basic scenario tests in tempest for lbaas service
14:03:30 <enikanorov> you can find one on the review:
14:03:40 <enikanorov> #link https://review.openstack.org/#/c/58697/
14:04:10 <enikanorov> I'd like to ask everyone who is working on their drivers to setup devstack environment with their solution and run this test
14:04:15 <enikanorov> and let us know the results
14:04:59 <enikanorov> this scenario checks basic operations and performs actoal end-to-end verification of balancing and connectivity
14:05:45 <enikanorov> any questions on testing?
14:06:07 <avishayb> we will start working on this soon. (next week)
14:06:25 <enikanorov> ok, cool
14:07:07 <enikanorov> meanwhile I suggest everyone working on particular features will create some kind of test plan that later will need to be implemented in tempest
14:07:17 <enikanorov> for each particular feature
14:07:20 <Vijay_> ok
14:08:01 <enikanorov> moving to the next topic
14:08:10 <enikanorov> #topic bugs
14:08:32 <samuelbercovici> hi everyone
14:08:51 <enikanorov> hi Sam
14:08:57 <enikanorov> on bugs side there is https://review.openstack.org/#/c/55032/
14:09:05 <enikanorov> #link https://review.openstack.org/#/c/55032/
14:09:22 <enikanorov> which fixes discrepancy between admin state up  and status
14:09:34 <enikanorov> I really would like to see this as part of API
14:09:47 <enikanorov> so I'd appreciate any feed back on how you think it should be done
14:10:03 <enikanorov> i mean dependency between admin_state_up and status
14:10:06 <obondarev> how about members?
14:10:09 <avishayb> <enikanorov. we will review it
14:10:13 <enikanorov> since I'd like to see this covered by tempest API test
14:10:43 <enikanorov> obondarev: members are addition to this review. probably deserve it's own bug
14:10:47 <obondarev> if set member admin state to down - should it became INACTIVE as well?
14:10:59 <obondarev> thre is a bug actually
14:11:00 <enikanorov> obondarev: i think yes, it should
14:11:09 <obondarev> https://bugs.launchpad.net/neutron/+bug/1240916
14:11:11 <uvirtbot> Launchpad bug 1240916 in neutron "Changing the only member of a pool into admin state down should move the member and pool statuses to INACTIVE" [Undecided,Incomplete]
14:11:31 <obondarev> probably makes sence to add members handling to that patch
14:11:49 <enikanorov> ok, will do
14:11:57 <avishayb> Bug update: I have fixed a bug in horizon-lbaas. https://review.openstack.org/56821
14:11:57 <obondarev> note: only 'half' of that bug should be fixed
14:12:16 <enikanorov> obondarev: what so you mean?
14:12:50 <obondarev> bug is incomplete currently
14:13:02 <enikanorov> avishayb: cool
14:13:18 <enikanorov> obondarev: Incomplete was because of proposed PENDING state?
14:13:25 <obondarev> yes
14:13:37 <avishayb> we used to display the UUID of the HM - not very good..
14:13:40 <enikanorov> i think there's a consensus to change the status to INACTIVE
14:13:47 <obondarev> please see my comment on the bug
14:13:47 <enikanorov> i'll change it to Confirmed
14:14:34 <obondarev> I think we shouldn't change status of the pool if only have inactive members
14:14:46 <samuelbercovici> guys, this is the first time we see https://review.openstack.org/#/c/55032/ we will review offline and commit on the change
14:15:28 <enikanorov> obondarev: yes. We'll state it in comments once again.
14:15:49 <enikanorov> samuelbercovici: thanks
14:16:31 <obondarev> enikanorov: ok
14:16:54 <enikanorov> ok, moving to the next topic
14:17:06 <enikanorov> #topic features
14:17:23 <enikanorov> avishayb: can you update on L7?
14:17:41 <avishayb> yes
14:18:20 <avishayb> I did a good progress in understanding HAProxy L7 model It is updated in the wiki
14:18:40 <enikanorov> ok, good. we'll review
14:18:42 <avishayb> https://wiki.openstack.org/wiki/Neutron/LBaaS/l7#HAProxy_L7_Switching
14:19:06 <avishayb> I have addressed some of of your cooments - will finish by the end of today
14:19:18 <avishayb> * comments
14:19:46 <enikanorov> ok, would be good if you could ping me or send notification
14:19:54 <avishayb> I will
14:20:05 <Vijay_> does it support regex based comparison
14:20:13 <Vijay_> it == HAProxy
14:20:19 <avishayb> it is
14:20:29 <avishayb> Vijay_ - yes
14:21:56 <enikanorov> ok
14:22:04 <enikanorov> obondarev: any updates on HA agents?
14:22:13 <obondarev> sure
14:22:43 <Vijay_> Avishay: since that is the only operator that is proposed, you might want to update the spec with relevant examples
14:22:48 <obondarev> the idea is to monitor agents states - and to reschedule agent's devices if it goes down
14:23:17 <obondarev> reschedule to other active lbaas agents, if any
14:23:29 <avishayb> Vijay_: OK - I will try to come with more relevant examples.
14:23:52 <obondarev> one problem here is that agent may be down but device(port) and haproxy process still running
14:24:27 <obondarev> currently investigating how can we deal with it
14:24:30 <enikanorov> obondarev: another question that i was thinking about: will that require additional status like 'RESCHEDULING' or something?
14:24:47 <avishayb> Vijay. See: https://github.com/joewilliams/haproxy/blob/master/examples/acl-content-sw.cfg#L39
14:25:06 <obondarev> enikanorov: yeah, good point, can think on it too
14:25:47 <enikanorov> any new state can be additional pain...
14:25:58 <obondarev> agree
14:26:01 <Vijay_> also, like reqested last time, it will be good to know the driver api
14:26:49 <enikanorov> Vijay_: driver api reflects rest api mostly. see abstract driver code
14:27:02 <Vijay_> need not
14:27:08 <Vijay_> for ex. monitors dont
14:27:30 <Vijay_> L7 policies are not associated with the loadbalancers object
14:27:52 <enikanorov> Vijay_: that's something that needs to be discussed still
14:27:53 <Vijay_> during creation
14:28:37 <enikanorov> i don't see the reason to create it without binding to a vip and the pool, why?
14:29:19 <s3wong> obondarev: is health monitoring of the agent something that is exposed to admin (configurable) or hidden?
14:29:39 <enikanorov> also I don't remember anyone has replied to my email with suggestions on L7 rules (based on L& wiki page)
14:29:44 <obondarev> s3wong: it's hidden
14:29:53 <Vijay_> eugene: top of mind, i also think so
14:30:11 <Vijay_> but if it is addressed in the wiki, then it is easier to review
14:30:35 <enikanorov> ok, i'll check the wiki and will shoot another email
14:31:47 <Vijay_> move on SSL?
14:31:58 <enikanorov> loadbalancer instance please :)
14:32:04 <enikanorov> it's going to be short
14:32:04 <Vijay_> ok :-)
14:32:10 <enikanorov> on loadbalancer instance front there was not much progress last week
14:32:17 <s3wong> obondarev: most common implementation of haproxy HA is haproxy with keepalived - is something like VRRP + peer something you are thinking about?
14:32:20 <enikanorov> I've updated the wiki per someone's request
14:32:27 <enikanorov> with some cli examples
14:32:58 <enikanorov> still hoping to put initial implementation on review within I-1 timeframe hoping that folks will review in the beginning of I-2
14:33:28 <obondarev> s3wong: thanks for pointing, will look at it
14:34:08 <enikanorov> next one: SSL
14:34:21 <samuelbercovici> I will answer for evgenyf as he is not attending
14:34:48 <samuelbercovici> Evgeny, has added the missing pieces based on Vijay_ comments.
14:35:19 <samuelbercovici> Vijay_, we are waiting for you to conclude whether it is acceptable to use the "simaple" model
14:35:50 <Vijay_> eugene: just one simple question on loadbalancer instance
14:35:59 <samuelbercovici> Evgeny, also compared the proposeal to HA proxy and EC2. I think that we can complete the BP desing next week
14:36:13 <Vijay_> will vip-show command also list vips alsong with  loadbalancer id?
14:36:31 <Vijay_> may be that also can be captured
14:36:39 <samuelbercovici> I am slo trying to get reponse on when HAproxy 1.5 is expected to turn GA
14:37:12 <enikanorov> object-show usually shows only the object being specified in parameter
14:37:16 <Vijay_> Sam. I just checked other cloud provider implementations. (cloudstack)
14:37:22 <enikanorov> while balancer-show can shot full configuration
14:37:40 <Vijay_> and they seem to have introduced certificate as a separte entity fromt he beginning when they introduced SSL termination
14:38:08 <Vijay_> the question really to answer is
14:38:16 <Vijay_> why not store certificate in db
14:38:23 <Vijay_> or rather keys
14:38:36 <Vijay_> unless we have an answer to that we will not be able to decide
14:39:02 <enikanorov> Vijay_: can you post this question into openstack-dev?
14:39:24 <Vijay_> sure. i think sgran also posted on the similar regard
14:39:31 <Vijay_> i will refresh that thread
14:40:21 <Vijay_> also, Sam. Good to see the backend certificates and the cert chain accomodated in the model
14:40:31 <Vijay_> and the parity with AWS
14:40:33 <Vijay_> thanks@
14:40:35 <Vijay_> thanks!
14:41:46 <samuelbercovici> Vijay_: if we get acceptance to storing the certificate in the db, than I would also like a model with certificates as 1st citizen
14:42:16 <samuelbercovici> otherwise, I think that a "simple" model will work better until persisting is some place can be done
14:42:22 <enikanorov> i saw a patch from Nachi Ueno today, who is going to do so for SLL VPN
14:42:23 <Vijay_> i also agree!!
14:42:24 <enikanorov> *SSL
14:42:40 <samuelbercovici> Vijay_: please flush in irc and ML and lets see if we see any pushback
14:42:53 <samuelbercovici> on another matter.
14:43:49 <samuelbercovici> Evgeny has also published: https://blueprints.launchpad.net/neutron/+spec/neutron-quota-extension and will submit the patches for it by next week
14:43:56 <samuelbercovici> please review
14:44:19 <enikanorov> i've seen something on review for this bp i believe
14:44:51 <enikanorov> ok, we'll review
14:45:10 <samuelbercovici> enikanorov: thanks
14:45:19 <enikanorov> #topic open discussion
14:45:48 <samuelbercovici> I would liek to discuss 3rd party testing
14:45:54 <enikanorov> samuelbercovici: did your team start working on test environment and jenkins integration?
14:45:59 <enikanorov> yeah
14:47:29 <samuelbercovici> avishay will answer on this. i have a question
14:47:33 <enikanorov> samuelbercovici: so you've missed first few minutes where i was telling that we've published first tempest scenario test for lbaas
14:48:14 <samuelbercovici> enikanorov: yes, I have seen it. we will review to see if/how to reuse
14:48:29 <enikanorov> ok
14:48:52 <samuelbercovici> the question is for everyone. what system are you considering to use for the tests themeslevves? is it templest or something else?
14:49:05 <samuelbercovici> templest == tempest
14:49:06 <avishayb> We start working on the 3rd party testing and it looks like there are some generic sections. Here are the building blocks/flow:
14:49:29 <avishayb> 1) Listen to gerrit stream. Analyze incoming events
14:50:15 <avishayb> 1) When an event is "intersting" - fetch the code, push it to your local env and invoke tests
14:50:51 <avishayb> 3) publish back a report (fail / ok)
14:50:52 <enikanorov> tempest is just the testsuite, it has certain tools for managing the cloud (clients to all OS projects)
14:51:10 <enikanorov> the environment is up to you (to how to set it up)
14:51:36 <Vijay_> so avishay, will the the devstack be refreshed and rebuilt before merging the patch?
14:51:46 <Vijay_> *assuming the test setup is with devstack
14:52:12 <samuelbercovici> enikanorov: so how do you manage the setup / teardown before you run the testsuite?
14:52:25 <enikanorov> Vijay_: i think it's not necessary, theoretically
14:53:11 <enikanorov> samuelbercovici: what kind of setup?
14:53:26 <enikanorov> I think that your environment should be setup already
14:53:32 <samuelbercovici> idealy specking, the following should happen for the testsuite
14:53:40 <enikanorov> it should have neutron/nova/glance/etc running
14:53:44 <samuelbercovici> a. alocate a physcal box/vm
14:53:51 <enikanorov> and also you should have tempest configured for your setup
14:54:05 <samuelbercovici> b. install openstack for example using devstack
14:54:25 <samuelbercovici> c. add the patchset that needs testing
14:54:25 <enikanorov> yes, devstack should do, I think.
14:54:30 <samuelbercovici> d. run tests
14:54:39 <samuelbercovici> e. cleanup
14:54:56 <samuelbercovici> how do you "automate" a.-e.
14:54:58 <enikanorov> in fact, devstack could be configured to getch particular project from particular url (gerrit)
14:55:21 <enikanorov> well, i would do it either with bash scripts or with python
14:55:29 <enikanorov> whatever is easier for you
14:56:12 <samuelbercovici> enikanorov: do you know if anyone already did it as an open-source project?
14:56:56 <enikanorov> i don't think so since the solution should be very simple
14:56:58 <Vijay_> i was thinking of sligh change. 1) listen on stream, 2) on event, if interesting proceed, 3) refresh devstack code, 4) run stack.sh to cleanup setup. 5) configure the lb providers, setup and other environments 6) run the tempest test.
14:57:05 <samuelbercovici> for example, the currect standart tempest tests probaly already run in this way
14:57:11 <enikanorov> i don't expect it to be more than 2 screens of bash code
14:57:15 <Vijay_> step 0) is devstack setup.
14:57:24 <Vijay_> with tempest
14:58:23 <Vijay_> Step 7) Vote
14:59:45 <enikanorov> Vijay_: the flow makes sense to me
14:59:53 <enikanorov> ok, we need to wrap up
14:59:56 <enikanorov> #endmeeting