18:00:22 #startmeeting astara 18:00:23 Meeting started Mon May 23 18:00:22 2016 UTC and is due to finish in 60 minutes. The chair is ryanpetrello. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:25 o/ 18:00:27 The meeting name has been set to 'astara' 18:00:32 o/ markmcclain 18:00:38 adam_g rods eric_lopez 18:01:03 o/ 18:01:33 o/ 18:05:55 so what's up this week? 18:06:02 adam_g fixed the oslo messaging thing :) 18:06:06 thanks for digging into that 18:06:15 sorry - little late 18:06:59 https://review.openstack.org/#/c/319443/ 18:07:11 adam_g, does this affect older versions of astara? 18:07:16 i.e., will we need to backport anything? 18:07:22 ryanpetrello: it shouldn't, one sec let me check global-requirements 18:08:21 https://review.openstack.org/#/c/317696/ got backported to kilo and liberty, which fixes an issue we saw last week 18:08:39 upper constraings has 4.6.1 which should be ok 18:08:45 yea 18:08:51 so 18:08:53 it should be fine in the gate 18:09:14 we still have this easy one hanging around 18:09:16 #link : https://review.openstack.org/#/c/304927/ 18:09:16 but the actually requirements.txt has uncapped oslo.messaging, so anyone installing from stable branches without using constraints will have issues 18:09:33 yeah... wonder if we should propose cap? 18:09:36 we could backport the messaging fix, i dont think we'll be able to cap them 18:10:04 except we can't backport because of dep on oslo.service 18:10:46 hmmm 18:11:05 markmcclain: you mean b/c we introduce a new requirement? 18:11:14 adam_g: yeah 18:11:51 ugh 18:12:47 one option would be to come up with a modified backport 18:12:51 that doesn't use oslo.service 18:13:08 or, block the master patch and modify it to drop the oslo.service usage 18:13:11 yeah I think that might be doable 18:13:19 backport that, then update master to use oslo.service (if we wanted it) 18:13:50 I was also going to stand up an isolated env and make sure oslo.service is not installed by our current dependency set 18:14:26 one sec 18:14:30 i can do that right quick 18:14:32 ok.. so we might be in luck 18:14:45 the current stable/mitaka installs oslo.service 18:14:54 ryanpetrello: what do you think about putting the brakes on merging 319443 ? 18:15:08 wfm if we want to push pause 18:15:24 so we might be able to backport the change by first fixing the error in the undeclared dep in stable 18:15:30 and then backporting the actual change 18:15:53 that would keep the history of why we did things clear.. thtoughts? 18:15:55 markmcclain: what do you mean, fixing undeclared dep? 18:16:48 When installing stable/mitaka in fresh env here's the current packages 18:16:51 #link http://paste.openstack.org/show/498240/ 18:17:16 we're implicitly relying on it (guessing a drive-by dep on some other oslo lib) 18:17:34 so we could explicitly declare it as a requirement for stable and then backport the fix 18:17:52 it wouldn't break anyone because it's already being installed 18:18:00 yea 18:18:19 WFM 18:18:31 ill add +W back to the original fix then 18:18:46 * ryanpetrello thumbs up 18:19:05 is this an issue pre-mitaka 18:19:21 ryanpetrello: only when using oslo.messaging >5.x 18:19:48 k 18:19:52 ryanpetrello: mitaka + liberty's requirements dont declare an upper version constraint on oslo.messaging, so pip installing it currently would get you the newer 5.x oslo.msg that would break you 18:20:02 right 18:20:23 BUT the upper-constraints.txt pins it to 4.x in stable/mitaka, so it gives us the illusion everything is working 18:20:29 ... in the gate 18:20:32 *sigh* 18:21:32 so after that messaging fix is landed, https://review.openstack.org/#/c/317744/ should fix the appliance image builds in the -src jobs 18:21:37 and our gate should be happy across the board 18:21:51 ill keep an eye and recheck that once the other merges 18:21:55 * ryanpetrello dance 18:22:02 awesome 18:22:06 thanks for this, adam_g :D 18:22:55 no prob 18:24:01 any other updates from anybody? 18:24:55 not much from me, those breakages occupied most of my time last week 18:25:17 just to random fixups I mentioned earlier 18:25:46 mestery put up https://review.openstack.org/#/c/319447/ which adds a vagrant config to spinup astara devstack. i dont use vagrant so if someone who does wants to look it over, that'd be cool 18:26:06 I was working through it earlier this morning 18:27:06 thinking we might want to tweak a bit of the readme since virtualbox virt-in-virt is painfully slow since it's all emulated 18:27:43 coool. im too married to my homegrown kvm + qcow2 snapshots + nfs mounted /opt/stack to kick tires on vagrant 18:27:54 heh 18:28:32 okay, sounds like we're done 18:28:37 o/ 18:28:43 I have been asked to present Astara to the OpenStack Ansible folks this Thursday 18:28:50 phil_h: cool 18:29:10 They have been looking at using Octavia 18:29:12 phil_h: oh cool. to give an overview of it, or present ansible integration? 18:29:26 I have been pushing Astara to the Rackspack folks 18:29:46 I need to get some more info in the morning 18:30:16 I'll let Eric know and he can pass it on to anyone else that is interested 18:30:19 neat 18:30:20 thanks 18:30:39 phil_h: lets talk I've been playing with OSAD to figure out the architecture 18:31:19 If we can get them into astara using loadbalancers then we can push them all the way into astara in hte furture 18:32:59 Yes, lets talk later today 18:33:18 call me or send me a message 18:33:29 #endmeeting