14:01:00 <enikanorov> #startmeeting neutron lbaas
14:01:01 <openstack> Meeting started Thu Jan  9 14:01:00 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:20 <russellb> nova will meet over in #openstack-meeting-alt
14:01:28 <enikanorov> hi, whos online for lbaas meeting except Vijay_?
14:01:45 <s3wong> enikanorov: Hello
14:01:50 <enikanorov> s3wong: hi
14:02:13 * pcm_ lurking :)
14:02:21 <sbalukoff> I'm lurking as well.
14:02:21 <enikanorov> pcm_: hi!
14:02:31 <pcm_> enikanorov: Hi
14:03:08 <enikanorov> ok, the new year and cristmass holidays are over for most of us
14:03:35 <enikanorov> lets go over the list of action items we have for lbaas
14:03:48 <enikanorov> #topic 3rd party testing
14:04:24 <enikanorov> it seems that a number of vendors has set up their environment and their systems are already voting in jenkins
14:04:52 <enikanorov> at this moment we only need one from radware
14:05:10 <enikanorov> but it looks like their folks are absent today
14:05:22 <enikanorov> Vijay_: did you have some specific questions on the matter?
14:05:23 <Vijay_> enikanorov: Netscaler driver is blocked for dependency on external testing...
14:05:31 <Vijay_> It is up and running today
14:05:39 <enikanorov> how is it blocked?
14:05:57 <Vijay_> Mark has blocked...it
14:06:02 <Vijay_> saying waiting for external testing
14:06:13 <Vijay_> what is the expectation of external testing...
14:06:19 <Vijay_> today it tests LBaaS API tests
14:06:22 <enikanorov> yes, so he meant that you (citrix) need to setup such testing system that will vote
14:06:48 <enikanorov> lbaas scenario test is still on review, but is close to merging
14:07:11 <Vijay_> can physical appliances be tested using lbaas scenario tests?
14:07:16 <enikanorov> i hope you are not waiting for that moment and are working in parallel to setup testing environment
14:07:26 <enikanorov> Vijay_: that's the point
14:07:56 <enikanorov> Vijay_: scenario test is just a script that perform operations that a regular user would do
14:08:00 <Vijay_> We run tempest LBaaS API tests and some internal tests similar to scenario tests
14:08:01 <enikanorov> and it is backedn-agnostic
14:08:43 <enikanorov> so the only thing your system needs to do is to setup neutron-server to use your provider (netscaler) as the default one
14:09:05 <Vijay_> will it work for physical appliances or VLAn based isolation environments?
14:09:15 <Vijay_> where namespaces are present?
14:09:41 <enikanorov> why the question?
14:09:58 <Vijay_> because tempest scenario tests are failing in our setup
14:10:05 <Vijay_> it is not able to access the servers
14:10:10 <Vijay_> or nova vms
14:10:49 <enikanorov> you should investigate that. that could be a misconfiguration of your environment
14:11:03 <enikanorov> but tempest doesn't make assumptions on backend network implementation
14:11:16 <enikanorov> however, devstack does some assumptions
14:11:36 <enikanorov> so you need to see, if your appliance can work with what devstack configures
14:12:01 <Vijay_> we have configured devstack to use with ML2 + VLAN
14:12:01 <enikanorov> i think we can discuss it specifically
14:12:08 <enikanorov> ok
14:12:14 <Vijay_> and device is able to access the VLANs
14:12:22 <enikanorov> ok
14:12:27 <Vijay_> and the servers
14:12:32 <Vijay_> but tempest is the one which is not able to access the Server
14:12:43 <Vijay_> server == nova vms
14:12:52 <enikanorov> i see
14:13:08 <enikanorov> so if you look at stack.sh
14:13:08 <Vijay_> so where should the tempest run?
14:13:12 <Vijay_> in the controller node?
14:13:26 <enikanorov> it doesn't matter, actually.
14:13:47 <enikanorov> tempest should be able to access api servers. access to vms should be provided by the devstack
14:13:57 <enikanorov> it is done for default devstack configuration
14:14:14 <enikanorov> by adding the route to the tenant network, created by devstack
14:14:29 <enikanorov> that is not your case, so you need to provide connectivity to vms yourself
14:14:56 <Vijay_> Let me just do one more round of investigation to see if tempest can be run outside of devstack
14:15:20 <enikanorov> check tempest.conf, i think it has some setting about tenant network availability
14:15:48 <enikanorov> so the thing is, tenant network is not directly reachable from controller by default
14:16:16 <enikanorov> you need to provide connectivity based on your network implementation
14:16:41 <Vijay_> hmm....let me check
14:16:50 <Vijay_> who will be right contact person
14:16:55 <Vijay_> to get in touch with for such queries?
14:17:33 <enikanorov> you can contact me, or ping on irc
14:17:43 <Vijay_> Ok. Done. Thanks!
14:18:24 <Vijay_> So, just to conclude, the expectation from 3rd party testing is to run both API testing and scenario testing?
14:18:31 <Vijay_> ? == .
14:19:22 <enikanorov> well, i'd say, both
14:19:44 <Vijay_> Yes, Both.
14:19:45 <enikanorov> both test suites can catch issues
14:20:20 <enikanorov> the question could also be - what kind of patches you need to test
14:20:38 <enikanorov> i mean you probably have a system that analyses patches
14:20:55 <enikanorov> and decides if it needs to run tests against the patch
14:21:22 <Vijay_> Yes, if the patches are related to tempest tests, lbaas or the driver, then the tests are run.
14:21:42 <enikanorov> ok
14:22:05 <Vijay_> it patches the code in devstack, runs stack.sh, configures netscaler driver and then restarts neutron
14:22:34 <Vijay_> runs api tests, collects logs from all systems - devstack, netscaler etc..
14:22:54 <enikanorov> good. looking forward to see the results
14:22:57 <Vijay_> and then uploads to a publicly accessbly url
14:23:05 <Vijay_> it is already up...
14:23:15 <Vijay_> but today it tests only netscaler submissions
14:23:16 <enikanorov> has it posted anything on gerrit?
14:23:21 <enikanorov> i see :)
14:23:21 <Vijay_> yes
14:23:34 <Vijay_> once netscaler is submitted
14:23:44 <Vijay_> it will start testing the tempest and lbaas core changes as well
14:24:32 <enikanorov> so if i submit something with serivces/loadbalancer/drivers/netscaler i will get a vote from your system?
14:24:45 <Vijay_> sure,
14:24:52 <enikanorov> cool!
14:24:56 <Vijay_> i have several times now :-)
14:25:20 <enikanorov> ok. lets move on
14:25:34 <enikanorov> we don't have usual set of devs here today
14:25:55 <enikanorov> so i'll skip status updates and will publish them in follow up email
14:26:13 <enikanorov> one interesting thing going on in neutron is this:
14:26:23 <enikanorov> https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
14:26:28 <enikanorov> !link
14:26:30 <openstack> enikanorov: Error: "link" is not a valid command.
14:26:31 <enikanorov> #link https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
14:26:51 <Vijay_> we have to discuss on the pool member status collection as well.
14:27:17 <enikanorov> i have not yet time to deeply study it, but it is something worth looking at, especially for those who work on routed solutions
14:28:03 <s3wong> enikanorov: it is interesting, and really even in haproxy driver we should refrain from hardcoding association with L3 agent
14:29:27 <s3wong> ML2 plugin, for example, fetches "l3service' from .ini file; perhaps if haproxy wants to have routed service support, we should use a similar model?
14:29:29 <enikanorov> i think we could have a separate discussion on this. but thinking of haproxy, i don't think it is much affected
14:30:23 <enikanorov> at least with it's current model.
14:30:40 <enikanorov> currently we don't have plans to add routed support for haproxy provider
14:30:51 <enikanorov> but it is something we can consider later
14:31:18 <enikanorov> at least for now users seem to use haproxy with floating ips
14:32:20 <enikanorov> Vijay_: regarding statistics
14:33:02 <enikanorov> I'd suggest doing the following: you create a mechanism in your driver. if you manage to make it generic enough, we could then use it in other drivers
14:33:52 <Vijay_> it necessaites creating separate threads. Is there any recommendation
14:33:57 <enikanorov> it's not that i'm against the feature, but we have a long list of them, so if someone wants something, you know, you need to go for it and implement it :)
14:34:36 <enikanorov> well, yes, existing implementations use separate thread in either way
14:35:01 <Vijay_> Running in controller?
14:35:23 <Vijay_> because threads initiated in driver will run in controller
14:35:49 <enikanorov> it doesn't matter, IMO. you wait on queue from the agent, or you wait on network IO
14:36:25 <Vijay_> netscaler driver does not have an agent
14:36:32 <enikanorov> so I see it as some async process updating db, that's it
14:36:46 <enikanorov> so your driver need to start the thread that will gather the stats
14:37:34 <enikanorov> the question you need to resolve is how to do it in such way that you can process many devices with one thread
14:37:52 <enikanorov> so if one becomes slow or unresponsive that doesn't block others
14:38:53 <Vijay_> for agent less cases, especially for netscaler/radware,  the collection is usually from another piece of software not a device/appliance.
14:39:17 <Vijay_> all collection goes to he intermediate software
14:39:25 <Vijay_> *the
14:39:42 <enikanorov> i'm not sure i understood the question
14:40:34 <Vijay_> I am just saying that all devices stats are queried from the same system. so if it is slow for collection of one device, then it will slow down for others as well
14:41:09 <Vijay_> i am just worried, that introducing such logic in netscaler driver will unnecessarily delay the committing of the driver.
14:41:30 <enikanorov> no, the key point that one device should not slow down collection from others
14:42:07 <enikanorov> the task itself is not very complex
14:43:00 <enikanorov> anyway, i think it's not a requirement to have all the features at once to commit the driver
14:43:12 <Vijay_> ok
14:43:28 <enikanorov> but i think it is not very difficult to implement such stats collection.
14:43:36 <Vijay_> ok
14:44:07 <Vijay_> ok. we can move on i guess. Did any get to review ssl or L7 rules.
14:45:08 <enikanorov> I think ssl is in a good shape, as far as i remember
14:45:41 <enikanorov> but as you know, the core team focus is on gate-blockers and parallel testing
14:46:07 <enikanorov> hopefully after the tempest code sprint thing could change in favor of advanced services :)
14:46:11 <enikanorov> *things
14:46:23 <Vijay_> ok.
14:47:09 <enikanorov> ok, one more item is about services.conf file
14:47:32 <enikanorov> which has been introduced to collect vendor-specific options for advanced drivers
14:48:31 <enikanorov> lately there was a discussion on the matter and Sean Dague has objections on having another conf file that needs to be passed to neutron-server on startup
14:49:13 <enikanorov> so depending on discussion outcome we may need to move to another model where each provider will have it's own conf file and neutron.conf will just reference it.
14:49:25 <enikanorov> but that is just to inform you.
14:49:41 <Vijay_> ok
14:50:57 <enikanorov> ok, i think we can end the meeting then
14:51:06 <enikanorov> thanks for joining, Vijay_ s3wong
14:51:11 <Vijay_> Ok. Bye then.
14:51:16 <enikanorov> #endmeeting