18:01:05 <adam_g> #startmeeting astara 18:01:06 <openstack> Meeting started Mon Jan 11 18:01:05 2016 UTC and is due to finish in 60 minutes. The chair is adam_g. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:09 <openstack> The meeting name has been set to 'astara' 18:01:13 <adam_g> o/ 18:02:06 <adam_g> markmcclain ryanpetrello rods 18:02:08 <markmcclain> o/ 18:02:29 <rods> o/ 18:02:45 <adam_g> hey guys 18:02:57 <adam_g> #topic mitaka development 18:02:58 <leonstack> hello everyone, I'm a new guy for astara :) 18:03:06 <adam_g> leonstack, welcome :) 18:03:14 <leonstack> thx~ 18:03:14 <rods> leonstack welcome :) 18:03:48 <markmcclain> welcome 18:04:12 <adam_g> so for mitaka, ive been sniffing around the internals of the instance manager and our nova code, looking at ways to implement https://blueprints.launchpad.net/astara/+spec/appliance-ha 18:04:27 <adam_g> haven't made too much progress there but hope to continue that this week and get some POC or spec up 18:04:44 <markmcclain> cool 18:05:28 <adam_g> markmcclain, where are you at with the BYONF stuff? i'd like to get either some POC code up on gerrit or some thoughts captured in an etherpad or spec somewhere describing it a bit. i actually got pinged by someone from networking-sfc about it over the weekend, would be great to point them somewhere 18:06:46 <adam_g> also, i went through and prioritized blueprints based on where we are in the dev cycle and how much time we've got left. i think appliance-ha, neutron-vpnaas and astara-sfc are the main feature areas we should be committing to for M. 18:07:10 <adam_g> would have liked for that list to be longer but a good deal of our cycles till now has been spent on renaming and stabilizing bugs 18:07:16 <markmcclain> ok.. I can capture the work in a spec 18:07:22 <ericlopez> these would be three nice features to have 18:07:35 <markmcclain> yeah I think that list makes sense 18:08:03 <adam_g> leonstack, FYI https://blueprints.launchpad.net/astara/mitaka is our blueprints for M, please see if theres seomthing that interests you and dont hesitate to ping us for help getting started 18:08:23 <adam_g> #link https://blueprints.launchpad.net/astara/mitaka 18:08:41 <leonstack> Oh, I know that site, and I have created one bp~ 18:08:46 <adam_g> #action markmcclain to capture BYONF work in a spec (astara-sfc) 18:08:53 <adam_g> leonstack, oh? which one? 18:09:04 <leonstack> let me see.. 18:09:43 <leonstack> it's about service instance template 18:09:48 <leonstack> https://blueprints.launchpad.net/astara/+spec/template-module 18:10:06 <leonstack> I'm not sure is that make any sense ? 18:10:43 <markmcclain> leonstack: this might be an opportunity to leverage a bit of the flavor framework 18:11:18 <adam_g> leonstack, makes sense, ya 18:11:37 <adam_g> markmcclain, this actually sounds similar to the BYONF workflow you've come up with 18:11:51 <markmcclain> adam_g: yeah that too 18:11:55 <markmcclain> there are few differences 18:12:01 <markmcclain> especially around mgt network 18:12:07 <leonstack> oh really, I did'nt know it ,sorry ~ 18:12:35 <markmcclain> leonstack: I need to better doc the thoughts on bring your own network function 18:12:49 <adam_g> long term, i think it makes good sense to centralize the configuration of the images/flavor/mgt_net for a resource to eliminate config drift among clustered orchestrators 18:13:27 <markmcclain> right 18:13:27 <adam_g> ie, stop using config files entirely for that.. 18:13:54 <adam_g> so yeah, leonstack i think we should discuss this further after meeting and see what we can agree on 18:13:57 <leonstack> OK, I have did a similar thing last year, I will write another doc for it :) 18:14:21 <leonstack> OK, I agree, thx :) 18:14:35 <adam_g> leonstack, thanks for raising the BP 18:15:04 <leonstack> my pleasure~ 18:15:41 <adam_g> #topic bugs 18:16:21 <adam_g> so we triaged a couple of bigger bugs last week 18:16:30 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1531274 18:16:32 <openstack> Launchpad bug 1531274 in Astara "unable to delete tenant networks" [Critical,Confirmed] - Assigned to Rosario Di Somma (mr-rods) 18:16:54 <adam_g> rods, you're assigned to this one, any updates? 18:17:44 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1531967 18:17:45 <openstack> Launchpad bug 1531967 in Astara "ingress DHCP traffic to instances blocked without tenant secgroup rule" [Critical,New] - Assigned to Mark McClain (markmcclain) 18:17:57 <rods> adam_g not yet, what I'm seeing in dev env is that vrrp ports are never removed 18:18:01 <adam_g> markmcclain, i know you had a fix in mind for this on the astara-neutron side--any updates there? 18:18:16 <markmcclain> I'm picking that one back up after fixing teh extension problem 18:19:01 <rods> markmcclain I'm going to ping you later to ask you a couple of questions 18:19:02 <ericlopez> do we need to get a neutron plugin CI so we aren't bitten by another neutron change 18:19:30 <markmcclain> might make sense to setup a periodic job that runs daily 18:20:34 <adam_g> hm 18:21:18 <adam_g> i think we produce enough patch traffic on our own, and are responsive enough to fixing small breaks like this 18:21:55 <adam_g> im not sure it'd be worth the effort of maintaining/babysitting our CI jobs in another projects pipeline 18:22:42 <adam_g> thats just my $.02 tho 18:23:27 <adam_g> rods, so it sounds like you'll be working on a fix for 1531274 or should i unassign you for now? 18:23:51 <markmcclain> adam_g: yeah.. was thinking we could just run the periodic jobs on our side 18:24:52 <adam_g> markmcclain, we could, but i dont think it'd buy us much--its not like we are letting things bitrot.. we push patches daily and have a good record of detecting the breakages as soon as they happen 18:25:01 <adam_g> periodics would be good for our stable branches tho 18:25:17 <markmcclain> yeah I think for stable makes lots of sense 18:25:29 <markmcclain> and if we 18:25:45 <markmcclain> 're generating enough activity on master that we're catching most things 18:26:40 <adam_g> ya, thats what i mean.. at least now--we're in the sweet spot of being active enough, with a small enough code base and a small, responsive team 18:26:58 <ericlopez> ok. makes sense 18:27:33 <adam_g> ok moving on... 18:27:48 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1527396 18:27:49 <openstack> Launchpad bug 1527396 in Astara "state machines get lost after failovers" [High,In progress] - Assigned to Adam Gandelman (gandelman-a) 18:28:01 <adam_g> that ones a gnarly one but the fix is pretty simple, theres a patch up for it 18:28:16 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1531597 18:28:17 <adam_g> ditto on that 18:28:18 <openstack> Launchpad bug 1531597 in Astara "after a tenant has deleted a resource, subsequent calls on new resources are droppe" [High,In progress] 18:29:42 <adam_g> #link https://bugs.launchpad.net/astara/+bug/1524068 18:29:43 <openstack> Launchpad bug 1524068 in Astara "get_local_service_ip conflicts across multiple astara nodes" [Critical,In progress] 18:29:59 <adam_g> this still has some patches that need to be merged, they've been sitting a while but should be in good shape 18:30:13 <adam_g> any other bugs anyone wants to bring up? 18:30:35 <adam_g> we've got a flood of smaller, low hanging bugs and patches over the last couple weeks (thanks for those, if the authors are reading) 18:30:40 <markmcclain> I'm also working on the external connectivity problem with devstack 18:30:51 * markmcclain needs to file bug for it 18:31:08 <adam_g> k 18:31:13 <markmcclain> yeah super cool to see the new contributors 18:31:47 <rods> adam_g yep, I'm working on it 18:31:57 <adam_g> rods, cool, thanks 18:32:16 <ericlopez> same here 18:32:37 <ericlopez> ss 18:33:23 <adam_g> #link https://launchpad.net/bugs/1531651 18:33:24 <openstack> Launchpad bug 1531651 in Astara "router interface plugging fails in the appliance" [Undecided,In progress] 18:33:33 <adam_g> oh, theres another bad one with a fix ready to merge 18:33:42 <adam_g> *ready to review :) 18:34:19 <ericlopez> after looking at the neutron extension issue last night… the extension is called dhrouterstatus… should this be renamed? 18:35:13 <markmcclain> yeah.. I'll work up a fix for it 18:35:22 <adam_g> ericlopez, it could but we'd have to do that over a long period of time, to ensure we dont break the API for older verisons of the orchestrator, which would still be requesting /dhrouterstatus 18:35:24 <ericlopez> and the namespace URL doesn't exist 18:35:42 <markmcclain> I was planning to make both supported for the interim 18:35:48 <adam_g> ah cool 18:35:53 <adam_g> lets move this to... 18:35:57 <adam_g> #topic open discussion 18:36:23 <adam_g> #action markmcclain to begin migration away from /dhrouterstatus API extension 18:36:33 <adam_g> markmcclain, question about https://review.openstack.org/#/c/246005/12 18:36:59 <markmcclain> adam_g: sure.. what's up? 18:37:10 <adam_g> markmcclain, is it possible to publsih non-public facing endpoints in keystone? i dotn remember 18:37:23 <adam_g> in other words, a service with only a service/admin endpoint? 18:37:43 <markmcclain> you can have different internal, public urls 18:37:55 <ericlopez> yes. 18:38:06 <markmcclain> but not sure if can restrict the visibility based on tenant 18:38:56 <adam_g> ok 18:38:58 <leonstack> I have one question....the application-ha is based on vrrp(active/backup)? or ecmp(A/A) 18:38:59 <adam_g> ill poke at it 18:39:04 <markmcclain> ok 18:39:53 <adam_g> leonstack, the plan is for VRRP pairs. we already create the ports on the neutron side, we just need to adjust the orchestrator to spawn and manage pairs of nova instances for those ports 18:40:23 <leonstack> oh, thanks~ 18:41:14 <adam_g> anyone have anything else? 18:41:34 <leonstack> I have did NFV work with neutron for one year...and... 18:41:49 <leonstack> our vpn is ipsec vpn? 18:42:44 <adam_g> leonstack, yeah, the initial plan is to make the first astara VPN support based on ipsec (strongswan in the appliance) 18:42:48 <adam_g> markmcclain, correct me if i'm wrong there 18:43:10 <leonstack> can we use some other company's image with different API...? 18:43:34 <adam_g> leonstack different API on the backend/appliance side? 18:43:38 <markmcclain> adam_g: correct 18:43:59 <leonstack> oh,both perhaps.. 18:44:28 <leonstack> I was confused by that actually .. 18:44:59 <adam_g> leonstack, we've tried to architect the orchestrator to support that via its appliance driver model. for now we support only the astara appliance, but it'd be easy enough to push VPN/router/LB config into a non-astara appliance provided it exposes some API to dot hat 18:45:22 <adam_g> also markmcclain BYNOF work makes it a bit easier to add support for arbitrary appliances 18:45:47 <leonstack> thanks for your patient explanation :) I got it 18:45:57 <adam_g> cool! 18:46:05 <adam_g> anythin else ? 18:46:55 <markmcclain> nothing from me 18:47:20 <ericlopez> nothing from me… 18:47:59 <ericlopez> I'm reviewing autogen orchestrator.ini patch 18:48:13 <adam_g> cool 18:48:18 <adam_g> ok talk to you all in #openstack-astara 18:48:22 <adam_g> #endmeeting