16:03:56 #startmeeting OpenStack Ansible Meeting 16:03:57 Meeting started Thu Apr 23 16:03:56 2015 UTC and is due to finish in 60 minutes. The chair is b3rnard0. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:04:01 The meeting name has been set to 'openstack_ansible_meeting' 16:04:18 #chair cloudnull 16:04:19 Current chairs: b3rnard0 cloudnull 16:04:31 #topic Agenda & rollcall 16:04:38 hi 16:04:39 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:04:43 o/ 16:04:47 howdy 16:05:38 o/ 16:05:42 howdy 16:06:08 o/ 16:06:35 presente 16:07:27 we have no action items from last week. do we want to dive into blueprints? 16:07:48 lets wait a min more. 16:07:55 for people to join in 16:09:14 i think people melted 16:09:35 ok. so lets go. 16:09:50 #topic Blueprints 16:10:09 https://blueprints.launchpad.net/openstack-ansible/+spec/build-facts-archive 16:10:20 ^ is jwagner around ? 16:10:23 here 16:10:36 #link https://blueprints.launchpad.net/openstack-ansible/+spec/build-facts-archive 16:10:51 never doen one of these meeting so... 16:10:55 do i just explain it? 16:10:58 done* 16:11:06 I think that's a valuable addition. I would like to see maybe a little more detail about where that info is stored 16:11:46 jwagner: walk us through it briefly 16:12:26 i was imagining on the deployment host under /opt or something in a dir stucture of /opt/osad-archive/{hostname}/[archived-bits] 16:12:32 then tar it up 16:12:34 etc 16:12:47 jwagner: So a set of yaml files? 16:12:58 Or a text dump of facter's info? 16:13:42 I think most of this is available via ansible facts, which can be run once and you'll get a report of all hosts in the inventory. 16:14:07 d34dh0r53 yes that is probably how we could get most of this info 16:14:32 I know there have been requests to get this information into a database for deployer support personnel 16:14:37 my man concern and need was the ability to parse all this info and grab bits and pieces that we need to report bugs in a more readable and accessable fashion to you guys 16:14:48 also to be able to aggregate the tempest test results up to jenkins 16:15:25 when you say things like 'cinder config' do you mean the host-level stuff, the openstack config, or the actual volumes/usage/etc ? 16:15:37 currently I cannot get to the results due to the fact that our ansible plays has no info about the inventory so getting to the utility container that has the xml from the tempest run is pretty janky 16:15:39 jwagner can you reformat/submit the spec this the spec repo using this template https://github.com/stackforge/os-ansible-deployment-specs/blob/master/specs/template.rst 16:15:51 some of this stuff is facts, but some of it is the result of slurping config files or API calls 16:16:28 cloudnull can do 16:17:16 tyvm 16:18:08 #action jwagner -- can you reformat/submit the spec this the spec repo using this template https://github.com/stackforge/os-ansible-deployment-specs/blob/master/specs/template.rst 16:19:55 okay, any other blueprints for discussion? 16:20:17 palendae's blueprint? 16:20:20 Can you guys check out the ceilometer bp spec when you get the chance? 16:20:25 It's not approved yet 16:20:45 #link https://review.openstack.org/#/c/169417/ 16:21:10 alextrcitiy my only issue with that spec is that we've not defined how testing will be done with mongo. 16:21:47 I know we touched on this in past meetings 16:22:02 Something like we were going to install Mongo as part of the gating? 16:22:09 i think that if we deploy mongo via a gate script for the test case im happy. if we bring mongo as a role in im dubious. 16:22:16 cloudnull: That's right. Are you looking for more description in the testing section? 16:22:21 i am 16:22:31 Okay sounds good 16:22:33 cloudnull: Do you mean bring in an ansible galaxy role to do mongo gating? 16:22:36 Or via bash? 16:22:49 Or do you not care as long as it's not a role that gets installed everywhere 16:23:05 either or, i just dont want the external role to be brought into the system. 16:23:24 which will only create confusion when people look to deploy ceilometer. 16:23:27 Right 16:24:10 So, are you against including any galaxy roles in our install then? 16:24:13 if we do bring in mongo as a role we support then it needs to be scalable. 16:24:30 If so, we need to look at modifying the bootstrap ansible role to take that out 16:24:40 And move it to a deployer-level solution 16:24:55 bootstrap ansible script* 16:25:42 +1 16:26:09 but in terms of the spec for ceilometer the only thing im concerned with is how is it tested. 16:26:14 Ok 16:26:19 Gotcha 16:26:53 so if we can get a test case into the spec im +2 16:27:14 you "can" deploy ceilometer with mysql though right? 16:27:24 i mean i know its not great in prod but for testing purposes/gating etc? 16:27:48 andymccr you "can" but it wont work in horizon . 16:27:58 oh ok so no go even just for testing? :( 16:27:59 andymccr: guess we'd need to test the whole mariadb installation mechanism in the gate to ensure that code path works 16:28:03 Are we testing it in horizon? 16:28:05 *mongodb 16:28:13 they have a "raise exception" on all things meta query 16:28:38 and meta query is only supported when using mongo 16:29:27 i'd have to look at what tempest tests in terms of ceilometer, but if it calls something that does a meta query it would be a no go. 16:29:55 Does horizon have integration tests to ceilometer taht we should exercise? 16:30:24 doesn't look it palendae 16:30:24 palendae no, but if it was deployed for testing using the AIO and wanted to see it working or tool around with it we'd run into problems. 16:30:56 its also a completely different code path/driver within ceilometer. 16:31:33 ^ makes me think that testing w/ mysql would not be a valid test 16:31:59 Right 16:32:15 but thats a difference between testing that ceilometer deployed and testing ceilometer itself right? 16:32:22 like surely its ceilometers job to test the codepath with mongo 16:32:22 we could get it in using mysql, it would just not be wants really used with its deployed; should someone choose to deploy it in prod. which is kinda against what / how we've tested all of the other openstacky things . 16:33:09 i agree with that, im just thinking if mongo getting in is a harder task as a first step it isnt a bad one, but its a non-event if the tests wont ever pass based on the meta query issue. 16:33:10 but for the purpose of the spec it might be ok. 16:33:19 It's close to how we've tested networking - neutron doesn't cover tests with the linuxbridge code path right now 16:33:21 At least not in scenarios 16:33:50 palendae thats true but we're exercising it using other scenarios . 16:33:53 I think i'll just make a gate script that deploys a simple mongodb server with ceilometer. Then use that mongo server to test ceilometer 16:34:12 Yes 16:34:19 that simple gate script could use the galaxy role previously identified. 16:34:30 ^ that im good with 16:34:44 Cool. I'll add that to the bp 16:36:06 thanks alextrcitiy 16:36:29 Sam-I-Am palendae https://review.openstack.org/#/c/173155/ 16:36:48 Yeah, I need to update that with suggestions people have made 16:37:10 I do have some CRs related to it, but I'd like to do those slowly - first get in the directory with the sphinx config/make file, then build on that 16:37:40 +1 16:38:02 I have a first draft of a playbooks overview, too 16:39:15 palendae: wooo docs 16:39:16 So, not really much to add to that right now 16:39:30 Sam-I-Am: And docs that *we* should be writing 16:39:39 Not "here's code write about it" 16:39:50 yeah. there will be some discussion about this on tuesday i think. 16:40:07 part of the overall "how do we get all the docs upstream" 16:40:25 My goal with this is not all the docs, btw 16:40:25 nice 16:40:37 palendae: er? 16:40:38 But mostly for someone contributing to osad to get up to speed 16:40:49 This specific BP 16:40:56 yes 16:41:05 but docs people might be touching this stuff 16:41:06 There's still room for deployer docs 16:41:10 Yes, true 16:41:17 diagrams, after all :) 16:41:50 https://github.com/stackforge/os-ansible-deployment/blob/master/development-stack.rst#diagram-of-stack < best diagram ever! 16:42:08 cloudnull: until i make it better :) 16:42:26 needs more emoji 16:42:30 That's a fantastic diagram. 16:42:37 So i think that we can close out on this one https://review.openstack.org/#/c/168976/ as it is 16:42:52 Needs some libaa or libcaca to render it 16:43:17 cloudnull: close out? 16:43:18 the policy copy mechanism is in place and we can build on that to make that spec more supported / capable. 16:43:26 +1 16:43:31 Superseded 16:43:36 ^ that one. 16:43:41 ahh 16:43:58 Policy copying done, what we need next is ini updating 16:44:07 yup 16:44:19 we should look at creating a new spec for that extension . 16:45:21 ok, well ill do that . 16:45:39 #action item cloudnull create a new spec to extend copy_update module. 16:46:19 #topic Open discussion 16:46:40 open up the festivus ! 16:47:07 Does anyone know if our gate job has to inlcude 'dsvm' in it? 16:47:22 http://festivusweb.com/images/seinfeld-festivusjpg.jpg 16:47:31 os-ansible-deployment-dsvm-check-commit 16:47:35 palendae no, we could take the name out i think 16:47:36 From what I gather 16:47:41 dsvm is DevStack VM 16:47:49 Which is inaccurate in our case 16:48:04 the idea is the same though (an AIO with core services in it) 16:48:09 Right 16:48:10 thats something we can update/change in project config 16:48:10 we should just use devstack 16:48:16 It's just not devstack 16:48:19 ==Sam-I-Am 16:48:28 then everything would work 16:48:30 cloudnull: Yeah, I wanted to ask before I put a PR in for that 16:48:31 # /kick Sam-I-Am 16:48:55 :) 16:48:57 * Sam-I-Am feels loved 16:49:00 We are doing the same thing, but it's not devstack (nor a VM, I don't think), so it's misleading 16:49:00 palendae that should be fine 16:49:10 you want to go bang that out ? 16:49:16 Yeah 16:49:19 palendae: you go and bug infra about it 16:49:35 sigmavirus24: I will 16:49:37 #action palendae to fix our gating name. 16:50:30 who wants the fetivus pole next ? 16:50:30 Bjoern__ where you be ? 16:50:30 :) 16:51:42 so are we done here? 16:52:10 perhaps 16:52:14 i think so :) 16:52:15 kill it 16:52:19 #endmeeting