16:03:30 <cloudnull> #startmeeting OpenStack Ansible Meeting
16:03:31 <openstack> Meeting started Thu Jun  4 16:03:30 2015 UTC and is due to finish in 60 minutes.  The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:35 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:03:41 <galstrom> o/
16:03:45 <cloudnull> #topic Agenda & rollcall
16:03:55 <rromans> .
16:04:12 <sigmavirus24> o/
16:04:26 <stevelle> o/
16:04:28 <prometheanfire> \o
16:04:36 <dstanek> o/
16:07:20 <cloudnull> so lets get started.
16:07:31 <cloudnull> #Blueprints
16:07:36 <cloudnull> #topic Blueprints
16:08:01 <cloudnull> #link https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment-specs,n,z
16:09:12 <cloudnull> this spec needs to be re-reviewed https://review.openstack.org/#/c/184726/
16:09:56 <cloudnull> Javeria Khan has revised the spec
16:10:19 <cloudnull> and will focus on only making the 'In tree' neutron code functional.
16:11:40 <Sam-I-Am> mmkay
16:13:21 * Sam-I-Am tap tap is this thing on?
16:13:48 <cloudnull> next #link https://review.openstack.org/#/c/181544/
16:14:07 <Sam-I-Am> yeah
16:14:08 <cloudnull> it would be great to get some more people to chime in on this.
16:14:38 <Sam-I-Am> maybe we need a config linter?
16:15:06 <cloudnull> this is probably something that we should look into
16:15:10 <sigmavirus24> Sam-I-Am: you write the spec, I'll write the linter
16:15:14 <sigmavirus24> It's already 90% done anyway
16:15:17 <cloudnull> i think sigmavirus24 did that
16:15:19 <cloudnull> ++
16:15:21 <cloudnull> :)
16:15:24 <sigmavirus24> github.com/sigmavirus24/schema-validator
16:15:41 <sigmavirus24> #link https://github.com/sigmavirus24/schema-validator
16:15:42 <Sam-I-Am> oh, well there you go
16:15:51 <sigmavirus24> needs osad integration though
16:15:52 <sigmavirus24> =P
16:15:54 <Sam-I-Am> so now whats this thing about a config scheme?
16:15:56 <Sam-I-Am> schema
16:15:56 <sigmavirus24> and someone to maintain things
16:16:02 <Sam-I-Am> hughs comment
16:16:13 <cloudnull> so i think we can expand upon that and make part of our process.
16:16:48 <cloudnull> i dont think OSAD needs to carry the repo, those bits can live on PyPi and and OSAD can consume them
16:16:58 <Sam-I-Am> this works
16:17:01 <hughsaunders> sigmavirus24++
16:17:08 <Sam-I-Am> hughsaunders: there you are
16:17:33 <sigmavirus24> cloudnull: yep, that was my understanding of how it would work too
16:17:51 <stevelle> even better, we get free lifetime support if we import it from Pypi
16:18:29 <Sam-I-Am> haha
16:18:34 <Sam-I-Am> sigmavirus24: are you core on that?
16:19:00 <Sam-I-Am> hughsaunders: so does this linter address your comment?
16:19:08 <Sam-I-Am> i can update the spec to include the linter
16:20:19 <cloudnull> i agree with others that the linter process should be a spec on its own.
16:20:19 <hughsaunders> Sam-I-Am: if sigmavirus24 has figured out how to do a linter/validator in a DRY & maintainable way
16:20:27 <hughsaunders> yep
16:20:34 <Sam-I-Am> we cant have a wet linter?
16:20:44 <sigmavirus24> hughsaunders: but wet linters are faster
16:20:52 <Sam-I-Am> does my spec become dependent on the linter spec?
16:20:56 <cloudnull> yes
16:20:57 <sigmavirus24> hughsaunders: and yeah, schema-validator just needs a schema to validate against
16:20:58 <cloudnull> imo
16:21:46 <sigmavirus24> hughsaunders: in other words, someone needs to maintain a schema so that the validator knows what belongs in the config file and what does
16:21:55 <sigmavirus24> it can be simple exclusion/inclusion or it can be more
16:22:00 <sigmavirus24> because jsonschema is powerful that way
16:22:10 <sigmavirus24> we can shave that yak when Sam-I-Am writes that spec
16:22:41 <cloudnull> kk
16:22:57 <cloudnull> next
16:22:59 <cloudnull> #LINK https://review.openstack.org/#/c/168976/
16:23:09 <cloudnull> can we kill this one off.
16:23:24 <cloudnull> or is it something that people are wantng to still do / see?
16:24:23 <Sam-I-Am> hmmm
16:24:29 <Sam-I-Am> is there still value for it?
16:24:44 <Sam-I-Am> having a standard way to tune things is better than a bunch of one-offs?
16:25:16 <Sam-I-Am> maybe the linter is helpful here too
16:26:20 <cloudnull> maybe
16:26:36 <cloudnull> so im abandoning that spec. unless someone gives me a reason not to
16:26:48 <Sam-I-Am> there is no jesse here
16:26:59 <cloudnull> silence is acceptance. . .
16:27:29 <cloudnull> lastly https://review.openstack.org/#/c/181955/
16:27:32 <cloudnull> #link https://review.openstack.org/#/c/181955/
16:27:59 <prometheanfire> I wanted to ask about providing a generic os support spec
16:28:10 <cloudnull> shoot
16:28:12 <prometheanfire> what methods do you think would work best for adding that (as a parrent spec)?
16:28:21 <prometheanfire> https://github.com/openstack-infra/bindep/ might help
16:28:26 <Sam-I-Am> yep, bindep
16:28:46 <cloudnull> just write the spec and update the gentoo specific one to be a dependent .
16:28:59 <cloudnull> then in LP you'll have to associate the two.
16:29:10 <prometheanfire> I don't think ansible has a generic package install function, just ones specific to distro (families)
16:29:33 <prometheanfire> cloudnull: got that part, it's implimentation details I wonder about :D
16:29:54 <cloudnull> this is correct.
16:29:59 <prometheanfire> think they have specifically avoided that
16:30:08 <cloudnull> so there will be conditional includes/vars
16:30:17 <cloudnull> based on facts
16:30:26 <prometheanfire> want to avoid that as much as possible is all
16:30:33 <prometheanfire> generic package spec would help
16:30:42 <prometheanfire> s/spec/functino
16:31:11 <cloudnull> i dont think theres a way to generically proxy commands to a ansible module. however that would be an interesting module upstream to write
16:31:15 <prometheanfire> it's something I'll look into
16:31:37 <prometheanfire> won't have the spec ready next week (gone), but will for the week after
16:31:52 <cloudnull> the truth is the package names themself will be different across distros which
16:31:59 <cloudnull> will intail optional includes.
16:32:03 <prometheanfire> cloudnull: use bindep for that
16:32:13 <prometheanfire> to source the package lists
16:32:29 <cloudnull> bindep produceses a flat requirement file with package lists.
16:32:43 <cloudnull> so there will be some additional logic that goes into making that work
16:32:56 <cloudnull> but yes bindep is key to multi distro
16:33:09 <prometheanfire> thought it provided mapping from generic package name to distro package name
16:33:41 <cloudnull> so lets move on.
16:33:45 <cloudnull> #topic Bugs
16:33:46 <prometheanfire> ya
16:34:03 <cloudnull> do we have any bugs that we need to call out or otherwise need people on ?
16:34:36 <cloudnull> we have the following high priority items that we should be looking at crushing https://bugs.launchpad.net/openstack-ansible/+bugs?search=Search&field.importance=High&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
16:34:41 <cloudnull> #LINK https://bugs.launchpad.net/openstack-ansible/+bugs?search=Search&field.importance=High&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
16:35:47 <cloudnull> if we could just get a few more eyes on those it would be great!
16:36:07 <cloudnull> #topic Open discussion
16:36:25 <cloudnull> anything else we want to talk about  ?
16:36:42 <cloudnull> with so few of us here i think we can wrap up if there's nothing us.
16:36:46 <cloudnull> *else
16:37:31 <cloudnull> it seems that people couldn't be bothered to come to the meeting today and or participate so i think we're done here.
16:37:43 <cloudnull> thanks everyone that showed up
16:37:44 <cloudnull> #endmeeting