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