15:02:15 <carl_baldwin> #startmeeting neutron_routed_networks
15:02:16 <openstack> Meeting started Tue Sep 27 15:02:15 2016 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:20 <openstack> The meeting name has been set to 'neutron_routed_networks'
15:02:20 <carl_baldwin> #topic Announcements
15:02:44 <carl_baldwin> I won't be around for this meeting next week. So, let's cancel it. Just keep going on the same trajectory.
15:02:55 <mlavalle> ok, will do
15:02:56 <carl_baldwin> Newton RC-2 is imminent.
15:03:14 <carl_baldwin> Summit is just 4 short weeks away.
15:03:26 <mlavalle> yaaay
15:03:29 <carl_baldwin> I hope to see many people there.
15:03:51 <carl_baldwin> If you have docs bugs or changes that need to be done, now is a good time to do those.
15:04:03 <carl_baldwin> Any other announcements?
15:04:16 <carl_baldwin> I will be off most of the next week.
15:04:35 <carl_baldwin> From tomorrow until next Wednesday.
15:05:06 <carl_baldwin> Okay, moving on...
15:05:14 <carl_baldwin> #topic Testing
15:05:14 <mlavalle> ohhh, next week means "Routed Networks week"
15:05:50 <carl_baldwin> mlavalle: I just got that. Yes, that's what I mean. Not "calendar week"
15:05:55 <carl_baldwin> :)
15:06:25 <mlavalle> as for testing
15:06:31 <carl_baldwin> mlavalle: You have the floor now. You were mentioning some unexpected behavior...
15:06:55 <mlavalle> we added a test case to verify the api behavior as for as the ip_allocation attribute in ports
15:07:11 <mlavalle> we create an unbound port and we get no fixed ips
15:07:26 <mlavalle> and ip_allocation in 'deferred' as expected
15:07:36 <mlavalle> we then bind the port
15:07:55 <mlavalle> we get fixed ips
15:08:12 <mlavalle> but ip_allocation is still 'deferred'
15:08:33 <mlavalle> is that the expected behavior? I thought at that point it should be 'immediate'
15:08:44 <carl_baldwin> armax foresaw this confusion...
15:08:56 <mlavalle> maybe it's a misunderdstanding on my part
15:09:29 <carl_baldwin> We need to document this. I should create a documentation bug to ensure this doesn't get forgotten.
15:09:54 <carl_baldwin> The ip_allocation attribute just reflects how the port was created. That's all.
15:10:42 <mlavalle> ok, so a port update doesn't change what was left in ip_allocation by the create
15:10:46 <mlavalle> correct?
15:11:00 <carl_baldwin> Correcty
15:11:04 <carl_baldwin> s/y//
15:11:55 <mlavalle> cool!
15:12:01 <mlavalle> we will fix the test case
15:12:10 <carl_baldwin> mlavalle: Thanks.
15:12:40 <mlavalle> I have also started digging as to how we are going to create the multinode job in jenkins for the tests
15:12:57 <carl_baldwin> mlavalle: Cool, how is that going?
15:12:59 <mlavalle> multinode means 2 nodes
15:13:11 <carl_baldwin> 2 > 1. :)
15:13:16 <mlavalle> infra doesn't have anything larger than that
15:13:49 <carl_baldwin> mlavalle: It is possible to do two segments with two nodes. But, I'm not sure what will do the routing.
15:13:57 <mlavalle> so we have now a 2 node vagrant environment that Bin put together based on my original environment
15:14:02 <carl_baldwin> ... if we need that in the tests.
15:14:19 <mlavalle> we wanted to put the roiter in one of those two nodes
15:14:24 <mlavalle> router^^^
15:14:29 <mlavalle> it already works
15:14:50 <mlavalle> so we know we can have an allinone, a compute and a router in 2 vm's
15:15:33 <carl_baldwin> mlavalle: that works. I was thinking of that but wasn't sure if there would be any issues routing traffic from the provider network on that node through the "router" on the same node.
15:15:34 <mlavalle> what I am working on right now is in having enough interfaces in the compute / router node in the environment offered by infra
15:15:41 <carl_baldwin> mlavalle: I just hadn't thought it through all the way.
15:16:27 <mlavalle> we have the scenario test already working in that 2 node env. It tests connectivity between two vm's
15:16:39 <carl_baldwin> mlavalle: cool
15:16:49 <mlavalle> the challenge nowis to translate that to what infra offers us
15:17:15 <mlavalle> haleyb gave me some pointers yesterday that I have to follow
15:18:12 <carl_baldwin> mlavalle: Cool. haleyb is awesome that way.
15:18:18 <mlavalle> that's all I have today as far as update in testing
15:18:25 <carl_baldwin> mlavalle: Thanks.
15:18:36 <carl_baldwin> Anything else for today's meeting?
15:18:39 <carl_baldwin> #topic Open Agenda
15:18:42 * mlavalle thinks haleyb is awsome in many ways
15:18:59 <haleyb> mlavalle: np, you're very welcome
15:19:01 <carl_baldwin> Basically, review the transcript from two weeks ago. That is still the direction we need to be moving.
15:19:11 <mlavalle> Just to let you know that I followed up in our conversation of last week's meeting
15:19:19 <carl_baldwin> mlavalle: ++
15:19:58 <mlavalle> and now we can process port events for ports with multiple fixed ips as far as the integration with NOva generic resoure pools
15:20:31 <mlavalle> The only missing piss is the association of aggregates with resource providers
15:20:38 <mlavalle> that hasn't merged in Nova
15:20:48 <mlavalle> But that hasn't stopped our progress
15:20:56 <mlavalle> I am 'mocking' it in the code
15:21:06 <carl_baldwin> mlavalle: excellent!
15:21:11 <mlavalle> so next step is to add unit tests
15:21:28 <mlavalle> I will do that this week and keep and I on the missing Nova bit
15:21:35 <mlavalle> that's all I have today
15:22:15 <carl_baldwin> mlavalle: Thanks for the report.
15:22:27 <carl_baldwin> Anything else?
15:22:31 <carl_baldwin> ... from anyone?
15:22:35 <mlavalle> Not from me
15:23:18 <carl_baldwin> ok
15:23:22 <carl_baldwin> going once...
15:26:07 <carl_baldwin> going twice...
15:26:25 <carl_baldwin> #endmeeting