16:04:52 <cloudnull> #startmeeting openstack_ansible_meeting
16:04:53 <openstack> Meeting started Thu May 28 16:04:52 2015 UTC and is due to finish in 60 minutes.  The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:56 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:05:13 <cloudnull> good day gents
16:05:22 <prometheanfire> g'day
16:05:23 <cloudnull> #topic role call
16:05:23 <stevelle> o/
16:05:27 <prometheanfire> o/
16:05:36 <dstanek> o/
16:05:40 <d34dh0r53> //0\\
16:05:51 <odyssey4me> o/
16:06:18 <Sam-I-Am> moo
16:07:32 <cloudnull> so we have no action items from next week
16:07:34 <sigmavirus24> o/
16:07:34 <cloudnull> so lets move on .
16:07:44 <sigmavirus24> cloudnull: we couldn't, it hasn't happened yet
16:07:50 <sigmavirus24> (action items)
16:08:03 <Sam-I-Am> action items - osad is the bomb diggity
16:08:03 <odyssey4me> back to the future?
16:08:16 <prometheanfire> review spec please :P
16:08:24 <cloudnull> 's/next/last/'
16:08:29 <Sam-I-Am> i have a spec that needs attention too :/
16:08:40 <cloudnull> #topic blueprints
16:08:47 <cloudnull> https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment-specs,n,z
16:08:52 <cloudnull> #link https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment-specs,n,z
16:09:04 <cloudnull> first up is the gentoo hosts spec
16:09:38 * Sam-I-Am taps foot
16:09:50 * sigmavirus24 taps Sam-I-Am
16:09:59 <cloudnull> so with that spec we've had a few reviews
16:10:30 <cloudnull> and it looks like this may be a good turning point in the spec to work out all of the issues that we'll face with multi distro support.
16:10:39 <cloudnull> IE what odyssey4me said in the last comment
16:10:52 <Sam-I-Am> bindep, anyone?
16:10:54 <prometheanfire> should that be a seperate spec that I depend on instead?
16:11:13 <prometheanfire> step 1, make generic
16:11:20 <prometheanfire> step 2, add gentoo support
16:11:29 <Sam-I-Am> a generic spec makes sense from a framework perspective
16:11:42 <cloudnull> it does.
16:11:45 <Sam-I-Am> i'm just dying to make it use rdo packages and ovs :)
16:11:58 <prometheanfire> you can be in charge of that
16:12:06 <cloudnull> # /kick Sam-I-Am
16:12:10 <Sam-I-Am> lol
16:12:14 <Sam-I-Am> i know how to get cloudnull riled up
16:12:36 <cloudnull> that said there are some technical issues that can come up with dealing with different os types.
16:12:42 <cloudnull> in a single deployment.
16:13:07 <cloudnull> in partcular the wheel building process can be incompatible between distros
16:13:08 <Sam-I-Am> that sounds like poor life choices
16:13:17 <Sam-I-Am> wouldnt it be 1 distro per deployment?
16:13:26 <cloudnull> especially in the case where linked libs are being used.
16:13:29 <prometheanfire> I'm not sure we can know all the badness until we try
16:13:41 <cloudnull> ^ that is true
16:13:57 <sigmavirus24> Should we set a level of badness that kills this idea?
16:14:01 <prometheanfire> it'll be an itteritive process
16:14:07 <sigmavirus24> i.e., if $badness -gt $X
16:14:17 <prometheanfire> sigmavirus24: if you can quantify badness
16:14:32 <cloudnull> so from my perspective I hink that it would be best to start with a consistent. IE containers and hosts are the same base os
16:14:33 <sigmavirus24> Pretty sure there's a scale for that
16:14:50 <cloudnull> consistent deployment
16:15:00 <prometheanfire> containers should be abstracted from the host imo
16:15:39 * Sam-I-Am likes consistent deployment idea
16:15:47 <cloudnull> #link http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/images/articles/mcgraw/072111_mcgrawfig02.jpg
16:15:59 <odyssey4me> yeah, it may be good to break this into two stages - one for the controller/infra hosts only, with Ubuntu still being deployed on the compute/storage hosts and containers using Ubuntu
16:16:01 <cloudnull> gentoo deployment , gentoo lxc containers.
16:16:18 <odyssey4me> the next stage would be to go down into the containers and compute/storage hosts
16:16:22 <odyssey4me> two linked blueprints
16:16:24 <cloudnull> rhel deployment , rhel lxc containers.
16:16:31 <prometheanfire> hmm
16:16:40 <prometheanfire> I thought we wanted to avoid multiple container types
16:17:11 <cloudnull> prometheanfire:  the good thing here is that the container base image already exists.
16:17:12 <cloudnull> https://images.linuxcontainers.org:8443/images/
16:17:15 <Apsu> ^
16:17:28 <prometheanfire> 404
16:17:34 <Apsu> I see supporting distros in containers as a base-image issue.
16:17:45 <Apsu> Provide appropriate base image, everything else is wheels and git
16:17:47 <cloudnull> use a real network .
16:17:56 <prometheanfire> fair enough
16:18:00 <prometheanfire> 443 works :P
16:18:16 <prometheanfire> neat, we have armhf containers too
16:18:28 <Sam-I-Am> can we use docker images?
16:18:28 <prometheanfire> been working on getting openstack keyworded for arm
16:18:30 * Sam-I-Am ducks
16:18:35 <Apsu> Sam-I-Am: *ducker
16:18:36 <prometheanfire> Sam-I-Am: /kick
16:18:42 <cloudnull> # /kick Sam-I-Am
16:18:50 <prometheanfire> so, to tie this up
16:19:26 <odyssey4me> cloudnull what was that tool which openstack-infra suggested at the summit which would handle the different dependant package names?
16:19:38 <prometheanfire> new spec for making osad generic, for both containers and hosts
16:20:25 <Apsu> Host-wise, that's essentially modularizing the distro-specific parts (file locations and package management)
16:20:27 <prometheanfire> Delorean?
16:20:34 <Apsu> Container-wise, imo that should be base-image things
16:20:34 <prometheanfire> Apsu: network config
16:20:47 <Apsu> prometheanfire: Not our problem.
16:20:49 <odyssey4me> prometheanfire just one thing though, if openstack-infra doesn't have support for gentoo then we can't hope to support it as we'll have no way to gate it
16:20:54 <Apsu> We only use bridges that are already made.
16:21:05 <Apsu> We happen to also provide an example config file for Ubuntu
16:21:06 <prometheanfire> odyssey4me: I'll have an image they can use
16:21:09 <Apsu> But that's the deployer's job
16:21:21 <Sam-I-Am> i think infra only currently has centos and ubuntu?
16:21:34 <prometheanfire> already building openstack images, just need to clean it up some
16:21:37 <Sam-I-Am> i'm guessing cent/rhel would be the most popular option behind ubuntu
16:21:42 <odyssey4me> prometheanfire you need to organise that with openstack-infra and get a working devstack on it
16:21:44 <prometheanfire> I assume so as well
16:21:53 <Apsu> Sam-I-Am: Fedora might be more popular, actually. But hey
16:21:57 <odyssey4me> otherwise for now we can only work with centos/ubuntu
16:22:01 <prometheanfire> eww, devstack
16:22:05 <Apsu> odyssey4me: Or takeover the world and replace devstack with our AIOs :D
16:22:09 <Sam-I-Am> Apsu: rpm-based
16:22:17 <d34dh0r53> Apsu: +1
16:22:27 <Sam-I-Am> fedora is popular, but it is not "enteprise linux"
16:22:39 <odyssey4me> yeah, the point is that OSAD can't go down the path of trying to add support for something that doesn't have more general openstack support
16:22:59 <odyssey4me> and we gate in openstack-infra, so that's the first entry-point for any new platform
16:23:05 <Apsu> Sam-I-Am: Yes. Unfortunately most people who want "enterprise linux" also want versions that have software/kernels so old most of the modern features they want out of openstack won't work :P
16:23:09 <Apsu> But hey!
16:23:28 <prometheanfire> odyssey4me: fair enough
16:23:53 <odyssey4me> anyway, if you're prepared to put the work into making room for other distro's then great... it'll pave the way for centos and others
16:24:10 <prometheanfire> step 1 can be done now
16:24:15 <sigmavirus24> odyssey4me: fwiw, the thing you were thinking of is bindep
16:24:26 <sigmavirus24> mordred can probably explain it well
16:24:30 <odyssey4me> sigmavirus24 yes, that's the one
16:24:53 <prometheanfire> which is just making osad prepared to be generic (staying with ubuntu/ubuntu)
16:25:01 <odyssey4me> bindep will be a key tool for the spec - otherwise we'll be maintaining package dependency lists...
16:25:15 <cloudnull> ++
16:25:16 <prometheanfire> step 2 relies on infra having os image testing and whatnot
16:25:59 <odyssey4me> prometheanfire sounds like you have two blueprints there - one to prep the foundation, another to add support for centos
16:26:10 <prometheanfire> centos?
16:26:13 <prometheanfire> what's that?
16:26:13 <odyssey4me> in the background you can get gentoo images into openstack-ci
16:26:15 <prometheanfire> I'm not doing that
16:26:22 <sigmavirus24> prometheanfire: the only other OS people use to deploy openstack?
16:26:37 <sigmavirus24> prometheanfire: it's pretty easy to add new images according to the infra docs
16:26:43 <odyssey4me> if the concept is proven on centos, gentoo would be next
16:26:44 * sigmavirus24 is kidding of course
16:26:46 <prometheanfire> I have users using gentoo hosts
16:26:56 <odyssey4me> FYI there are a few interested parties with regards to CentOS
16:27:03 <prometheanfire> then they can work on it
16:27:11 <prometheanfire> that would be a third spec
16:27:11 <Sam-I-Am> i get a lot of requests for rpm-based distros
16:27:27 <odyssey4me> alright, then gentoo second - and others can do centos in parallel
16:27:36 <prometheanfire> if rax wants me to work on it then I'll do both
16:27:40 <sigmavirus24> Sam-I-Am: centos charges on a revolutions per minute basis?
16:27:41 <prometheanfire> this is a my own time thing
16:27:53 <Sam-I-Am> sigmavirus24: yes, its the new hotness
16:27:58 <sigmavirus24> interesting
16:28:00 * sigmavirus24 strokes beard
16:28:25 <odyssey4me> prometheanfire ah, ok cool
16:28:44 <cloudnull> ok so next spec
16:29:03 <cloudnull> https://review.openstack.org/#/c/184726/
16:29:27 <cloudnull> #link https://review.openstack.org/#/c/184726/
16:29:52 <Sam-I-Am> yes
16:30:16 <cloudnull> so there has been some interest from vendors to provide vendor functionalty has been a thing.
16:30:17 <Sam-I-Am> any of the spec devs here?
16:31:07 <cloudnull> and so OSAD is going to need to come up with some contrib  or extras repo that vendors can contribute to
16:31:19 <cloudnull> i really dont want vendor roles in tree.
16:31:24 <Sam-I-Am> makes sense
16:31:30 <cloudnull> but i understand the desire
16:31:51 <odyssey4me> I'm down with vendors laying the groundwork, but their roles should be in their own repositories and playbooks should be external too.
16:31:53 <Apsu> Sounds like they should make this, then.
16:31:57 <cloudnull> so i think that OSAD can build upon what has been done in rpc-extras
16:32:03 <Sam-I-Am> they should work something like rpc-extras
16:32:07 <Sam-I-Am> yeah :)
16:32:38 <odyssey4me> OSAD provides the facility to consume extra roles. The issue at this point is more to do with where to put the playbooks.
16:32:47 <stevelle> so do we have momentum to merge rpc-extras into osad? :D
16:32:47 <cloudnull> odyssey4me:  if i pull from what cinder / neutron has been doing for a while now they both have lots of vendor functionality backed in.
16:32:53 <cloudnull> however now they are attemptoing to remove that
16:33:15 <cloudnull> and pull those extra bits into other repos
16:33:23 <cloudnull> i think we can do that from the very beginning .
16:33:23 <Apsu> stevelle: Wat? No. Church and state.
16:33:33 <odyssey4me> cloudnull Sure, much like we should start to use external roles for some of the bits we do in OSAD.
16:33:59 <Apsu> IMO, clone what rpc-extras is doing and make osad-extras.
16:34:05 <cloudnull> if plubgrid wants a community supportable distribution of their product in osad i think thats awesome i just dont want it in OSAD proper.
16:34:09 <Apsu> Make noise about it, let vendors start doing work
16:34:13 <Apsu> Done
16:34:22 <Apsu> We can evolve what that means as we go
16:34:40 <odyssey4me> cloudnull it sounds like there should be a stackforge repo for the role then
16:34:50 <cloudnull> odyssey4me:  i agree with the external roles thing, on premiss, i've just not found external roles to be able to provide what we need at present.
16:35:16 <cloudnull> not that we couldnt contribute to these other roles to make them better,
16:35:33 <odyssey4me> so it comes down to something similar to the hosts
16:35:35 <cloudnull> but whos to say we need to when our roles work and provide all the things we need.
16:35:53 <cloudnull> but back to plumbgrid
16:35:54 <odyssey4me> OSAD and OpenStack expect the bits outside of OpenStack configs to be there already
16:36:32 <odyssey4me> ie Plumbgrid can do whatever to get their bits deployed, but OSAD needs to facilitate that OpenStack can be configured to use that substructure
16:36:32 <cloudnull> but osad is an openstack deployment system. the only thing we expect is that the OS is present.
16:36:44 <Sam-I-Am> plumgrid :)
16:36:46 <Sam-I-Am> its a fruit
16:37:03 <Sam-I-Am> has anyone seen their playbooks yet?
16:37:05 <cloudnull> odyssey4me:  ++
16:37:33 <odyssey4me> So I figure that they should ensure that OSAD is configurable, but no plumgrid bits should be installed using OSAD directly.
16:38:13 <odyssey4me> all OSAD should be doing is allowing their drivers to be enabled, and allowing any bits they don't need configured to be disabled
16:39:08 <Sam-I-Am> wouldnt it work something like run-the-plumgrid-bits which sets things in os-ansible configs that pertain to it? such as... neutron stuffs.
16:39:11 <Apsu> osad-extras 4 lief
16:39:48 <prometheanfire> plugin
16:41:20 <d34dh0r53> I like the osad-extras, not sure where it will live or what the review/commit process will be though
16:43:24 <cloudnull> so im inclined to accept the spec / work until we work out a contributor model for vendors to put there stuff.
16:43:44 <cloudnull> once we do that we move the vendor roles into osad-contrib or something similar.
16:44:03 <sigmavirus24> I don't think osad needs to maintain a contrib repo
16:44:11 <odyssey4me> by contrib do you mean playbooks and roles sit underneath a subtree?
16:44:14 <sigmavirus24> Unless we give the contrib people core to only merge stuff on their bits
16:45:45 <cloudnull> similar to what neutron has done with the lbaas, vpnaas bits
16:46:00 <cloudnull> which we could give core access to within those repos.
16:46:28 <cloudnull> we could also create a vendor-playbooks directory in the main repo
16:46:44 <cloudnull> where they could contribute these extra roles within
16:47:11 <odyssey4me> cloudnull we could, but then do we exempt those from gate checks and automate their approvals?
16:47:22 <cloudnull> but telling them to piss off and host their bits elsewhere is not going to help build our community
16:47:28 <odyssey4me> why should we be policing their contributions?
16:47:47 <odyssey4me> (to their own stuff which only they use)
16:48:01 <odyssey4me> it's not about sending anyone away, it's just about scoping
16:48:24 <cloudnull> right. its similar to what we already have with netapp support for cinder.
16:48:27 <odyssey4me> I don't see why this project should carry bits that it'll never consume and has no idea what to do with
16:48:40 <cloudnull> its just that we baked that functionality into the cinder roles.
16:49:01 <Apsu> odyssey4me: That I agree with.
16:49:14 <odyssey4me> netapp support for cinder is exactly what I'm happy to have in OSAD - configs in OpenStack are facilitated, NetApp stuff is already in-place
16:49:49 <cloudnull> the netapp driver is part of core cinder.
16:50:06 <cloudnull> and the logic, which we'll never consume, is in our cinder role.
16:50:38 <cloudnull> which is made possible by our support for cinder nfs + netapp.
16:50:39 <odyssey4me> ie we need to ensure that our roles/plays allow any vendor (Cisco/Plumgrid/etc) to emable their driver and configure OpenStack... but we don't need to install/configure Plumgrid's proprietary software or Cisco's properiatary software/switches
16:51:22 <Sam-I-Am> so...
16:51:28 <Sam-I-Am> this sounds like another bigger topic
16:51:41 <Sam-I-Am> perhaps a separate item at a future meeting
16:52:29 <cloudnull> as of now sigmavirus24 and odyssey4me have reviewed the spec. if we're pushing for now, can we -2 the spec?
16:53:00 <odyssey4me> -2 is too harsh, I'd like to see it adjusted as per my comments
16:53:09 <odyssey4me> -2 sticks between patch sets
16:53:43 <Sam-I-Am> i'm still curious about the code
16:54:26 <sigmavirus24> odyssey4me: -2 is probably appropriate though if there are fundamental objections to the spec
16:54:30 <cloudnull> but the spec is to provide plumbgrid roles the generifying neutron is being done as part of another spec. if we have no intention on allowing them in then we need to firmly block it. IMO.
16:54:38 <sigmavirus24> and -2s can be removed
16:55:22 <cloudnull> so changing gears for the last few minutes.
16:55:23 <Sam-I-Am> -2 is just do not merge, not do not ever merge
16:55:45 <cloudnull> #topic open discussion
16:55:57 <Sam-I-Am> guess we'll do the config spec later :P
16:56:07 <cloudnull> Sam-I-Am:  yes
16:56:14 <d34dh0r53> I talked to Alex and he would like to get the ceilometer stuff on the agenda for next weeks meeting
16:56:14 <cloudnull> we have only 5 min left.
16:56:21 <cloudnull> or we can talk more about in the channel.
16:57:02 <cloudnull> I would like to invite "svg" to the core team. but he doesn't quite meet all of the requirements.
16:57:19 <cloudnull> so i thought i would bring it up here
16:57:25 <cloudnull> to see if there are any objects.
16:57:33 <cloudnull> before i submit it to the mailing list.
16:57:45 <sigmavirus24> cloudnull: requirements?
16:58:05 <sigmavirus24> Is svg not reviewing enough of the rest of the codebase or something?
16:58:06 <cloudnull> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
16:58:20 <cloudnull> mostly that he has not had a lot of reviews.
16:58:49 <cloudnull> however has merged code, has been in the channel for some time, and is well versed in ansible
16:58:54 <sigmavirus24> If we're really concerned about the requirements, we can work with svg to get their review status up
16:59:00 <cloudnull> + ceph experience
16:59:05 <sigmavirus24> Otherwise, I have no objection
16:59:28 <stevelle> if svg has capacity for some more reviews I have no objection
16:59:30 <cloudnull> so imo i think he's a good fit, but before i propose it on the ml i thought i'd ask for oppinions here.
17:00:20 <cloudnull> so if nobody has any? ill send out a note in a bit.
17:00:27 <d34dh0r53> cloudnull: +1
17:00:31 <cloudnull> other than that, we're out of time.
17:00:36 <cloudnull> so thanks everyone.
17:00:37 <cloudnull> #endmeeting