18:01:07 <adam_g> #startmeeting astara
18:01:08 <openstack> Meeting started Mon Dec 21 18:01:07 2015 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:11 <openstack> The meeting name has been set to 'astara'
18:01:13 <adam_g> o/
18:01:14 <markmcclain> o/
18:02:59 <elo> hola
18:03:27 <adam_g> #topic Bugs
18:04:05 <adam_g> https://launchpad.net/bugs/1524962
18:04:05 <openstack> Launchpad bug 1524962 in Astara "transient gate failure trying to update astara-appliance config " [Undecided,In progress]
18:04:31 <adam_g> so our gate test seems to be getting more unreliable. ive got a patch up to try to help track one of them but im not sure theres only one bug.
18:04:58 <adam_g> im hoping to spend some cycles digging into that thsi week and see if i can really get to the bottom of it. seems we have to recheck more than not these days
18:05:39 <markmcclain> wondering if we need to track the underlying cloud since it seems to be a timing issue
18:05:47 <adam_g> #action adam_g to dig deeper into transient gate failures
18:05:58 <adam_g> markmcclain, yea, that was one of hte things i was going to look at (RAX vs HP vs etc)
18:06:21 <markmcclain> there's also the new cloud that might ahve introduced enough jitter into the system
18:06:21 <adam_g> id like to also add some logging into the appliance somewhere so we have some visibility into whats gumming up the config update
18:06:57 <adam_g> https://bugs.launchpad.net/astara/+bug/1524068
18:06:57 <openstack> Launchpad bug 1524068 in Astara "get_local_service_ip conflicts across multiple astara nodes" [Critical,In progress]
18:07:16 <adam_g> started tackling this last week and ran into another bug in our clustering layer: https://bugs.launchpad.net/astara/+bug/1527396
18:07:16 <openstack> Launchpad bug 1527396 in Astara "state machines get lost after failovers" [High,In progress] - Assigned to Adam Gandelman (gandelman-a)
18:07:36 <adam_g> https://review.openstack.org/259216 begins to address that, hope to get it finished up today
18:07:44 <elo> I'll need to understand the update resource so this helpful for debugging
18:08:40 <markmcclain> cool
18:09:17 <adam_g> elo, you filed a few small bugs lsat week; https://bugs.launchpad.net/astara/+bug/1524584 https://bugs.launchpad.net/astara/+bug/1524592 and https://bugs.launchpad.net/astara/+bug/1524596   you have any interest in driving any of those /w patch?
18:09:17 <openstack> Launchpad bug 1524584 in Astara "'astara-ctl browse' command broken" [Undecided,New] - Assigned to j_king (james-agentultra)
18:09:18 <openstack> Launchpad bug 1524592 in Astara "'astara-ctl ssh' command broken" [Undecided,New]
18:09:19 <openstack> Launchpad bug 1524596 in Astara "devstack hardcode location of astara appliance public key" [Undecided,New]
18:10:29 <elo> sure I can easily do the 152496... will look at the other two
18:11:10 <adam_g> cool ill assign that one
18:12:35 <adam_g> #topic mitaka development
18:13:15 <adam_g> markmcclain, i was thinking, maybe the BYONF work can be rolled into https://blueprints.launchpad.net/astara/+spec/astara-sfc as a building block?
18:13:43 <markmcclain> yeah that seems like natural fit
18:14:10 <adam_g> cool
18:14:43 <adam_g> im thinking of pickig something off the blueprint queue to start working on before the holiday. might take a crack at the appliance HA/VRRP stuff we've been discusisng forever
18:15:06 <adam_g> at least expanding our state machine management to allow managing multiple SMs per neutron resource
18:15:27 <markmcclain> yeah... if that feature is added
18:15:47 <markmcclain> the instance stuff shouldn't be too hard to setup
18:15:48 <adam_g> markmcclain, the BP is assigned to you. did you have any WIP stuff stashed somewhere or still just in your head?
18:16:08 <markmcclain> it's in my head
18:16:21 <adam_g> k
18:17:38 <adam_g> #topic open discussion
18:18:00 <adam_g> anything to discuss? figure it's going to be a short week with the holiday
18:18:02 <markmcclain> so I've also been kicking around vpnaas impl too
18:18:14 <markmcclain> I think it might not be too terrible
18:18:31 <markmcclain> otherwise also trying to track down another interesting issue
18:18:43 <adam_g> cool
18:18:45 <adam_g> whats the issue?
18:18:57 <markmcclain> where the state machine can get stuck thinking a machine is still booting
18:19:02 <markmcclain> when it is ready for config
18:19:26 <markmcclain> I haven't filed the bug because I've got to isolate where this happens
18:20:35 <adam_g> hmm not seen that one before
18:20:40 <elo> could this be similar to the issue Phil is hitting?
18:21:32 <elo> appliance gets booted, but somehow config drive isn't configuring the interfaces
18:21:40 <markmcclain> adam_g: yeah it's occurs when you have really long boot times
18:22:02 <markmcclain> elo: so this is different because the appliance does come up
18:22:07 <markmcclain> and the bootcmd is run
18:22:21 <markmcclain> but the orchestrator has problems talking to the instance
18:22:28 <elo> ok
18:23:41 <adam_g> might be able to reproduce /w some strategically placed sleeps on the nova side
18:24:30 <adam_g> elo, hoping to get some appliance logging going soon for the gate issue, which should help in your situation
18:24:31 <markmcclain> yeah... that was my plan
18:25:36 <adam_g> cool. anything else?
18:25:39 <markmcclain> yeah I think dumping a bit more state to teh console would help
18:25:41 <elo> thanks. I informed phil about getting on the console for the appliance. Not heard from him back yet. I've not been able to replicated it
18:28:18 <adam_g> ok. well unless anyone has anything else we can get back to it
18:29:03 <markmcclain> nothing else from me
18:29:38 <adam_g> ok o/
18:29:40 <adam_g> #endmeeting