18:01:41 <adam_g> #startmeeting astara
18:01:42 <openstack> Meeting started Mon Jan 18 18:01:41 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:45 <openstack> The meeting name has been set to 'astara'
18:01:49 <adam_g> o/
18:02:17 <adam_g> most of the US team is out today for a holiday, but thought i'd call the meeting anyway to see if anyone else had something to address
18:02:46 <leonstack> e...few people~
18:03:18 <elo> here
18:03:23 <adam_g> hiya leonstack
18:04:04 <leonstack> mmm...how about a bp of mime #links https://blueprints.launchpad.net/astara/+spec/schedule-instances
18:05:04 <adam_g> #topic mitaka development
18:05:13 <adam_g> #linkhttps://blueprints.launchpad.net/astara/+spec/schedule-instances
18:05:16 <adam_g> derp
18:05:17 <adam_g> #link https://blueprints.launchpad.net/astara/+spec/schedule-instances
18:05:48 <leonstack> I'm not sure application-ha has already done that
18:05:52 <adam_g> leonstack, so  this blueprint targets changing th behavior of the pez instance provider to use more intelligent scheduling?
18:06:29 <leonstack> mmm..nor only pe
18:06:32 <leonstack> pez
18:06:35 <leonstack> sorry
18:06:53 <leonstack> also daemon provider
18:07:19 <leonstack> just for high available
18:07:40 <adam_g> dah
18:07:50 <leonstack> if a computer node is down, it can make sure the network function can work well
18:08:06 <adam_g> the HA work will eventually use anti_affinity for the HA pairs themselves
18:08:25 <adam_g> that is, using hte on demand instance provider the pairs will be booted with those parameters
18:08:49 <adam_g> for pre-provisioned nodes, we'd want them to be scheduled that way first, so yeah--i think it'd be a good addition there, too
18:10:46 <leonstack> OK...thanks~
18:11:05 <adam_g> so im trying to keep this brief, dont want to spend too much going over work that people not present are working on.
18:11:18 <adam_g> anyone else have any other mitaka BPs they'd like to call attention to?
18:12:48 <adam_g> #topic bugs
18:13:28 <elo> a couple of bugs created this weekend
18:13:47 <adam_g> so it looks like we're making good + quick progress on bugs as they get filed, but we're lagging on actually landing the patches. any help with review backlog would be appreciated
18:13:57 <elo> related to hardcode IP address
18:14:10 <adam_g> elo, right i briefly saw that
18:14:33 <adam_g> unfortunately liberty and prior make all kinds of assumptions and use hard-coded addresses and networks all over the place
18:14:55 <adam_g> we've started to fix a lot of that in M and will require back porting to liberty as we get those fixes landed
18:15:15 <adam_g> #action adam_g to get all M2 bugs targeted
18:15:56 <elo> ok. cool. this would help out a couple of deployments
18:16:22 <adam_g> anyone else have anything critical they've hit in the last week that they want to bring up?
18:17:32 <elo> not at the moment
18:17:43 <leonstack> me too
18:17:46 <adam_g> #topic open discussion
18:18:44 <leonstack> how about the application-ha going for now ?
18:18:59 <adam_g> leonstack, its going, a bit slow because of everything else going on
18:19:10 <adam_g> but ive started to refactor the instance_manager to account for multiple instances, which is the first start
18:19:46 <leonstack> thanks ,I got it :)
18:19:51 <adam_g> one thing i forgot to bring up earlier in the meeting is that this week is the mitaka-2 milestone. any help getting patches reviewed and landed would be greatly appreciated
18:20:59 <adam_g> leonstack, my plan is to have a first set of patches that make the instance manager capabale of multiple instances, and have the default essentially be a cluster of 1. then work on the neutron side to allow creation of HA things with no l3 agents running, then work toward getting the VRRP address failover going
18:21:48 <adam_g> theres some assumptions on the neutron side that forces HA routing to require a miniumu of 2 neutron L3 agents running.. in our case we run 0, so we need to get creative on the astara-neutron side
18:22:21 <adam_g> anything else from anyone?
18:23:54 <adam_g> ok well ill call it there. thanks everyone
18:23:59 <adam_g> #endmeeting