16:00:27 <b3rnard0> #startmeeting OpenStack Ansible Meeting
16:00:35 <openstack> Meeting started Thu Apr 16 16:00:27 2015 UTC and is due to finish in 60 minutes.  The chair is b3rnard0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:49 <b3rnard0> #chair cloudnull
16:00:50 <openstack> Current chairs: b3rnard0 cloudnull
16:00:53 <b3rnard0> #topic Agenda & rollcall
16:01:03 <b3rnard0> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:04 <palendae> o/
16:01:17 <b3rnard0> presente
16:01:19 <stevelle> o/
16:01:28 <alextricity> hello
16:01:33 <Sam-I-Am> hi
16:01:45 <cloudnull> hi
16:02:08 <svg> o/
16:02:30 <b3rnard0> cloudnull: not a lot on the agenda besides palendae open discussion item. anything you want to prioritize for this meeting?
16:02:58 <cloudnull> no. we're full steam ahead on kilo
16:03:20 <cloudnull> i'd like alextricity to talk a bit about his BP (if he wants to).
16:03:25 <Sam-I-Am> warp 9, sir
16:03:31 <odyssey4me> o/
16:03:36 <alextricity> cloudnull. That would be cool. thanks
16:03:43 <cloudnull> otherwise lets open up to general discussion.
16:03:52 <cloudnull> alextricity: you have the mic.
16:04:07 <alextricity> There are a couple of items that i'm still wrestling with
16:04:17 <alextricity> 1. Mongodb gate tests
16:04:18 <b3rnard0> #topic Blueprints
16:04:23 <rromans> o/
16:04:35 <d34dh0r53> down in front
16:04:36 <alextricity> 2. configuration of ceilometer across different projects
16:05:11 <alextricity> regarding #1, i found an ansible galaxy role to deploy a simple mongodb server
16:05:14 <alextricity> and I mean SIMPLE
16:05:28 <alextricity> Let me pull up the link..
16:05:29 <alextricity> mom
16:06:07 <alextricity> https://github.com/UnderGreen/ansible-role-mongodb
16:06:31 <b3rnard0> #link https://github.com/UnderGreen/ansible-role-mongodb
16:06:42 <alextricity> I would like somebody else to take a look ( preferably someone with mongo experience)
16:07:09 <alextricity> I was thinking we could add that role as part of a gate script
16:07:19 <alextricity> do the necessary things to build the ceilo database
16:07:24 <alextricity> and test against that
16:07:30 <alextricity> What do you guys think?
16:07:49 * cloudnull looking at the role.
16:08:11 <cloudnull> as for the gate job, we could pull that in for testing of ceilometer.
16:09:02 <cloudnull> it would need to be something that was added to the gate scripts to do that.
16:09:04 <odyssey4me> I would think that perhaps ceilometer should rather be tested using multinode tests via external-CI
16:09:07 <alextricity> Definitely, how much do you think we should test though? e.g. do you think we should test replication sets..etc.
16:09:20 <odyssey4me> as it stands right now the AIO is heavily overcommitted
16:09:56 <alextricity> odyssey4me: are you saying make a separate gate script for these tests?
16:10:01 <cloudnull> odyssey4me: this is fair. the AIO is under load , but i think with the recent changes in config we can do a bit more. and ceilometer is a core OS project.
16:10:27 <cloudnull> maybe we tune the affinity down
16:10:32 <andymccr> i think we should be careful not to create a second class citizen there.
16:10:37 <cloudnull> and make the multi node gate required and voting.
16:10:51 <odyssey4me> cloudnull perhaps, but then I'd suggest not including it in the commit check until it's been in the project for a while
16:11:39 <alextricity> How does one go about making a multi-node gate?
16:11:51 <Sam-I-Am> we have one
16:11:57 <odyssey4me> and yes, multi-node gate vote enablement is an important target to ensure that it doesn't become a second class citizen as andymccr has highlighted
16:12:01 <alextricity> I'm not too familiar with that process, forgive my dump questions xD
16:12:16 <Sam-I-Am> alextricity: its one of those things you should avoid :)
16:12:17 <alextricity> s/dump/dumb
16:12:17 <andymccr> well i meant more that ceilometer is either in or not in, and not like a "its in, but we dont like it as much as the others"
16:12:25 <andymccr> but yeh multinode should get added :D
16:12:46 <cloudnull> +1 andymccr
16:13:26 <odyssey4me> andymccr agreed, but we also need to be aware of the resource limitations available in the openstack-infra instances - 8GB RAM doesn't get you very far
16:13:26 <cloudnull> i like the wip ceilometer role so far. and if its in then we need to treat as we would neutron, swift, nova.
16:13:29 <alextricity> what would the multinode gate look like? One AIO and a mongodb server?
16:13:54 <andymccr> this is true, we can only do what we can do - but i think its a slippery slope, do we start excluding heat also?
16:13:56 <odyssey4me> alextricity we have openstack-infra doing single instance gate checks
16:14:16 <cloudnull> this is the other things we can do , we may be able to leverage to OS ci gate to put infra parts on, IE galera, rabbit, mongo etc. .
16:14:20 <odyssey4me> alextricity we also have an external CI (jenkins, etc) which reacts to commits and other events and does a full 5 node build-out
16:14:21 <palendae> alextricity: We have some external-CI jobs that have groups of 5 nodes
16:14:31 <cloudnull> i mean as a multi-node OS CI
16:14:38 <alextricity> oh sweet
16:14:48 <alextricity> See..this is why i come to these meetings
16:14:55 <alextricity> learn cool things
16:14:56 <odyssey4me> cloudnull yes, there is precedence for a two node openstack-infra gate check
16:15:20 <odyssey4me> we may wish to start that as an experimental or periodic job, then graduate it to a commit check later
16:15:37 <cloudnull> i'd good with that
16:15:37 <stevelle> that sounds promising odyssey4me
16:16:08 <alextricity> odyssey4me: are you a good person to bug about things related gate?
16:16:09 <palendae> Agreed, worth a try, then integrate slowly
16:16:58 <cloudnull> so back to the question of testing mongo,
16:17:14 <odyssey4me> alextricity most of us have worked with the gate to some degree - I'm happy to assist, but hughsaunders is probably better suited to handle queries regarding the RPC External CI.
16:17:24 <cloudnull> if we add the role incldue as part of the gate process, then i think we can stay away from having a build mongo role.
16:17:32 <alextricity> odyssey4me. Awesome.Thank you
16:17:39 <hughsaunders> mongo wut
16:17:42 <alextricity> cloudnull: for sure
16:17:56 <alextricity> That was the goal of going out and searching for a galaxy role
16:18:19 <cloudnull> hughsaunders mongo for ceilometer.
16:18:20 <alextricity> I'll need to do more testing with the role i sent, but I think it will suffice
16:18:23 <odyssey4me> cloudnull yeah, it would be great to start consuming external roles - although we should edit the ansible bootstrap script to download the roles outside of the os-ansible-deployment directory tree
16:18:23 <alextricity> it's "good enough"
16:18:36 <cloudnull> odyssey4me +1
16:18:51 <palendae> odyssey4me: Separate from the ansible-role-requirements.yml file?
16:19:05 <palendae> That's currently where 3rd party roles would go
16:19:21 <palendae> Or we could make a gate-ansible-role-requirements.yml file
16:19:24 <odyssey4me> palendae right now when bootstrap-ansible.sh downloads the external roles, it puts them into the os-ansible-deployment/playbooks/roles directory
16:19:44 <odyssey4me> that dirties the git tree there, causing support issues
16:19:48 <cloudnull> palendae yea, the roles in that file, at present, install in the main repo's role path. we can use that to store it in the ansible namespace at /etc/ansible/roles so that it doesnt impact upgrades.
16:19:56 <palendae> Oh, I see what you're saying
16:20:00 <odyssey4me> ^ what he said :)
16:20:08 <palendae> Yeah, that makes sense
16:20:18 <alextricity> Is that so people don't confuse the mongo role to be part of OSAD?
16:20:26 <cloudnull> yes
16:20:34 <alextricity> +1 to that
16:21:06 * hughsaunders has caught up
16:21:07 <alextricity> So..the #2 item
16:21:21 <alextricity> about configuring ceilometer bits on other projects
16:21:51 <Sam-I-Am> i think we already configure a lot of that stuff
16:21:54 <Sam-I-Am> for MaaS
16:22:04 <Sam-I-Am> at least notifications, and swifty things
16:22:04 <alextricity> Right now I've added the "ceilometer_measured_services" list to user_variables. That way users can choose which services they want to measure
16:22:13 <hughsaunders> the way the multi node gate is setup, it should be fairly straight forward to add an optional mongo-prep step that is outside of OSAD (can be jenkins-rpc or external)
16:22:42 <alextricity> https://review.openstack.org/#/c/173067/6/etc/openstack_deploy/user_variables.yml
16:23:21 <alextricity> I was thinking we could turn on/off the ceilometer bits on other projects depending on if the project is listed there
16:23:28 <b3rnard0> #link https://review.openstack.org/#/c/173067/6/etc/openstack_deploy/user_variables.yml
16:23:33 <cloudnull> an aside, odyssey4me  i think we need to rename all of our ansible files to .AIO or something so that people are not doing the blind copy and getting things they dont expect.
16:24:02 <cloudnull> we talked about this before. but  it just popped back into my head.
16:24:06 <odyssey4me> alextricity why not have each of the openstack projects have a variable to enable/disable ceilometer - then add whatever configs are required for each project into their roles
16:24:22 <cloudnull> example files in etc/openstack_deploy/
16:24:38 <Sam-I-Am> cloudnull: yes, this is important
16:24:50 <Sam-I-Am> cloudnull: sort of fell by the wayside
16:25:05 <alextricity> odyssey4me: Okay. Like a "ceilometer_enabled = True|False" variable in the default/main.yml
16:25:09 <odyssey4me> cloudnull agreed - thought about that a while back... try to stick to the convention of .example, .aio and perhaps others where applicable
16:25:15 <Sam-I-Am> we need .example and .aio, with no useable default fle
16:25:28 <Sam-I-Am> so people have to do "something" to make it work
16:25:29 <odyssey4me> Sam-I-Am +2
16:25:35 <cloudnull> +1 . sorry , side tracked. .. .
16:26:09 <odyssey4me> alextricity yes, then ideally the ceilometer role can simply use those values to determine which services should be monitored
16:26:58 <odyssey4me> this is assuming that each openstack service requires some sort of configuration for ceilometer before it works?
16:27:14 <odyssey4me> it's been a long time since I looked at ceilometer, so forgive my ignorance
16:27:17 <alextricity> Most, but not all
16:28:17 <alextricity> I've been using this guide to help me out
16:28:17 <alextricity> http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-controller-install.html
16:28:30 <b3rnard0> #link http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-controller-install.html
16:29:04 <alextricity> For the compute service, you need to add "instance_usage_audit", "instance_usage_audit_period", "notify_on_state_change"..etc
16:29:38 <alextricity> There are some extra configs for glance, swift, and cinder as well
16:31:08 <alextricity> I'll try having that boolean variable in the default/main.yml of each project. I'll keep you guys posted
16:31:16 <odyssey4me> well, then each role will have to have some bits for that configuration
16:31:38 <alextricity> odyssey4me. Right I still need to add those in.
16:32:28 <alextricity> cloudnull: That's all I had if you guys want to continue
16:32:39 <alextricity> thanks for everything :) You guys rock
16:32:50 <odyssey4me> other than that, I'd expect that you can move some/most/all of the environment file changes into etc/openstack_deploy/env.d
16:33:01 <cloudnull> sweet! thank you for working on this alextricity !
16:33:13 <odyssey4me> that's optional though, I just think that perhaps we should start to use that convention more
16:33:22 <cloudnull> +1 to what odyssey4me about env.d
16:33:32 <alextricity> for sure. I'll do that on the next patch set
16:34:16 <odyssey4me> cloudnull on another note, we probably need to figure out a way to do something similar for haproxy
16:34:26 <andymccr> +1
16:34:43 <cloudnull> haproxy into conf.d makes sense to me
16:34:48 <andymccr> i know its not "production" but we should make it more modular
16:34:51 <andymccr> and adaptable
16:35:47 <odyssey4me> cloudnull yeah, but right now we have no way of simply adding an extra LB without having to redefine all the LB's again
16:36:23 <odyssey4me> similar issue to the tunables issue, so it could be solved with the copy_update plugin when that goes in, but perhaps there are other ways
16:37:23 <cloudnull> so can we get some more reviews on that review
16:37:30 <cloudnull> and if its all good lets make it go
16:37:55 <b3rnard0> any more blueprints to discuss?
16:38:30 <sacharya> i am around if you have any questions on the copy_update plugin #link https://review.openstack.org/#/c/168104/
16:38:31 <cloudnull> #topic Open discussion
16:38:50 <cloudnull> boom, the man the myth the legend .
16:39:03 <cloudnull> :)
16:39:43 <odyssey4me> sacharya good work there, sorry that we haven't managed to review it much - been busy getting Kilo done right
16:39:43 <sacharya> ;)
16:40:40 <odyssey4me> If you could possibly update/rebase the keystone part of it once we have a kilo branch that'd make life quite a bit easier for the review.
16:41:38 <sacharya> i'll do that
16:42:39 <sacharya> i will also send another review for all other policy.jsons to use the copy_update
16:43:03 <b3rnard0> also in the open discussion agenda
16:43:09 <b3rnard0> #info How is copyright handled on code in os-ansible-deployment? — palendae
16:43:26 <odyssey4me> sacharya that would be great
16:43:39 <palendae> Yeah, so - I notice a lot of our files have the Rackspace copyright, since most of us right now are writing os-a-d at Rackspace
16:43:55 <palendae> However, I'm mostly curious about answering how that assignment works from someone outside RAX
16:44:05 <palendae> Would they assign it to whoever they work for and we merge it?
16:44:47 <palendae> Here's soem reference on that for the OpenStack projects - https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers
16:45:50 <palendae> I take that silence to mean no one knows :)
16:45:53 <odyssey4me> as I recall, although it's been a while since I checked up on all this, whoever writes the file has a right to put the notice there with their name - this assumes that their contribution is substantive I guess
16:46:21 <palendae> odyssey4me: That link I just dropped made it sound like the headers aren't strictly necessary for OS contributions
16:46:26 <odyssey4me> in the openstack namespace I think they have a rule that only the foundation can be in the copyright statement
16:46:56 <palendae> "Copyright notices are not required in order to create or protect your copyright rights, but they may nonetheless be useful."
16:47:08 <odyssey4me> ultimately I believe that when it comes to actually enforcing copyright in law the commit history would come into play, so the notice in the file itself is fairly meaningless
16:47:19 <palendae> Yeah, I think that's the newer thing - if you write it for OpenStack, it should be foundation
16:47:21 <palendae> If you use it
16:47:28 <Apsu> palendae: That's because you have automatic copyright upon creating a work. At least in the USA.
16:47:34 <palendae> Apsu: Yeah
16:47:43 <Apsu> Licensing is a way to specifically assign, divide or relinquish some of your copyright.
16:47:52 <odyssey4me> yup - so it comes down to the license being important just to be explicit
16:48:01 <Apsu> So a license isn't explicitly needed but it does reduce confusion with regards to your wishes
16:48:07 <cloudnull> all of the OS projects do something similar https://github.com/openstack/nova/blob/master/nova/cmd/api_os_compute.py
16:48:22 <Apsu> As well as potentially enforcing stipulations, such as in the case of assertive licenses like the GPL
16:48:26 <palendae> cloudnull: That's 2010, but ok
16:48:30 <palendae> Just checking
16:48:31 <b3rnard0> #link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers
16:48:40 <palendae> Like, there's no need to clean them up
16:48:41 <b3rnard0> #link https://github.com/openstack/nova/blob/master/nova/cmd/api_os_compute.py
16:48:59 <palendae> So, if someone outside RAX commits they'd drop their own header and it's cool
16:49:06 <palendae> ?
16:49:14 <palendae> drop in*
16:49:21 <palendae> On their file
16:49:22 <cloudnull> https://github.com/openstack/magnum/blob/master/magnum/common/clients.py
16:49:32 <Apsu> They wouldn't be able to drop their own FOSS license header if it's incompatible with the project licensing
16:49:42 <Apsu> But they could attribute the work as being copyrighted by them.
16:49:43 <palendae> Apsu: Assuming they're following the license
16:49:49 <cloudnull> palendae on that file yes. if they created it
16:49:54 <palendae> I'm not talking the license, I'm talking the copyright
16:49:56 <palendae> Ok
16:50:08 <palendae> Ok
16:50:09 <Apsu> Yeah. Just wanting to make sure it's clear to all that we're distinguishing
16:50:17 <Apsu> The file cloudnull just linked has both :)
16:50:30 <palendae> Yeah, I'm operatng under the assumpting they're putting it under our license, no messy stuff
16:50:35 <Apsu> Cool.
16:50:35 <palendae> assumption
16:51:11 <Apsu> Then yeah, copyrighting to yourself is good and common, to trace attribution histories and avoid confusion in the event we need to contact or request transfer/etc
16:51:12 <palendae> My question's answered then - new contributors would put their copyright on new files contributed
16:51:30 <odyssey4me> palendae correct
16:51:47 <palendae> Thanks
16:52:36 <b3rnard0> #info My question's answered then - new contributors would put their copyright on new files contributed
16:53:13 <b3rnard0> Anything else? Going once...
16:53:50 <Sam-I-Am> crickets
16:53:54 <b3rnard0> Going twice
16:53:56 <cloudnull> ok so we're done here. :)
16:54:00 <Sam-I-Am> moar crickets
16:54:09 <b3rnard0> #endmeeting