16:00:19 <odyssey4me> #startmeeting OpenStack Ansible Meeting
16:00:20 <openstack> Meeting started Thu Jan 28 16:00:19 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:34 <odyssey4me> #topic Agenda and rollcall
16:00:38 <palendae> o/
16:00:39 <d34dh0r53> o/
16:00:39 <cloudnull> o/
16:00:40 <prometheanfire> \/
16:00:49 <spotz> \o/
16:00:56 <jmccrory> o/
16:00:58 <serverascode> o/
16:01:12 <hughsaunders> word
16:01:23 <automagically> 0/
16:02:45 <mattt> \o
16:04:12 <cloudnull> hughsaunders: sanders palabra
16:04:13 <automagically> https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:04:18 <cloudnull> lol
16:04:22 <odyssey4me> :) thanks automagically
16:04:35 <odyssey4me> right, welcome everyone!
16:04:39 <hughsaunders> cloudnull: I looked that up on UD last time
16:04:49 <cloudnull> NSFW
16:05:09 <odyssey4me> Today we're going to discuss https://etherpad.openstack.org/p/openstack-ansible-multi-os-support specifically to try and break down the work
16:05:25 <odyssey4me> we'll focus on that for the first 30 mins, then move on to other topics
16:05:28 <prometheanfire> https://blog.flameeyes.eu/2013/03/autotools-mythbuster-automagically-disabled-dependencies
16:05:31 <pabelanger> o/
16:05:36 <jasondotstar> o/
16:05:38 <prometheanfire> that's what automagic means to me
16:06:12 <prometheanfire> odyssey4me: should we have a seperate etherpad for this pre-work?
16:07:07 <odyssey4me> prometheanfire I'd rather not - let's work on this for now and break it down more - then each stage can be broken out
16:07:17 <prometheanfire> ok
16:07:33 <prometheanfire> so, I think we should target non-voting gates
16:08:33 <odyssey4me> ok, let me give a quick brakdown of the stages I think the work can be broken down into
16:08:54 <odyssey4me> the first is simply doing enablement in the existing roles
16:09:20 <odyssey4me> ie still supporting only ubuntu, but changing the tasks and variables in such a way that the flow caters for other platforms
16:09:48 <odyssey4me> an example of how this can be done is in  https://github.com/openstack/openstack-ansible/blob/master/tests/roles/bootstrap-host/tasks/main.yml
16:09:50 <automagically> +1
16:10:03 <prometheanfire> right
16:10:23 <prometheanfire> I'd like to talk a little about pre-work even before osa work gets started
16:10:37 <odyssey4me> so, for example, the packages to install are separated into vars which are OS specific
16:10:55 <odyssey4me> eg: https://github.com/openstack/openstack-ansible/blob/master/tests/roles/bootstrap-host/tasks/main.yml#L23-L30 and https://github.com/openstack/openstack-ansible/blob/master/tests/roles/bootstrap-host/vars/ubuntu.yml
16:11:11 <odyssey4me> prometheanfire what sort of work do you mean?
16:11:13 <cloudnull> I'm also for the idea of adding in a NV gate for a given OS  that we want to support regardless if the project supports it at that time . we can then work on getting that test to pass.
16:11:47 <cloudnull> its more load on the gate but sets a direction of the project for the given cycle
16:11:51 <odyssey4me> please use the etherpad to add items under the 'work breakdown' section
16:11:55 <prometheanfire> https://github.com/cloudnull/os-ansible-deployment/tree/master-rhel
16:12:02 <prometheanfire> odyssey4me: ok
16:12:18 <odyssey4me> note that prior art is already set in another section of the etherpad
16:12:27 <prometheanfire> disk-image-builder needs support for the given OS
16:12:40 <prometheanfire> along with the simple-init and growroot elements
16:12:49 <odyssey4me> and prior art is often outdated, so I really feel that it's useful for reference, but not necessarily something that should be copy-pasted
16:12:54 <jiteka> mattt: thx
16:13:25 <prometheanfire> glean needs support for your OS, which is an openstack-infra project
16:13:43 <odyssey4me> prometheanfire sure, but I think we need to be careful initially to leave that out of scope for the project - we should rather say that we can only add support for platforms which openstack-ci already has images for
16:13:57 <cloudnull> ++ the master rhel stuff is a bit dated
16:14:12 <odyssey4me> if anyone wants to add additional images to openstack-ifra, that needs to be outside the scope of this work - at least to start with
16:14:26 <prometheanfire> most of the elements here need support for your OS https://github.com/openstack-infra/project-config/tree/master/nodepool/elements along with support for installing actual packages from https://github.com/openstack/requirements/blob/master/other-requirements.txt
16:15:00 <prometheanfire> odyssey4me: it's outside the scope of this work but I think it should be mentioned so that people know where they need to start
16:15:28 <prometheanfire> once all that prework is done I feel we should add a non-voting gate-job even if it's just periodic
16:16:22 <odyssey4me> we can add an experimental job which can be kicked off on demand
16:16:25 <prometheanfire> seperate from that, prep work can occur in OSA
16:16:39 <odyssey4me> it'll be non-voting, but will never kick off unless it's specifically requested
16:16:44 <prometheanfire> odyssey4me: that'd probably be best until it's somewhat workable
16:17:11 <prometheanfire> once it's 'stable' periodic or primary gate job would be nice
16:17:57 <prometheanfire> but that can be discussed at a later time
16:18:04 <odyssey4me> once it's stable, then we switch it to a per commit non-voting job for a two week cycle
16:18:10 <cloudnull> I also think with the role separation we can add support for various OS 's on a per role basis
16:18:14 <odyssey4me> if it proves stable through that phase, we switch it to voting
16:18:24 <prometheanfire> odyssey4me: agreed
16:18:30 <odyssey4me> cloudnull++
16:18:33 <mattt> so we will be gating on every supported OS?  is that the goal?
16:18:36 <prometheanfire> cloudnull: yep
16:18:37 <cloudnull> which means we can add additional OS testing on the same per role basis
16:18:42 <mattt> kind of feels like we have enough challenges gating against ubuntu only
16:18:44 <odyssey4me> I think a good place to start will be in the roles that are already separated
16:18:51 <cloudnull> mattt:  no i hope not
16:19:12 <cloudnull> but i would like to see CentOS in the coming cycle
16:19:18 <prometheanfire> for the remainder of this half hour I feel like we should specificly list out the OSA work needed
16:19:36 <mattt> cloudnull: i see value in centos, but i'm concerned when we start talking about fringe distros
16:19:38 <palendae> mattt: I'd hope not too - IMO CentOS/RHEL is the broader target
16:19:39 <prometheanfire> mainly spliting out vars/roles, mostly/only in the host side for the first pass
16:19:44 <odyssey4me> cloudnull can you add that to the etherpad under 'platforms to target' ?
16:20:08 <palendae> mattt: Yeah...I'd say if someone wants to try making PuppyLinux work, that's cool, but it's on them
16:20:36 <odyssey4me> prometheanfire can you please add next to each platform which already have openstack-ci images, and which don't
16:22:02 <odyssey4me> please add votes next to each platform indicating that you'd like to see it
16:22:07 <prometheanfire> odyssey4me: ok
16:22:09 <odyssey4me> the votes will determine the priority
16:22:39 <prometheanfire> I will say gentoo is the one I'm activly working on
16:22:52 <prometheanfire> I want mitaka to be the last version of openstack I package
16:23:03 <palendae> odyssey4me: Maybe votes would be one you're willing to work on?
16:23:48 <odyssey4me> palendae I'd rather have votes based on actual need/desire for the platform. ie do you want this for the purpose of a use-case you have
16:23:59 <palendae> ok
16:24:02 <cloudnull> not necessary some deployers are simply interested in the supportability of a different distro which would be nice for them to test if they dont want to or have the capacilty to work on the specific code
16:24:18 <pabelanger> prometheanfire: what OS specifically are you looking for support in diskimage-builder?
16:24:35 <prometheanfire> pabelanger: gentoo, see the patches linked in the etherpad
16:24:44 <pabelanger> ah
16:24:54 <odyssey4me> lol, better to add your own +1 to the platfor, not removing other votes
16:24:56 <prometheanfire> I have basic support in already, but those patches are the rest
16:25:01 <odyssey4me> that way we can tell who wants what :p
16:25:23 <automagically> Ah, I was the first offender there, my bad
16:25:37 <odyssey4me> ok - the voting can continue in time - the initial work actually doesn't relate directly to a platform
16:25:38 <palendae> So evidently one person has voted +3 on centOS and Ubuntu ;)
16:25:57 <odyssey4me> if we do this right, hopefully each platform's differences will be minor
16:26:05 <prometheanfire> I wonder who the fedora person was :P
16:26:16 <prometheanfire> odyssey4me: agreed
16:26:29 <prometheanfire> and to be clear, we are targeting host side first and only for now
16:26:47 <odyssey4me> well, let's chat about approaches here
16:27:03 <prometheanfire> does -1 mean your are going to sabotage it?
16:27:07 <odyssey4me> one way we can break this down is to consider focusing on multi-os enablement everywhere
16:27:29 <odyssey4me> and another could be to do something like enablement for compute/storage/swift nodes and ignore the control plane
16:27:33 <mattt> prometheanfire: that was me, i'm strongly against fringe distros :)
16:27:45 <odyssey4me> another is to only do host stuff and leave the containers alone
16:28:29 <prometheanfire> odyssey4me: at least at first I'd like to just target host (which include compute/cinder/swift as they are metal)
16:28:32 <odyssey4me> personally I kind-of think that we can do it everywhere, and a deployer can choose where to apply it
16:28:35 <palendae> prometheanfire: I was fedora, but ¯\_(ツ)_/¯
16:28:39 <logan-> can trusty containers run on vivid/systemd ubuntu?
16:29:04 <odyssey4me> I don't think this will add that much overhead, assuming we have people interested in assisting where a patch doesn't work on a different platform
16:29:12 <prometheanfire> we can eventaully do it everywhere, supporting only host side is just about splitting up the work
16:29:36 <oneswig> How would the baremetal flag affect this choice?
16:29:51 <mattt> oneswig: good question
16:29:58 <odyssey4me> prometheanfire sure, considering the currently broken out roles I think that it's largely going to start on the hosts anyway
16:31:09 <odyssey4me> oneswig yeah, I think this is going to create a bit of adventuring :)
16:31:09 <prometheanfire> oneswig: I think that's something we will have to solve ongoing
16:31:17 <cloudnull> logan-:  yes they can , however i'd when we introduce new OS support i'd like to see about keeping the container images the same
16:31:46 <cloudnull> so cent7 == cent7 containers etc...
16:31:47 <odyssey4me> cloudnull sure, to start with at least
16:32:12 <odyssey4me> well, that's what we test with - if a deployer wants to mix and match then it's their choice
16:32:16 <cloudnull> i would rather not have cent7 w/ trusty containers.
16:32:20 <odyssey4me> we have to limit our test matrix to be practical
16:32:35 <cloudnull> oneswig: what do you mean?
16:33:02 <prometheanfire> ya
16:33:12 <odyssey4me> oneswig prometheanfire I think the onmetal flag effect means that we will effectively have to do the enablement on everything
16:33:14 <prometheanfire> where are containers sourced from again?
16:33:19 <odyssey4me> we can't really choose
16:33:20 <oneswig> IIRC you can deploy OS-A without containers, which puts all into the host system.  In this mode there's no separation
16:33:26 <prometheanfire> odyssey4me: ya, probably
16:33:41 <cloudnull> prometheanfire: lxc templates
16:34:08 <odyssey4me> prometheanfire I'm working on a patch to make the image build more generic, which will make this work easier
16:34:15 <cloudnull> oneswig: yes . so i think if we introduce a new os all components need to support that os
16:34:48 <odyssey4me> ok, can we put some notes into the work breakdown about things we know will be different between OS's and OS versions
16:34:56 <prometheanfire> so should we have a more generic gate job that tests onmetal for everything?
16:34:59 <odyssey4me> eg: init vs systemd
16:35:04 <odyssey4me> package names
16:35:26 <oneswig> network interface management
16:35:52 <prometheanfire> oneswig: isn't that handled by iproute2?
16:36:17 <palendae> Probably more like /etc/network/ vs others
16:36:26 <palendae> Where config files go
16:36:27 <prometheanfire> we write to that?
16:36:33 <prometheanfire> and config file format
16:36:34 <oneswig> prometheanfire: not sure, I do some manual steps on systems for network config that are distro-specific
16:36:45 <odyssey4me> oneswig yeah, 'network configuration mechanisms'
16:37:40 <oneswig> I'm 3 weeks out of touch, wasn't this all in an etherpad?
16:37:53 <odyssey4me> oneswig https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
16:37:53 <palendae> oneswig: https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
16:37:58 <oneswig> thx
16:38:00 <odyssey4me> we're recodring notes in there right now
16:38:19 <palendae> That pad existed, we're doing a work session to flesh out more details
16:38:35 <oneswig> duh, really should arrive on time :-)
16:41:12 <prometheanfire> odyssey4me: so, for osa, first thing that needs done is spliting out 14.04 into OS specific roles
16:41:23 <michaelgugino> hello all
16:42:24 <spotz> hey
16:42:27 <cloudnull> o/ michaelgugino
16:42:57 <michaelgugino> sorry, I was stuck in a meeting.
16:43:16 <michaelgugino> meeting still in progress?
16:43:27 <prometheanfire> ya, still working on https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
16:43:28 <mattt> michaelgugino: https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
16:44:24 <odyssey4me> prometheanfire I don't think there needs to be OS specific roles at all
16:44:42 <prometheanfire> roles was probably the wrong word :P
16:44:54 <odyssey4me> I think that we can use common roles, but do task inclusion splits for special tasks based on Ansible's knowledge of the target host
16:44:57 <cloudnull> -1 for os specifc roles
16:45:14 <prometheanfire> ya, that's what I meant
16:45:41 <pabelanger> odyssey4me: do we have time to loop back to the ansible roles I am working on and seeing if adding them to this team is a good fit?
16:45:45 <oneswig> If we set on Ansible 2.0 we get this http://docs.ansible.com/ansible/package_module.html
16:45:46 <automagically> Not sure if its been mentioned but do we need to account for multiple OSes on the control host?
16:45:47 <odyssey4me> ok, so how do we break this down into small enough parts
16:46:05 <odyssey4me> pabelanger it looks like we'll be quite busy with this until the close of the meeting
16:46:05 <mattt> oneswig: yay!
16:46:15 <odyssey4me> pabelanger can you add it to the next meeting's agenda please?
16:46:19 <pabelanger> odyssey4me: sure
16:46:50 <palendae> oneswig: Yeah - the trick is moving to ansible 2.0 along with openstack services AND OS versions
16:47:20 <oneswig> that's quite a trick
16:47:33 <palendae> Indeed
16:47:37 <cloudnull> thus endith the trick ! :)
16:47:40 <odyssey4me> oneswig palendae I'm not entirely a fan of trying to wedge Ansible 2 stuff into this cycle
16:47:48 <palendae> oneswig: Nor am I
16:47:52 <odyssey4me> and I think that this work will probably be done in this cycle and the next
16:47:55 <palendae> Er, odyssey4me
16:47:56 <michaelgugino> ansible 2 is a big effort, I would think.
16:48:07 <palendae> But that'll be the hurdle no matter when it happens
16:48:12 <odyssey4me> so I'm keen to work on what we can with Ansible 1.9x in this cycle, then look an Ansible 2 stuff next cycle
16:48:16 <michaelgugino> I'd rather backport/reimplement the package module from ansible 2 and include it as a plugin, if necessary.
16:48:21 <prometheanfire> I'm not saying any of this should target this cycle :P
16:48:44 <cloudnull> thanks to the efforts of jmccrory we're there i believe (or almost at least) to be ansible to compatible
16:48:48 <palendae> Yeah - I'm not advocating ansible 2.0 right now. Just pointing out the migration will be concurrent with lots of other things
16:49:10 <odyssey4me> I'm not entirely sure that the Ansible 2 install module gives us all that much - this is a simple enough pattern to apply: https://github.com/openstack/openstack-ansible/blob/master/tests/roles/bootstrap-host/tasks/main.yml#L41-L46
16:49:31 <pabelanger> palendae: I am running into some problems with 2.0, breakages in general. Just an FYI when porting upwards
16:49:39 <palendae> pabelanger: Right
16:49:48 <palendae> Anyway, that's all a digression
16:50:07 <odyssey4me> ok, so we can break down this work into per-role work, but also into the layers
16:50:26 <mattt> i like per role, because that means we cna start gating those on different distros pretty much immediately
16:50:27 <odyssey4me> first we focus on simply changing our tasks so that they don't assume Ubuntu and apt everywhere
16:50:46 <odyssey4me> and yes, mattt, I think the work should start in the already broken out roles
16:50:49 <prometheanfire> odyssey4me: I added next steps down below
16:51:19 <cloudnull> odyssey4me mattt +1
16:51:27 <odyssey4me> prometheanfire ah, under 'next steps.
16:51:38 <jmccrory> going with the var file per os pattern?
16:51:38 <prometheanfire> yep
16:51:48 <prometheanfire> I'm trying to get a task list for myself
16:51:53 <prometheanfire> so I know what to work on
16:52:19 <odyssey4me> jmccrory we know it works - are there other options?
16:52:43 <jmccrory> no, i think that looks like a good option
16:53:16 <cloudnull> i believe we can do conditional includes of var files from the vars/main.yml
16:54:00 <prometheanfire> cloudnull: it is possibly but the code looked hairy last time I looked
16:54:34 <odyssey4me> can we allocate people to do the next steps on a specified role - I'm thinking that we can perhaps allow the freedom to choose any method that makes sense as a Spike, then compare when the test is in review?
16:54:38 <cloudnull> if it works, then we wont have to use the var load module which comes with its own quirks
16:55:35 <odyssey4me> ie we have someone work on the galera role, and someone else on the rabbit role - then we compare notes and discuss how much we like the options/methods implemented?
16:55:46 <prometheanfire> cloudnull: true
16:55:50 <michaelgugino> I like that idea odyssey
16:55:57 <prometheanfire> odyssey4me: that sounds good
16:56:08 <cloudnull> +1
16:56:12 <odyssey4me> michaelgugino will you have time to tackle one?
16:56:21 <odyssey4me> it seems like prometheanfire would like to tackle the other?
16:56:27 <michaelgugino> yes, I have time tomorrow and next week
16:56:39 <odyssey4me> any volunteers to tackle a third? the more variety we have, the better the spike
16:56:52 <michaelgugino> I'm working on DVR changes, and I'm waiting on some input from my network eng/neutron eng, so that's at a standstill for now.
16:56:55 <prometheanfire> I could do either, it would most likely be me working on it next week
16:57:01 <prometheanfire> though maybe over the weekend
16:57:46 <odyssey4me> and what work do we start with for this spike?
16:57:56 <mattt> galera has a dependency on some other stuff
16:58:00 <odyssey4me> just the package installs, or do you think systemd support could be fit in?
16:58:01 <mattt> so perhaps not the right place to start?
16:58:11 <mattt> cloudnull: what is the base role that we would need to work?
16:58:27 <cloudnull> maybe rabbitmq
16:58:35 <mattt> i'm thinking apt_package_pinning etc.
16:59:25 <cloudnull> maybe lxc-hosts
16:59:25 <palendae> Hm
16:59:33 <palendae> Maybe I should get my dependency graphs made
16:59:42 <palendae> Where did I put those last time..
16:59:51 <cloudnull> thats a complex role but is very integral in supporting everything else
16:59:52 <mattt> ok i think i misunderstood goal here
17:00:00 <jmccrory> memcached_server looks easy enough
17:00:01 <odyssey4me> well, considering that the current focus is just to establish a pattern - the dependent roles will largely be irrelevant I think
17:00:10 <mattt> i thought we were going to wedge another distro in immediately, but that's not correct
17:00:11 <odyssey4me> for systemd support work that won't be true
17:00:12 <prometheanfire> palendae: that would be nice for this
17:00:15 <palendae> https://dl.dropboxusercontent.com/u/1887128/osa.png
17:00:28 <openstack> cathy_: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
17:00:30 <palendae> That's a little dated, I will try to get a doc patch in that builds the dep list
17:00:38 <odyssey4me> ooh sorry cathy_ - we'll vacate
17:00:44 <odyssey4me> move to #openstack-ansible
17:00:45 <cloudnull> cheers
17:00:46 <cathy_> odyssey4me: thanks!
17:00:47 <odyssey4me> #endmeeting