16:00:38 <odyssey4me> #startmeeting OpenStack-Ansible
16:00:39 <openstack> Meeting started Thu Jun 30 16:00:38 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:43 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:49 <GB21> Thanks all
16:00:56 <odyssey4me> #topic Agenda & rollcall
16:01:22 <michaelgugino> here
16:01:32 <spotz> \o/ welcome back odyssey4me
16:01:33 <admin0> \o/
16:01:35 <evrardjp> o?
16:02:14 <palendae> o7
16:02:16 <Zucan> o/
16:02:31 <mrhillsman> 0/
16:02:36 <andymccr> o/
16:02:45 <adreznec> o/
16:04:06 <asettle> o/
16:04:13 <jmccrory> o/
16:04:22 * odyssey4me just finished reading the log from last week's meeting :p
16:04:42 <evrardjp> mhayden did fast and well IIRC
16:04:42 <asettle> I'm sure that was just a rollercoaster read.
16:05:30 <odyssey4me> alrighty, let's rumble :)
16:05:38 <odyssey4me> #topic Review action items from last week
16:05:53 <odyssey4me> #topic MariaDB 10.1 Upgrade for Newton
16:06:00 * odyssey4me hands the mic to adreznec
16:06:34 <prometheanfire> o/
16:06:39 * mhayden stumbles in
16:06:56 <adreznec> Hey odyssey4me. Not a ton to report yet, I have an environment set up locally but didn't have quite as much time to look at it as I was hoping for
16:06:56 <odyssey4me> lol, welcome mhayden - enjoying the show?
16:07:39 <odyssey4me> adreznec ok, not a major issue - although it seems that it may be a blocker for the PPC support :/
16:07:42 <adreznec> Haven't run into any issues yet, but I'm going to dig farther in today/tomorrow here and push up some initial test changes
16:07:53 <cloudnull> o/
16:08:05 <adreznec> Yeah, we hit a few other PPC issues I'm work ahead of that
16:08:09 <adreznec> *working
16:08:18 <alextricity25> o/
16:08:21 <alextricity25> better late than never
16:08:25 <odyssey4me> We have discussed whether we should do the 10.1 upgrade for Newton. I think it was at the summit. Everyone was open to it, but no-one volunteered to pick it up as I recall.
16:08:30 <odyssey4me> It wasn't urgent for anyone.
16:08:49 <adreznec> Yeah, I saw that on the multi-os etherpad
16:08:54 <automagically> o/
16:09:16 * automagically mostly here, but troubleshooting OVS simultaneously
16:09:18 <alextricity25> i thought it was needed for the 16.04 work?
16:09:38 <odyssey4me> adreznec We did a MariaDB 5.5 -> 10.0 upgrade process from Kilo->Liberty so there is some prior art around. As I recall the Mitaka branch may still have an in-role test set which you can use for the patch submission.
16:09:50 <palendae> Yeah, it does
16:10:03 <adreznec> alextricity25: I thought for x86 10.0 is still available in the mirrors for Xenial
16:10:16 <adreznec> odyssey4me: Ok, I'll take a peek at that
16:10:21 <odyssey4me> I hope it removes some moving parts, actually, due to the built-in galera bits.
16:10:43 <alextricity25> adreznec: You're probably right. I'm just going off something I read off some etherpad a few days ago
16:10:45 <odyssey4me> But of course that means we'll need a patch added to the Mitaka->Newton upgrade process to ensure that things are cleaned up.
16:12:28 <odyssey4me> I would personally prefer to ditch the extra moving parts and use the packages in Xenial as far as possible, but I think there may be an issue with xtrabackup there.... not sure.
16:13:08 * odyssey4me had a nightmare about all the moving parts in an OpenStack install.
16:13:13 <adreznec> odyssey4me: Yeah, I'll have to test that out
16:13:26 * alextricity25 hugs odyssey4me
16:13:28 <odyssey4me> OK - any other thoughts before we move on?
16:13:30 <alextricity25> it'll be alright
16:13:47 <asettle> This got emotional quick
16:13:54 <michaelgugino> 10.1 is not so much the problem, it's the missing xtra backup components
16:13:59 * odyssey4me eyes mhayden - it's all your fault isn't it?
16:14:08 <cloader8_> lol
16:14:12 <alextricity25> i think we should all talk about our feelings
16:14:22 <asettle> alextricity25: omg okay, you first
16:14:28 <odyssey4me> Considering we all work in OpenStack, I think that's a bad idea.
16:14:28 <evrardjp> w/c ?
16:14:38 <michaelgugino> Xenial repos only provide 10.0 as well, there was no package update, debian is still shipping 10.0, so we need to bug the debian maintainers if we want to ship 10.1 in Ubuntu's repos
16:14:38 <asettle> evrardjp: to me that stands for Water Closet.
16:14:40 <alextricity25> sorry...didn't mean to deviate
16:14:45 <asettle> alextricity25: oh yes you di
16:14:46 <asettle> did*
16:15:06 <evrardjp> what's UCA shipping ?
16:15:11 <odyssey4me> michaelgugino I was thinking that we stick to 10.0 but we switch from the MariaDB packages to the Xenial packages.
16:15:33 <michaelgugino> The problem is we need the galera patches which are source patches
16:15:38 <odyssey4me> michaelgugino As far as I can tell that should cater for PPC and remove some moving parts.
16:15:48 <odyssey4me> Ah, then that died in a fire.
16:15:59 <michaelgugino> no way to use galera+mariadb10 without the source patches
16:16:08 <adreznec> Ah, well there goes that idea
16:16:11 <palendae> Was 10.1 where they combined them?
16:16:15 <michaelgugino> yes
16:16:31 <odyssey4me> OK, so that pipedream will have to wait for another Ubuntu release.
16:16:48 <odyssey4me> Right - moving on.
16:16:56 <odyssey4me> #topic Mid Cycle Planning
16:17:01 <eil397> we already have build for python packages. let's build deb : - ) - just a joke
16:17:15 <michaelgugino> looks like xtrabackup is finally out natively for 16.04, so we might be able to ship 10.1+ from mariadb if we chose.
16:17:20 <odyssey4me> Thanks mhayden for organising stuff so far. We need to start building an agenda.
16:17:33 <michaelgugino> but that would be a breaking upgrade that we need coverage for during m->n
16:18:23 <odyssey4me> michaelgugino M->N with N on Xenial requires new hosts & new containers... so upgrades are not much of an issue
16:18:49 <odyssey4me> let's pick pu that convo a bit later though - we have plenty to work through before then
16:19:01 <michaelgugino> true, but I'm of the preference of keeping as much the same between trusty and xenial as possible, but I'm okay with making that change personally.
16:19:16 <asettle> odyssey4me: just a note on the agenda, I'd like to have a docs working session to help improved teh install guide at hte midcycle
16:19:17 <asettle> plz
16:19:20 <odyssey4me> I think it's time we start forming an agenda on the mid cycle etherpad
16:19:21 <asettle> I'll give you another cookie
16:19:23 <odyssey4me> #link https://etherpad.openstack.org/p/osa-midcycle-newton
16:19:28 <asettle> \o/ yas
16:21:34 <odyssey4me> ok, I've added a bit of a framework
16:23:23 <asettle> Excuse me, odyssey4me and I are having an etherpad argument
16:27:14 <prometheanfire> lol
16:27:42 <odyssey4me> for those proposing long sessions, best you plan body breaks ;)
16:27:48 <palendae> Yeah
16:28:08 <odyssey4me> ok cool - while that continues let's move on a bit
16:28:55 <odyssey4me> adreznec Feel free to propose a session to help the power work get ahead. Once we have all proposals up we'll have to check how much time we have and prioritise.
16:29:31 <adreznec> odyssey4me: Sounds good, I'll get that up there.
16:29:32 <odyssey4me> next up
16:29:43 <odyssey4me> #topic Backport of OVS work to stable/mitaka
16:29:48 * odyssey4me hands the mic to automagically
16:30:07 <automagically> I just wanted to see if anyone would have objections to getting this work backported
16:30:26 <automagically> Also, wondering if anyone has ideas on how we might get gate testing around it in either os_neutron or the AIO
16:30:52 <automagically> Seems to be a fair bit of demand for the feature, but I’m not networking wizard and could use some help/validation from the community
16:30:58 <odyssey4me> automagically ok yeah, I'm lagging on sorting out the gating bit - I have committed to doing it and it is getting rather urgent
16:31:14 <andymccr> scenario gating!
16:31:25 <evrardjp> woot
16:31:29 <automagically> I guess what I should do is add it to the mid-cycle planning as a topic. The gating work
16:31:32 <odyssey4me> in terms of backporting - if the changes are fairly contained and opt-in, I suppose it's not too much of an issue
16:31:40 <automagically> Its definitely opt-in
16:31:56 <michaelgugino> there was a fair amount of refactoring of variable names and whatnot for the ovs work
16:31:57 <odyssey4me> it's hard to tell without looking at the full body of change
16:32:27 <automagically> This is pretty much it: https://github.com/openstack/openstack-ansible-os_neutron/compare/stable/mitaka...trumant:stable/mitaka
16:32:40 <odyssey4me> yeah, it may require some rejigging due to the multi-os work and liberal use of the deprecation filter to ensure that var names that worked before keep working
16:32:43 <stevelle> sounds like with the var changes that there would be upgrade impacts L->M?
16:32:53 <automagically> I’ve been doing testing on it in my lab and hopefully will have results soon
16:33:20 <automagically> okay, will keep in mind the var naming issues before proposing a patch to stable/mitaka
16:34:01 <palendae> yeah, var name changes would definitely affect upgrades
16:34:04 <evrardjp> sorry to be painful on this point, but it's not stable if we change variables
16:34:09 <palendae> ^
16:34:18 <michaelgugino> looks like the ovs changes need to be updated for xenial as well
16:34:21 <palendae> Added is fine
16:34:28 <michaelgugino> there's no UCA for xenial, so those bits will fail
16:34:35 <automagically> Okay, appreciate the feedback I’m getting from all of you
16:34:38 <odyssey4me> yeah, if you ensure that any var name changes are covered by the deprecation filter and that there are release notes indicating deprecation in mitaka and removal in newton, then you should be covered
16:34:44 <automagically> Helps me understand what work would be needed
16:34:53 <odyssey4me> michaelgugino xenial now does have UCA
16:34:58 <michaelgugino> oh, cool
16:35:04 <automagically> I’m happy to cede the floor, unless any of you have additional thoughts
16:35:08 <odyssey4me> michaelgugino after N1 they did Xenial packages
16:35:27 <odyssey4me> FYI too we now have UCA mirrors in OpenStack-Infra: http://mirror.dfw.rax.openstack.org/ubuntu-cloud-archive/dists/
16:35:28 <evrardjp> any work of deprecation should be properly filled with an upgrade path
16:35:34 <palendae> ^
16:35:38 <odyssey4me> so I'm working on a patch to consume that
16:35:42 <evrardjp> so I'll review -1 if I don't have it :p
16:35:51 <evrardjp> because stable
16:35:56 <evrardjp> :D
16:36:58 <odyssey4me> ok, moving along
16:37:00 <evrardjp> ok
16:37:08 <odyssey4me> #topic Release planning and Decisions
16:37:22 <odyssey4me> Are there any blockers for another Liberty/Mitaka release?
16:37:47 <odyssey4me> To finalise Kilo and formally EOL it I need some votes on https://review.openstack.org/336075 please.
16:37:55 <evrardjp> no critical issue that I am aware of for L/M
16:38:08 <odyssey4me> d34dh0r53 andymccr ^
16:38:31 <stevelle> d34dh0r53: out on holiday?
16:38:55 <odyssey4me> ah, I wasn't aware of that - good! :)
16:39:04 <odyssey4me> stevelle if you're happy to vote that's be great
16:39:09 <stevelle> queued
16:39:19 <stevelle> shouldn't take long
16:39:38 <odyssey4me> #action odyssey4me to request Liberty/Mitaka releases and propose subsequent SHA bumps
16:40:03 <odyssey4me> #topic Ubuntu 1604 LTS Support
16:40:16 <odyssey4me> Any comments on the current status, and does anyone have any blockers?
16:40:37 <evrardjp> https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:40:55 <evrardjp> for those who lost the link
16:41:08 <eil397> evrardjp:  thanks
16:41:15 <michaelgugino> someone can +1 the wf on my swift patch
16:42:06 <michaelgugino> then, we just need someone to do horizon, and that's all the major roles
16:42:11 <odyssey4me> michaelgugino link?
16:42:14 <michaelgugino> we still have some bugs regarding the lxc bridge
16:42:21 <stevelle> I got it, upgraded my vote
16:42:39 <michaelgugino> https://review.openstack.org/#/c/334543/
16:42:42 <michaelgugino> :) thanks stevell
16:42:48 <odyssey4me> ah, I see it's done
16:43:11 <odyssey4me> yeah, I need to finalise https://review.openstack.org/330231
16:43:24 <odyssey4me> please review and comment on the existing progress
16:43:46 <evrardjp> starred
16:43:59 <odyssey4me> ok, we're close to time so I'm going to rather open up for discussion for any further updates/questions
16:44:03 <michaelgugino> we need to decide if we are going to continue using our hand-built lxcbr0 bridge for xenial, or if we should use the lxc.net service
16:44:07 <odyssey4me> #topic Open Discussion
16:44:17 <michaelgugino> those two are conflicting, and results in the lxcbr0 not coming up after a reboot
16:44:29 <evrardjp> we should stick closer to standard IMO
16:44:34 <odyssey4me> michaelgugino if xenial has something better, let's use it
16:44:39 <odyssey4me> evrardjp ++
16:44:49 <evrardjp> lxcbr0 is ugly right now
16:45:17 <odyssey4me> we should, where possible, do the things that a system admin would expect in a normal environment
16:45:18 <michaelgugino> I don't know if it's better or not, just wanted to throw it back out there
16:45:19 <evrardjp> that would require a lot of changes in the test playbooks/roles too michaelgugino
16:45:24 <stevelle> who's child are you calling ugly? :)
16:45:41 <odyssey4me> stevelle that would be cloudnull's ugly child ;)
16:45:43 <evrardjp> not calling names stevelle :D
16:45:56 <evrardjp> that's harsh
16:45:57 <michaelgugino> my preferences is to not manually create lxcbr0 if it's being created by a service
16:45:58 <cloudnull> what ?
16:46:08 <evrardjp> michaelgugino: +!
16:46:14 <evrardjp> +1 I meant
16:46:14 <odyssey4me> michaelgugino agreed
16:46:21 <michaelgugino> but, I'm behind on a couple of things and don't have the time to cut a patch right now.  Maybe in a couple weeks.
16:46:34 <logan-> I have questions about https://review.openstack.org/#/c/323504/ .. what's the reason behind having all of these hostnames for each container? Backwards compat? And are they all expected to be resolvable by all hosts and containers?
16:46:40 <odyssey4me> michaelgugino maybe register a big for it?
16:46:43 <odyssey4me> *bug
16:46:50 <cloudnull> michaelgugino: I'd recommend not using the lxc.net service.
16:46:56 <stevelle> we need to develop a migration method if we want to convert
16:46:57 <evrardjp> logan-: that's a good question
16:47:06 <cloudnull> though I do agree lxcbr0 should be cleaned up
16:47:08 <odyssey4me> logan- oh dear, now that's an ugly baby
16:47:08 <evrardjp> back/forward compatibility
16:47:27 <michaelgugino> not using lxc.net I believe should be as simple as dropping an empty service file to mask it
16:47:46 <evrardjp> cloudnull: is there a reason why you'd rather not use lxc.net service?
16:47:59 <michaelgugino> I will defer to cloudnull's judgement as he's the expert in that domain.
16:47:59 <odyssey4me> michaelgugino I think the security role does a service disable or two - there's likely some prior art there to learn from.
16:48:00 <evrardjp> I mean ubuntu should do their job and provide a decent default
16:48:01 <cloudnull> it loads the bridge into memory without an interface file.
16:48:09 <cloudnull> so you cant restart it
16:48:17 <cloudnull> IE ifup/down
16:48:23 <cloudnull> you have to restart the service
16:48:42 <cloudnull> it also is impossible to plugin the lxc.net interface into a real network
16:49:08 <evrardjp> I'll inform myself on this
16:49:09 <eil397> not possible to bridge it ?
16:49:15 <evrardjp> this seems a big deal
16:49:36 <cloudnull> eil397: you cant bridge the bridge
16:49:44 <odyssey4me> logan- to your question, it would seem like we're at that stage where perhaps we should rather be building something like a dnsmasq service in a container which all the hosts talk to - then ensure that it serves the names... then at least it keeps the ugly baby in a small space
16:49:50 <eil397> ok. add interface to the bridge ?
16:49:53 <logan-> I'm using an unbound role to have centralized dns resolution instead of syncing hosts. Just trying to figure out what I need to update in my unbound role (currently just syncing {{ container }}
16:50:08 <cloudnull> logan-: that should only be executed against the physical hosts. not the containers.
16:50:47 <evrardjp> we should use designate to add each new container into a new zone
16:50:52 <cloudnull> in the past we had all hosts being able to resolve all hosts and containers but were doing this with the inventory names which resulted in a non-complaint hostname
16:51:24 * odyssey4me kicks evrardjp's butt...
16:51:29 <evrardjp> :D
16:51:39 <cloudnull> eil397: i guess you could manually add an interface to the bridge. but at last check the service didnt allow you to do that
16:52:18 <cloudnull> odyssey4me: ++ for the DNS service idea.
16:52:33 <eil397> cloudnull: thanks. interesting. i would like to look on this lxc.net service : - )
16:52:43 <cloudnull> rackertom was talking about something similar a while back.
16:52:56 <evrardjp> unbound is quite light
16:53:23 <odyssey4me> yeah, this is one of those things we really need to take a step back and re-look at the purpose and re-imagine how to solve the goals
16:53:41 <cloudnull> eil397: if we could achive the same thing without carrying lxcbr0 as something our lxc_host role accomplishes I'm +1
16:54:41 <odyssey4me> logan- if you have thoughts on how to make the DNS stuff go better, and the time to put a patch up, I think we'd love to see it
16:54:47 <evrardjp> cloudnull: that's cheap you could even +2!
16:55:04 <odyssey4me> that /etc/hosts based thing is becoming a nasty grinch
16:55:05 <cloudnull> eil397: if we could achive the same thing without carrying lxcbr0 as something our lxc_host role accomplishes I'm +2
16:55:07 <cloudnull> :p
16:55:16 <evrardjp> logan-: keep in mind rabbitmq and all the things *recommend* not using dns
16:55:22 <logan-> Ok I will put that on the list. I've had good luck with the unbound stuff so far.
16:55:41 <eil397> cloudnull: I think +2 can be if it will be backward compat : - )
16:56:30 <odyssey4me> ok, we're pretty much out of time
16:56:34 <odyssey4me> thanks all!
16:56:35 <cloudnull> just a note: I'd like to make sure whatever we end up doing w/regard to DNS is ipv6 compatible/portable.
16:56:40 <odyssey4me> any further chat please move to the channel
16:56:52 <evrardjp> thanks everyone
16:56:53 <odyssey4me> cloudnull ++
16:56:55 <odyssey4me> #endmeeting