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