16:00:00 <mhayden> #startmeeting openstack_ansible_meeting
16:00:01 <openstack> Meeting started Thu Dec 15 16:00:00 2016 UTC and is due to finish in 60 minutes.  The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:08 <mhayden> #topic Roll Call!
16:00:12 <andymccr> o/
16:00:13 <stevelle> o/
16:00:20 <asettle> o/
16:00:20 <evrardjp> o/
16:00:32 <mhayden> the perfectionist in me is always happy when i hit it right at 16:00 ;)
16:02:12 <adreznec> o/
16:02:14 <palendae> Hi
16:02:24 <mhayden> thanks to the kind person who updated the agenda ;)
16:02:59 <jmccrory> o/
16:03:30 <andymccr> i got you mhayden!
16:04:12 <mhayden> unfortunately some of us rackspace folks are in another meeting right now, too :P
16:04:16 <mhayden> but let's get underway
16:04:59 <logan-> o/
16:05:07 <mhayden> #topic Review action items from last week
16:05:27 <mhayden> first up is -> review and backport https://review.openstack.org/#/c/408677/ (and review the backport!)
16:05:31 <andymccr> its merged
16:05:35 <andymccr> + backport!
16:05:41 <mhayden> hooray!
16:05:44 <mhayden> my favorite kind of action items
16:05:53 <mhayden> next was -> review https://review.openstack.org/#/c/407607/ before release
16:05:58 <andymccr> reviewed and merged
16:06:03 <mhayden> hot dang
16:06:23 <mhayden> #topic Discussion Topics
16:06:31 <mhayden> well this section appears to be empty
16:06:44 <andymccr> christmas time im guessing :)
16:06:46 <mhayden> it is holiday times :)
16:06:52 <mhayden> okay, moving right along
16:06:57 <mhayden> #topic Release planning & decisions
16:07:07 <andymccr> yay!
16:07:07 <andymccr> ok
16:07:08 <andymccr> so
16:07:19 <andymccr> OpenStack-Ansible milestone 2 was released!
16:07:26 <odyssey4me> \o/
16:07:43 <evrardjp> woot
16:07:45 <andymccr> newton 14.0.4 and mitaka 13.3.10 are ready but pending
16:07:57 <andymccr> the role SHA revert for master isn't passing at the moment
16:08:05 <andymccr> nor are the sha bumps for newton/mitaka so will need to look into those
16:08:29 <andymccr> but thats all really :) all good!
16:08:40 <palendae> andymccr: Ocata milestone 2?
16:08:49 <evrardjp> andymccr: I think mhayden spotted an issue with mysql version for gnocchi
16:08:53 <andymccr> palendae: yip
16:09:02 <evrardjp> so some ppl could have a look, that would be great!
16:09:04 <mhayden> yeah, i was confused on that mysql failure
16:09:07 <andymccr> Ocata milestone 2, its due by end of today, ours merged this morning so we're all in and good
16:09:10 <mhayden> haven't had a chance to peek
16:09:20 <evrardjp> neither do I mhayden :/
16:09:29 <andymccr> yeah if anybody feels like looking into the failures for the sha bump on newton/mitaka or the ansible-role pin revert on master, would be awesome
16:10:04 <andymccr> i'll try take a look tomorrow and fix that up :)
16:10:13 <mhayden> i did find something that we might want to get into the next release, though -> https://review.openstack.org/#/q/topic:bug/1650035
16:10:15 <evrardjp> else we just say on m2 until release. Ok I'm out.
16:10:28 <mhayden> long story short, heat expects cinder's backup functionality to be turned on
16:10:38 <mhayden> if it isn't, you end up creating undeletable stacks!
16:10:59 <mhayden> IMMUTABLE STACKS
16:11:02 <mhayden> which sounds good at first
16:11:04 <evrardjp> that's cool
16:11:07 <evrardjp> it's a feature
16:11:08 <mhayden> but it's really not, in this case :)
16:11:11 <evrardjp> :D
16:11:25 <andymccr> well tl;dr lets fix mitaka/newton/master :P
16:11:29 <evrardjp> I thought you had to know heat DB in order to use it
16:11:43 <mhayden> so if folks can ensure i didn't make a horrible error with those patches, i'd be much obliged
16:12:00 <evrardjp> marked for review, next?
16:12:02 <evrardjp> :D
16:12:43 <mhayden> #topic Blueprint work
16:13:24 <mhayden> the security role blueprint is sooooo close to being finished
16:13:28 <odyssey4me> mhayden is it possible to turn off that feature in heat? If so a group_var could easily be crafted to do that.
16:13:40 <mhayden> odyssey4me: that's in my patches :)
16:14:05 <mhayden> remaining security role items: https://review.openstack.org/#/q/project:openstack/openstack-ansible-security+status:open
16:14:15 <andymccr> nice!
16:14:18 <mhayden> a few bugs there
16:14:28 <andymccr> almost there
16:14:32 <mhayden> i'll try to get it testing with the integrated role very soon
16:15:02 <mhayden> any other blueprint updates?
16:15:07 <mhayden> the trusty cleanup is moving along well
16:15:14 <andymccr> yeah so
16:15:20 <andymccr> all patches should be in (except security role)
16:15:24 <mhayden> asettle: anything we can do to help with the ops guide work?
16:15:26 <andymccr> some are failing, i'll look at that today/tomorrow
16:15:33 <mhayden> (it's weird because i can see asettle in a VC call right now)
16:16:05 <mhayden> we'll see if she jumps in later
16:16:05 <andymccr> https://review.openstack.org/#/q/status:open+topic:bp/trusty-removal
16:16:07 <evrardjp> how luchy
16:16:18 <evrardjp> lucky*
16:16:32 <andymccr> also upgrade testing is basically done - there is no upgrade test for galera though - which we probably should have, and integrated build
16:16:54 <logan-> a working ceph-ansible integration is up at https://review.openstack.org/#/c/409407/ -- i'll be taking the WIP off as soon as I have time to write up some basic docs/reno for it as a testing-only thing for now. but andymccr it should be possible to get an integrated build scenario job added for this right?
16:17:10 <asettle> mhayden: sorry man, check back in with me when I'm not answering questinos on what thing :P
16:17:17 <andymccr> logan-: what do you mean by scenario? like an additional test?
16:17:32 <odyssey4me> yeah, it is possible to add scenario's now
16:17:47 <jmccrory> andymccr no upgrade test between branches? i think there's an test for 10.0 to 10.1
16:17:51 <odyssey4me> a sample is here: https://review.openstack.org/370638
16:17:56 <andymccr> jmccrory: ahh ok that probably works
16:18:09 <logan-> correct we have scenario testing support in bootstrap-host, so that patch adds a scenario for ceph
16:18:23 <odyssey4me> awesome
16:18:24 <logan-> you pass the SCENARIO envvar to gate-check-commit i think
16:18:39 <odyssey4me> yep, andymccr you'll see that instrumented in project-config
16:18:53 <odyssey4me> it grabs the scenario name from the job name
16:19:22 <andymccr> odyssey4me: yeah ive seen them, im just makign sure the ask is to add it to the test infra
16:19:24 <odyssey4me> we can add a ceph scenario as experimental and give it a whirl
16:19:36 <logan-> yes i'd like to get it added to infra
16:19:38 <andymccr> i'll add that logan-
16:19:40 <logan-> thanks!
16:19:40 <andymccr> no problem
16:19:53 <andymccr> thanks for doing the work behind that1
16:21:43 <mhayden> okay, moving along
16:21:48 <mhayden> #topic Open Floow
16:21:53 <mhayden> #undo
16:21:54 <openstack> Removing item from minutes: #topic Open Floow
16:21:57 <mhayden> #topic Open Floor
16:21:59 <andymccr> hahahaha
16:22:02 <mhayden> FLOOOOOOOOOW
16:22:06 <andymccr> subtle plug for openflow
16:22:38 <stevelle> super subtle
16:22:41 <evrardjp> dragonflow implements an openflow like thing
16:23:16 <evrardjp> reviews welcome :p
16:23:21 <palendae> Something I've been noticing lately - we've been a little lax on including release notes. I know I've forgotten them myself on a bunch of changes
16:23:21 <andymccr> ahh yeah
16:23:23 <andymccr> dragonflow is fixed now
16:23:39 <evrardjp> I'll have a look andymccr
16:23:46 <andymccr> palendae: good point
16:24:04 <andymccr> ive had a couple where i -1'd for that, but would be good if we could be more consistent (where release notes are required)
16:24:05 <palendae> Mostly just a poke to remind us, when reviewing, to ask for them
16:24:20 <palendae> We did great when reno first appeared
16:24:29 <evrardjp> palendae: yes it's a good idea to poke
16:25:07 <evrardjp> I also forgot to call for a release note in master, so if we backport to newton without touching the patch we'll forget the release note :/
16:25:30 <evrardjp> I mean we have to remember all the times, not only in stable branches
16:25:35 <palendae> Yeah
16:25:43 * cloudnull lobs a grenade
16:25:47 <cloudnull> anyone have thoughts on using nspawn instead of general LXC?
16:25:47 <evrardjp> just when you think it's backport potential -> think release note!
16:26:00 <palendae> cloudnull: Whoa, you're not the person I'd think to suggest that :p
16:26:10 <evrardjp> cloudnull: I hated the networking model at first, lxc is so simple
16:26:32 <cloudnull> w/ us moving to only OS's w/ systemd, nspawn could be an option to remain platform agnostic .
16:26:40 <cloudnull> idk if it's totally possible.
16:26:48 <evrardjp> cloudnull: docker works too
16:26:52 <evrardjp> for that
16:26:54 <evrardjp> :p
16:26:55 <cloudnull> just was thinking about evolutionary ideas.
16:27:15 <cloudnull> evrardjp: docker would not work because it can't support an init
16:27:19 <evrardjp> I don't think there is a problem suggesting it :D
16:27:25 <andymccr> cloudnull: if there is genuine benefit - would be a good point of interest for the PTG - if you're keen to write up an etherpad and some other stuff.
16:27:32 <cloudnull> ++
16:27:44 <palendae> I have no thoughts other than it's worth a prototype
16:27:55 <cloudnull> was +/- curious
16:27:58 <evrardjp> well the networking models are really interesting in your prototype
16:28:04 <andymccr> thats really only like 2 months away - seems good timing wise :P
16:28:08 <evrardjp> and I'd be happy to have results
16:28:11 <evrardjp> it seems good
16:29:12 <cloudnull> ok. was just curious if there were violent objections .
16:29:31 <evrardjp> not from me
16:29:43 <evrardjp> we should be open!
16:29:44 <andymccr> cloudnull: im a pacifist - if i dont like your idea i'll beaurocrat it to death - no violence.
16:30:00 <evrardjp> lol
16:30:00 <cloudnull> obviously no matter the solution we're going to have to provide upgrade paths for folks.
16:30:10 <odyssey4me> cloudnull I think that nspawn would be a great use case for abstracting out hypervisor.
16:30:12 <cloudnull> if that's lxc, lxd, other
16:30:19 <odyssey4me> out our use of a hypervisor I mean
16:30:25 <palendae> cloudnull: No objection, but since I don't know much about it I wouldn't mind seeing some sort of implementation
16:30:29 <andymccr> yeah of course, but i think its silly to not stay aware of new and potentially better tools/platforms etc.
16:30:37 <andymccr> yeah agree /w palendae
16:30:37 <cloudnull> ++
16:31:15 <odyssey4me> although nspawn would put us into a position much like we are with LXC - it won't really move us forward
16:31:21 <palendae> IMO a prototype to see what kinds of rough edges and advantages there are, then a spec would be good
16:31:34 <palendae> And that goes for any alternative
16:31:36 <cloudnull> IDK if nspawn is a good idea at this point, i know it was a terrible idea before but with recent systemd it doesn't seem to make me want to punch a baby. so there's that.
16:31:45 <odyssey4me> moving towards buying into LXD more wholesale brings us a lot of new features, whereas implementing nspawn brings us nothing but a lower cost footprint
16:32:21 <odyssey4me> well, that's as far as I saw when I last looked into it
16:32:26 <cloudnull> odyssey4me: that's true, i will say though that images in nspawn are really just a tarball of a chroot
16:32:48 <odyssey4me> cloudnull yeah, so that's what I like about it - but then again LXC images are just a rootfs tarball too
16:32:49 <asettle> OMG IM BACK
16:32:50 <asettle> IM SORRY
16:32:51 <asettle> IM SO BAD
16:32:58 <asettle> mhayden: sorryyyy
16:33:04 <odyssey4me> so this is why it's not offensive, and probably a relatively easy implementation
16:33:14 <evrardjp> cloudnull: think also on the operators ease of use if possible
16:33:35 <odyssey4me> but moving to LXD brings us an API for managing containers and hosts - whereas nspawn is still pretty much a per host model much like LXC
16:33:41 <cloudnull> in looking at lxc and lxd images there's quite a bit of meta-data that has to go a long with them, where as in nspawn there's none.
16:33:54 <cloudnull> that is true
16:34:06 <michaelgugino> lxd ftw
16:34:08 <odyssey4me> well, if you look at the metadata there's not much to it
16:34:26 <michaelgugino> lxd will boot pretty much any root tarball without extra instruction
16:34:31 <cloudnull> you're right there's not much, but it is >0
16:34:37 <michaelgugino> don't have to create whacky profiles, etc
16:34:40 <evrardjp> what michaelgugino said is true :)
16:34:41 <palendae> nspawn is local management only, right? hence being mostly a side-grade?
16:34:55 <cloudnull> correct
16:34:58 <cloudnull> its local only
16:35:31 <cloudnull> like i said before, lobbing grenades.
16:35:45 <odyssey4me> if we were looking to cover small deployments then I'd say go with nspawn... but we're looking at production grade enterprise implementations... I think that LXD is a better fit for the long term
16:36:02 <cloudnull> I don't disagree at this point .
16:36:13 <odyssey4me> I would even suggest that we should perhaps consider dropping the 'optional' use of containers in the long term and buy into the model wholesale.
16:36:28 <michaelgugino> I completely agree with that
16:36:29 <palendae> I've been lxd-curious for a while, but just not taken the time to rewrite stuff to try it
16:36:32 <odyssey4me> at least for the integrated build
16:36:41 <palendae> odyssey4me: It would certainly make inventory easier
16:36:47 <stevelle> seems to me that lxd sounds like a better fit, but that effort is going so might as well ensure nspawn is properly disqualified by spiking it :)
16:36:52 <evrardjp> oh I didn't know about machinectl pull-tar
16:36:53 <evrardjp> nice
16:37:10 <cloudnull> yea. its neat
16:38:05 <cloudnull> it can even pull raw
16:38:30 <cloudnull> which would allow for pulling a base image from a distro
16:38:55 <stevelle> possible artifacty goodness too?
16:38:58 <cloudnull> but I've not really tried anything with it . was just poking at all the things
16:38:59 <odyssey4me> if we want to persue hypervisor abstraction - which I question the value of beyond it being cool to do - then we should possibly consider looking at the whole deployment model and try to abstract a  bunch of things
16:39:21 <odyssey4me> it just seems like a lot of rework with very little value attach to it
16:39:22 <evrardjp> OMG systemd-nspawn really improved ... you can now have --network-veth or --network-interface=eth0
16:39:24 <evrardjp> woot
16:39:36 <odyssey4me> but hey, if you're bored and have some time to spike it - go for it
16:39:50 <cloudnull> im going on vacation starting tomorrow
16:40:01 <evrardjp> holiday tomorrow!
16:40:06 <cloudnull> so looking at things I can do, besides brake my house :)
16:40:17 <odyssey4me> but if we start to merge things like that it bring us into a scary place where we're having to cater for so many options that no-one is using to our knowledge
16:40:24 <stevelle> gotta start with a plumbing project then quit halfway to work on nspawn
16:40:35 <cloudnull> stevelle: ++
16:40:38 <cloudnull> :p
16:40:47 <palendae> stevelle, cloudnull: Context switching as anger management
16:41:06 <cloudnull> odyssey4me: agreeded. I don't want to break focus.
16:41:07 <odyssey4me> what might be neat is putting together an Ansible-based alternative to devstack based on nspawn :p
16:41:19 <evrardjp> stevelle: haha
16:41:21 <palendae> :o
16:41:55 <cloudnull> I think our project has maintained fantastic focus on large scale deployments and I'd rather not create a bunch of one off nonsense.
16:41:58 <evrardjp> odyssey4me: or you mean with an ansible alternative based alternative to devstack?
16:42:10 <odyssey4me> lol evrardjp
16:42:16 <stevelle> nicely done
16:42:19 <odyssey4me> or write go-configure
16:42:33 <evrardjp> we've been talking about that
16:42:39 <evrardjp> I suggest a vote
16:42:45 <andymccr> now now :P
16:42:50 <evrardjp> lol
16:43:20 <palendae> If someone wants to spike, go ahead. But then we'll see if it gets approved via review
16:43:32 <cloudnull> ++
16:43:57 <palendae> So it gets a vote, but we're not voting on what someone chooses to do with their time
16:44:57 <evrardjp> I was... just kidding? Sorry :/
16:45:09 <stevelle> I already voted for the half a plumbing project idea :P
16:45:14 <evrardjp> Anyway, if there is no other topic, I'm leaving. Thank you for the meeting!
16:45:22 <odyssey4me> cloudnull I would perhaps suggest looking into how LXD operates, and how we can implement a LXD image cluster back-end... I don't think it clusters itself.
16:45:24 <palendae> evrardjp: Didn't mean to call you out, just that a vote is good, but not now :)
16:46:09 <evrardjp> odyssey4me: I think it kinda work p2p mode
16:46:13 <andymccr> id like to see some investigation results for the PTG, that'd be awesome. and not just a "theoretically x y z" but spike work being completed - on any ideas that are genuinely serious
16:46:21 <palendae> ^
16:46:22 <mhayden> note: about 13 minutes left in the mtg
16:46:23 <cloudnull> odyssey4me: will do
16:46:23 <odyssey4me> but yes, realistically I would actually suggest stepping away from the laptop for the holidays
16:46:29 <palendae> ^
16:46:33 <andymccr> haha yes
16:46:34 <michaelgugino> each lxd host operates independently; you establish a trust between them for sharing images, etc
16:46:36 <palendae> Or doing not work :)
16:46:48 <palendae> Program something else
16:47:18 <odyssey4me> michaelgugino yeah, I'm thinking about how we would implement a clustered image store in the environment or as a service
16:47:27 <palendae> glance? ;)
16:47:38 <michaelgugino> also, fyi, I finally got the fix for the ansible apache2_module merged; however they are leaving it in devel for this release because?  Anyway, maybe it will be out in ansible 2.2.n+1
16:48:08 <odyssey4me> ah nice
16:48:12 <michaelgugino> odyssey4me: you only need to upload the images to one lxd host, establish the trust, and the other hosts will copy over the images when needed
16:48:25 <odyssey4me> michaelgugino then 'when needed' is the issue
16:48:32 <odyssey4me> if that host goes offline, then you lose them
16:48:57 <michaelgugino> if we're talking about the control plane, they images will be cached locally once we boot them
16:49:04 <odyssey4me> ideally I'd like to build them, host them on a web server somewhere, then tell the LXD service to fetch them
16:49:38 <palendae> odyssey4me: That webserver being inside the cluster?
16:49:44 <michaelgugino> lxd supports that
16:49:49 <palendae> Unless it's made HA you theoretically have hte same problem
16:49:51 <odyssey4me> we should ideally be able to stage them so that it doesn't only cache them when you build a container
16:50:17 <stevelle> yupp
16:50:42 <michaelgugino> https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/
16:50:44 <michaelgugino> lxd image copy
16:50:51 <odyssey4me> I suppose the way to do it might be to simply pre-stage the images from the web server into the repo server - then have LXC use the repo server once it's there
16:51:00 <evrardjp> this post was good indeed
16:51:02 <odyssey4me> similar to how we're using get-pip.py and upper constraints now
16:51:32 <odyssey4me> anyway, this is all really just pontification right now.
16:51:41 <odyssey4me> my hot tub is calling me
16:51:48 <michaelgugino> lol
16:52:04 <andymccr> ok cool - we all done here for today? :D
16:52:12 <palendae> michaelgugino: Thanks for that link
16:52:40 <odyssey4me> :) cheers all, chat tomorrow
16:52:58 <stevelle> looks like andymccr / mhayden maybe end now?
16:53:04 <mhayden> can do
16:53:08 <evrardjp> thx everyone
16:53:09 <mhayden> thanks everyone
16:53:10 <andymccr> do it mhayden :D
16:53:11 <mhayden> #endmeeting