15:04:47 <tmorin> #startmeeting bgpvpn
15:04:48 <openstack> Meeting started Tue Jun 16 15:04:47 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:51 <openstack> The meeting name has been set to 'bgpvpn'
15:04:58 <matrohon> hi
15:05:15 <pcarver> hi
15:05:16 <svinota> hello
15:05:23 <tmorin> hi everyone
15:05:44 <pc_m> o/
15:06:03 <tmorin> we have only a light agenda for today
15:06:10 <ramanjaneya> Hello everyone
15:06:18 <matrohon> #topic Announcement
15:06:53 <matrohon> bgpvpn is under the openstack repo, not in stackforge anymore
15:07:07 <pc_m> nice!
15:07:49 <matrohon> https://review.openstack.org/#/c/186041/
15:07:56 <matrohon> ^ the related patch
15:08:01 <tmorin> the .gitreview, READMEs have been updated
15:08:52 <matrohon> any other announcement anyone?
15:09:14 <tmorin> no, I think we can go through last week's action points
15:09:27 <tmorin> "ACTION: tmorin to     update specs to indicate that DB will store only import_rts and     export_rts"
15:09:38 <tmorin> I updated the specs accordingly
15:09:46 <tmorin> #topic action items
15:10:18 <tmorin> pc_m , don't hesitate to have a look to confirm that my change reflects what you had in mind
15:10:21 <tmorin> if you did not already
15:10:39 <pc_m> tmorin: will do
15:11:01 <tmorin> we will put the .rst file into a doc subdir in networking-bgpvpn
15:11:39 <tmorin> my understanding is that the current change request for neutron-specs will be useless at that point
15:11:51 <svinota> ok
15:11:59 <tmorin> but we'll link to it for reference, there are a few useful discussions in there
15:12:18 <tmorin> #action tmorin to move spec rst into networking-bgpvpn/doc
15:12:37 <tmorin> next item:  "ACTION: tmorin to     investigate unit test coverage to db persistency"
15:13:11 * tmorin did not advance much, was only able to start looking how its done in other projects
15:13:42 <tmorin> #action tmorin to investigate unit test coverage to db persistency
15:13:59 <tmorin> next item: "ACTION: vikram to     update  python-neutronclient code"
15:14:25 <tmorin> vikram ain't here AFAICT
15:14:49 <tmorin> nor dhruv
15:15:14 <tmorin> next item: "svinota to work on DB mappings and RD (mostly done)"
15:15:37 <svinota> not so mostly, as I thought
15:16:00 <svinota> was a bit overloaded, so postponed everything. Will continue this week.
15:16:08 <tmorin> ok, good
15:16:46 <tmorin> (the next action item was on the new repo)
15:17:03 <tmorin> #topic driver status
15:17:50 <tmorin> any update on this front ?
15:18:07 <tmorin> in particular on odl side ?
15:18:34 <svinota> ODL — no info
15:19:08 <tmorin> ok
15:19:20 <svinota> will ping Chris, maybe I missed something
15:19:51 <ramanjaneya> Hi this ramanjaneya from Vikram team..
15:20:07 <svinota> hi!
15:20:13 <tmorin> nothing urgent nor mandatory, but I guess i can be interesting to have an idea
15:20:30 <tmorin> hi ramanjaneya
15:21:43 <tmorin> #topic functional tests
15:22:00 <ramanjaneya> Vikram join tomorrow..and we will work on neutron client changes
15:22:09 <tmorin> ok
15:22:12 <tmorin> good :)
15:22:32 <matrohon> I'm following what is done in the neutron side
15:22:44 <matrohon> with the fullstack framework
15:22:54 <matrohon> for instance : https://review.openstack.org/#/c/190832/
15:23:07 <tmorin> can you describe quickly what the func test would look like for bgpvpn
15:23:16 <tmorin> what pieces it would exercise and so on
15:23:17 <tmorin> ?
15:23:47 <matrohon> actually it runs processes such as l2 agent, l3 agents
15:24:00 <matrohon> neutronserver and so on
15:24:26 <matrohon> it's useful to have end-to-end tests
15:24:33 <tmorin> definitly so
15:24:49 <matrohon> it uses the lib Fixture to auto  create and destroy object and processes
15:25:33 <matrohon> there are som fixture available to emulate a VM! and ping them
15:26:26 <matrohon> for bagpipe, it would useful, since it's only few componenet that might be descibed with Fixtures
15:26:49 <matrohon> maybe il would be painful for 3rd party sdn controller
15:27:28 <tmorin> ok, so in these functional test, for bagpipe driver, they would spawn the modified ovs agent and bagpipe-bgp
15:27:56 <matrohon> yep
15:28:09 <tmorin> doing multinode tests would make it easy to exercise ovs
15:28:34 <tmorin> but without multinode, some work will be required to simulate multiple bagpipe-bgp instances
15:28:47 <matrohon> there are also ongoing discussions to have a more pluggable l2agent :
15:28:50 <matrohon> https://review.openstack.org/#/c/189723/
15:29:22 <matrohon> I'll try to help on that part to make it useful for bagpipe
15:29:43 <tmorin> pluggable l2agent is not specific to functional test, though
15:30:18 <tmorin> svinota, had you any particular ideas on functional tests ?
15:30:34 <tmorin> the other part we may want to cover is tempest tests
15:30:56 <tmorin> do we think we need both fullstack tests and tempest tests ?
15:30:58 <svinota> I have some. But not sure they will be appreciated much
15:31:10 <tmorin> please go ahead :)
15:31:24 <tmorin> or we leave this meeting bored
15:31:25 <tmorin> :)
15:31:32 <svinota> since I'm trying to make real tests with real VMs with BGP stack installed
15:32:15 <tmorin> real VMs being running a BGP stack like quagga's or a closed-source bgp stack ?
15:32:29 <svinota> quagga as a beginning
15:32:44 <svinota> actually, I need (for other task) a tool to run several VMs infrastructure that form an isolated network segment
15:32:54 <tmorin> not a bad idea to have tests that really cover interop with non-bagpipe implementations
15:32:57 <svinota> with a code injected on each node
15:33:26 <svinota> and I am not sure they will like it in the the openstack team
15:33:52 <svinota> but I will definitively publish it as soon as I get the system up & running
15:33:54 <tmorin> you bgp test VMs would be spawned on a admin vlans to which the bagpipe bgp implems would be connected ?
15:34:02 <tmorin> spawned by openstack itself
15:34:07 <tmorin> or your tool would do it ?
15:35:04 <svinota> not sure I got the question
15:35:05 <tmorin> I'm not sure I get what you mean by "code injected on each node": what code ? node==VM ?
15:35:20 <svinota> ok, step by step:
15:35:27 <tmorin> would the VMs be spawned by openstack/nova or by another tool ?
15:35:32 <tmorin> yes;)
15:37:01 <svinota> 1. prepare a bunch of VM images (get from a repo); 2. using guestfs inject all the code I need (OpenStack: Neutron, bagpipe, etc.); 3. in the same way inject testing framework that will start tests, will be run from rc.local
15:37:56 <svinota> 4. boot VM using libvirt; 5. wait until a condition; 6. shutdown nodes, collect results
15:38:30 <svinota> reasons: I'm going to test 3rd-party unreliable code, and I must isolate it from ANY network
15:39:03 <svinota> VM can be interconnected, but the host must have no connection to VMs
15:39:04 <matrohon> why not running devstack?
15:39:15 <tmorin> looks a bit like what zuul is doing for CI, no ?
15:39:24 <svinota> tmorin, probably
15:39:27 <tmorin> apart maybe the isolation requirement
15:39:44 <svinota> matrohon, since I tried and failed — probably I'm too stupid, not sure yet
15:40:15 <matrohon> we can surely help :) what is failing on devstack?
15:40:21 <matrohon> the bagpipe part?
15:40:33 <svinota> tmorin, the issue is that for me the isolation is a requirement. I can not trust no change I didn't review, and this solution should work even with not yet reviewed code
15:41:43 <tmorin> I've nothing particular pro or against the tool that you are writing, but I would be more confortable if networking-bgpbpn would use tools already used by other projects
15:41:43 <svinota> matrohon, let me ping you on Thursday and I will try to do the same (not literally the same, but what can do) with the devstack
15:41:57 <tmorin> that is, unless we hit issues with these tools
15:41:59 <matrohon> svinota : great!
15:42:25 <svinota> matrohon, since I believe I miss something, and will be glad not to invent nothing new
15:43:15 <svinota> matrohon, most of issues are about unpredictable devstack deployment — sometimes it refuses to start 'cause of (probably) races
15:43:46 <matrohon> devstack is not always reliable!
15:44:09 <svinota> matrohon, then it can not be used for testing, can it be?
15:44:36 <tmorin> there are a few things that I had to learn to be able to use devstack
15:44:54 <tmorin> like doing an unstack.sh before doing a stack.sh
15:44:58 <matrohon> it is used for CI with some masterised parameters
15:45:06 <tmorin> stack.sh must start on clear ground
15:45:59 <matrohon> if one try to mix some devstack parameters that are never mixed in the CI jobs, it might fail
15:46:11 <svinota> ok, so let's try on Thursday — I really can be wrong and this will save me several days of work
15:46:24 <matrohon> for instance using the bgpvpn devstack plugin :)
15:46:34 <svinota> matrohon, oh yes :)
15:46:46 <tmorin> but we definitely can work out a working config for openvswitch agent + bgpvpn service driver + bagpipe driver
15:47:01 <tmorin> and the result should be reliable enough for CI testing
15:48:09 <svinota> I just realized that these tools can be used together — devstack with what I try to design for an isolated testing
15:48:38 <matrohon> svinota : you can have a look at my devstack conf here : https://github.com/mathieu-rohon/devstack-conf/tree/master/test_bgpvpn_bagpipe
15:48:57 <matrohon> They propbably need an update though
15:49:30 <svinota> matrohon, thanks
15:49:37 <svinota> got it, reading
15:50:06 <tmorin> using tempest based on such a devstack would be a possible approach
15:51:04 <tmorin> writing tests that would call the BGPVPN API, and test how results are applied (e.g. pinging between VMs in two distinct networks bound to a common VPN, or between a tenant VM and a VRF on a quagga VM)
15:51:30 <matrohon> svinota : at least, the bgpvpn repo has to be changed in the local.conf, since it's not stackforge anymore but openstack
15:51:42 <svinota> yep
15:51:59 <matrohon> tmorin : that would be great for a CI job
15:52:11 <tmorin> yes
15:52:38 <matrohon> it needs some tempests patches
15:52:52 <tmorin> to add the new tests ?
15:53:10 <tmorin> can't they be in our project ?
15:53:20 <matrohon> I think yes, I'm not sure how tempest is pluggable
15:53:49 <svinota> I believe they can be anyways. If not, we can make it pluggable :)
15:53:58 <tmorin> doing the "pinging between VMs in two distinct networks bound to a common VPN" would be easy to do if we have the ability to run multi-node tempest tests
15:54:05 <tmorin> svinota: yes
15:54:25 <tmorin> other projects would probably be in the same situation as ours
15:55:08 <tmorin> we need to see with openstack-infra how feasible it would be to have multi-node tests
15:55:27 <matrohon> I'm not sure that running multi-node tests in the infra is the easy way. I'm not sure that the infra team is really keen on multi-node tests
15:55:56 <matrohon> I would bet on fullstack tests in a first attempt
15:56:06 <tmorin> ok
15:56:16 <tmorin> both are complementary I understand
15:56:34 <tmorin> tempest tests would have the benefit of not being tied to a specific backend
15:58:18 <matrohon> yep, but even with a tempest test, Im not sure the gate would be able to deploy a sdn controller such as ODL
15:58:42 <matrohon> this would need a third party testing to vote on bgpvpn changes
15:59:56 <tmorin> ok, we'll see
16:00:00 <tmorin> we are out of time
16:00:09 <tmorin> #topic next meeting
16:00:31 <tmorin> next week the goal is to try to have everyone present to discuss attachement options
16:00:34 <tmorin> router, subnet, networks
16:00:45 <tmorin> it would be nice to have everyone
16:00:46 <svinota> ok. I'll be here.
16:00:47 <tmorin> including diego
16:00:56 <tmorin> tim
16:01:05 <tmorin> and ideally someone from contrail too
16:01:17 <tmorin> we need to free the room now :)
16:01:22 <tmorin> thanks everyone
16:01:25 <matrohon> thanks
16:01:28 <tmorin> #endmeeting