18:01:41 #startmeeting astara 18:01:42 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:45 The meeting name has been set to 'astara' 18:01:49 o/ 18:02:17 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 e...few people~ 18:03:18 here 18:03:23 hiya leonstack 18:04:04 mmm...how about a bp of mime #links https://blueprints.launchpad.net/astara/+spec/schedule-instances 18:05:04 #topic mitaka development 18:05:13 #linkhttps://blueprints.launchpad.net/astara/+spec/schedule-instances 18:05:16 derp 18:05:17 #link https://blueprints.launchpad.net/astara/+spec/schedule-instances 18:05:48 I'm not sure application-ha has already done that 18:05:52 leonstack, so this blueprint targets changing th behavior of the pez instance provider to use more intelligent scheduling? 18:06:29 mmm..nor only pe 18:06:32 pez 18:06:35 sorry 18:06:53 also daemon provider 18:07:19 just for high available 18:07:40 dah 18:07:50 if a computer node is down, it can make sure the network function can work well 18:08:06 the HA work will eventually use anti_affinity for the HA pairs themselves 18:08:25 that is, using hte on demand instance provider the pairs will be booted with those parameters 18:08:49 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 OK...thanks~ 18:11:05 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 anyone else have any other mitaka BPs they'd like to call attention to? 18:12:48 #topic bugs 18:13:28 a couple of bugs created this weekend 18:13:47 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 related to hardcode IP address 18:14:10 elo, right i briefly saw that 18:14:33 unfortunately liberty and prior make all kinds of assumptions and use hard-coded addresses and networks all over the place 18:14:55 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 #action adam_g to get all M2 bugs targeted 18:15:56 ok. cool. this would help out a couple of deployments 18:16:22 anyone else have anything critical they've hit in the last week that they want to bring up? 18:17:32 not at the moment 18:17:43 me too 18:17:46 #topic open discussion 18:18:44 how about the application-ha going for now ? 18:18:59 leonstack, its going, a bit slow because of everything else going on 18:19:10 but ive started to refactor the instance_manager to account for multiple instances, which is the first start 18:19:46 thanks ,I got it :) 18:19:51 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 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 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 anything else from anyone? 18:23:54 ok well ill call it there. thanks everyone 18:23:59 #endmeeting