16:00:09 <b3rnard0> #startmeeting OpenStack Ansible Meeting
16:00:10 <openstack> Meeting started Thu Apr  9 16:00:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:26 <b3rnard0> #chair cloudnull
16:00:27 <openstack> Current chairs: b3rnard0 cloudnull
16:00:37 <b3rnard0> #topic Agenda & rollcall
16:00:47 <b3rnard0> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:03 <cloudnull> o/
16:01:10 <b3rnard0> presente
16:01:10 <d34dh0r53> @'
16:01:47 <Sam-I-Am> hi
16:02:02 <BjoernT> Hi
16:03:03 <andymccr> hi
16:03:24 <b3rnard0> i didn't see any action items from last week. anything we want to discuss action items wise?
16:04:02 <BjoernT> I guess one action item would be starting the blueprint around EC2 and S3 api support  in juno
16:05:00 <cloudnull> BjoernT do you have one ready for review ?
16:05:06 <odyssey4me> uh BjoernT I'm confused - juno already has s3/ec2 api support as good as it gets
16:05:28 <BjoernT> s3 middleware is missing in osad
16:05:39 <cloudnull> BjoernT are you talking about swift3?
16:05:42 <BjoernT> ec2 works if we fix keystone_es2_url
16:05:52 <BjoernT> right swift3
16:06:39 <cloudnull> IE https://github.com/stackforge/swift3
16:07:54 <odyssey4me> hmm, so for kilo+ we'd probably have to include s3/ec2 support from outside the standard swift/nova trees - that's a whole different ball-game
16:08:20 <odyssey4me> doable if the resource allocation is worth the effort
16:09:45 <b3rnard0> let's get through the rest of the agenda before we go down this rabbit hole
16:09:54 <BjoernT> yes
16:10:06 <b3rnard0> cloudnull: do we want to talk blueprints?
16:10:33 <cloudnull> sure
16:10:52 <b3rnard0> #topic Blueprints
16:11:01 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/implement-ceilometer
16:11:20 <cloudnull> the one in progress is for ceilometer. alex is gone for the week so he's not here to talk about progress on that at this time.
16:11:44 <cloudnull> odyssey4me: we also have https://review.openstack.org/#/c/168976/
16:11:50 <odyssey4me> any chance we can scratch the details from launchpad?
16:12:01 <odyssey4me> leave the detail in the spec and only the summary in launchpad
16:13:08 <cloudnull> whats that ?
16:13:30 <odyssey4me> the ceilometer blueprint - it has all the details in both launchpad and the submitted spec
16:13:46 <odyssey4me> it's just very verbose
16:13:57 <odyssey4me> no matter - re: https://blueprints.launchpad.net/openstack-ansible/+spec/tunable-openstack-configuration
16:14:33 <cloudnull> ah yes we can pair that down
16:15:10 <cloudnull> http://docs-draft.openstack.org/76/168976/1/check/gate-os-ansible-deployment-specs-docs/845ff17//doc/build/html/specs/kilo/tunable-openstack-configuration.html
16:16:50 <odyssey4me> I have implemented a PoC in a review which seems to have disappeared which is a WIP, but illustrates the basic point and is covered in the complementary spec in https://review.openstack.org/168976
16:17:40 <odyssey4me> cloudnull fed back that the dict merge approach taken is less friendly, predictable and maintainable than the approach in https://review.openstack.org/168104
16:18:14 <odyssey4me> I have yet to look into that in detail. My time's focused elsewhere and until I'm done with kilo-related commitments this will stall.
16:18:45 <odyssey4me> ah, there's the WIP (second page of reviews) :o https://review.openstack.org/165683
16:19:25 <cloudnull> ok so lets table this for now.
16:19:31 <odyssey4me> I'm game for the alternative method, it's just a matter of time and priority right now.
16:19:59 <odyssey4me> if someone wants to do the analysis and patch the spec and do a test review then that'd be great.
16:20:25 <odyssey4me> I think we all agree on the objective, it's only the method in question.
16:21:04 <cloudnull> so does anyone here have cycles and want to run with that for now?
16:22:10 <cloudnull> ok then.
16:22:15 <cloudnull> :)
16:22:31 <cloudnull> so on the topic of blueprints BjoernT : what say you?
16:23:12 <BjoernT> nah, no time, lol
16:23:51 <odyssey4me> minimal-kilo should probably be changed to implemented
16:24:00 <cloudnull> speak now or forever hold your piece.
16:24:18 <Sam-I-Am> woof
16:24:26 <odyssey4me> glance, heat, horizon kilofication should be superceded by master-kilofication?
16:24:58 <cloudnull> yes they should
16:25:28 <odyssey4me> it would seem to me that build-facts-archive and dynamic-inventory-lib could dovetail nicely
16:26:25 <odyssey4me> both, however, are a stretch in terms of the osad manifesto - which we have yet to get into the details of
16:26:27 <cloudnull> yes. that could probably go hand in hand
16:27:09 <odyssey4me> I think both are useful to deployers, but they stray from the idea of deploying openstack and go more into the realm of running ansible.
16:28:29 <cloudnull> this is true, however in the case of inventory i think that is essential to OSAD. and presently our inventory system works but it could be a whole lot better
16:28:55 <cloudnull> but itll be a bit of a balance
16:29:44 <odyssey4me> cloudnull I agree - the inventory library is on the perimeter and would add much value if we did that.
16:30:17 <odyssey4me> storing an inventory of what's out there, however, seems like a better fit for a deployer's CMDB which the library can consume
16:31:04 <cloudnull> +1
16:33:14 <cloudnull> so barring anything else on bp's b3rnard0  lets move on
16:33:38 <b3rnard0> next up
16:33:43 <b3rnard0> #topic Milestones
16:33:53 <b3rnard0> anything specific there to be discussed?
16:34:08 <b3rnard0> i know we still have 3 bugs outstanding for 10.1.3
16:34:08 <cloudnull> we're actively working on kilo
16:34:50 <odyssey4me> b3rnard0 which bugs?
16:35:12 <b3rnard0> #link https://launchpad.net/openstack-ansible/+milestone/10.1.3
16:35:17 <cloudnull> andymccr did the work for the glance / swift chunking https://bugs.launchpad.net/openstack-ansible/+bug/1436647
16:35:19 <openstack> Launchpad bug 1436647 in openstack-ansible trunk "Make chunk size configurable for swift-backed glance" [Medium,In progress] - Assigned to Andy McCrae (andrew-mccrae)
16:35:25 <cloudnull> and thats merged.
16:35:57 <odyssey4me> yup
16:36:24 <b3rnard0> how about https://bugs.launchpad.net/bugs/1438118
16:36:25 <openstack> Launchpad bug 1438118 in openstack-ansible juno "some v10 Juno playbooks containing a wrong host pattern" [Low,Triaged] - Assigned to Serge van Ginderachter (svg)
16:36:28 <odyssey4me> also merged
16:37:13 <cloudnull> svg worked on that and its merged.
16:37:22 <b3rnard0> last one is https://bugs.launchpad.net/bugs/1430872
16:37:23 <openstack> Launchpad bug 1430872 in openstack-ansible trunk "Add token dhcp_domain to dhcp_agent.ini template" [Medium,Confirmed] - Assigned to Jesse Pretorius (jesse-pretorius)
16:37:47 <b3rnard0> the listed status in the list is throwing me off :-P
16:37:47 <odyssey4me> ok, that's on me - I haven't had a chance to actively work on it
16:38:14 <b3rnard0> is that a hard requirement for 10.1.3 or can we push out to 10.1.4
16:38:32 <odyssey4me> I took a look a day or two ago and realised that it would involve a new template and a bit more than a simple nova.conf entry, so I pushed it out.
16:38:41 <odyssey4me> so yes, good question b3rnard0
16:39:02 <cloudnull> i think it should be a requirement for 10.1.3 its been an ask for a while now.
16:39:33 <cloudnull> looking at you BjoernT
16:39:43 <odyssey4me> it's not hard work, but it introduces a fair change to how dnsmasq is used and could put risk into the 10.1.3 release
16:39:59 <b3rnard0> if we've committed to doing a 10.1.3 release tomorrow, is that still doable or can we get another volunteer, err, active contributor
16:40:12 <odyssey4me> I would recommend shifting it with my apologies - I can prep the change, but we should hold it until after 10.1.3
16:40:41 <cloudnull> ok. lets push it
16:40:52 <Sam-I-Am> push it real good?
16:40:58 <BjoernT> we patch it already manually so 10.1.3 is good
16:40:59 <cloudnull> done.
16:42:45 <cloudnull> so b3rnard0  moving on
16:43:08 <b3rnard0> okie dokie, anything else milestones wise or should we go to open discussion
16:43:32 <cloudnull> #topic Open discussion
16:43:40 <BjoernT> https://bugs.launchpad.net/openstack-ansible/+bug/1442239
16:43:40 <openstack> Launchpad bug 1442239 in openstack-ansible "Commit c5d488059d9407f1b9b96552159ffc298c8dc547 is invalidating sshd_config" [Undecided,New]
16:44:21 <b3rnard0> BjoernT: we have a couple of items on the agenda for open discussion. cloudnull, any of those that need to be discussed?
16:44:32 <BjoernT> ok
16:44:42 <odyssey4me> wow, I thought that was long gone - we had a bug about that ages ago
16:45:25 <cloudnull> * Do we have defined criteria for core team members? This would be useful to discuss prior to bringing more in. (palendae)
16:45:48 <b3rnard0> i believe palendae is at a conference
16:46:09 <cloudnull> true, but to address this we should be using https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
16:46:44 <odyssey4me> cloudnull I believe we've discussed that, although perhaps something should be added to the contributing file in the repo to clarify for the future?
16:47:09 <cloudnull> as for Reach agreement regarding osprofiler middleware across openstack services during Kilofication. Available: Yes/no and config strategy? (stevelle) - i think the decision was itll be available but disabled.
16:47:26 <cloudnull> odyssey4me maybe we add a point about that
16:47:48 <cloudnull> and the last one Clarify the meaning of the Triaged status and decide on how we are going to use that status. [1] - (d34dh0r53)
16:47:58 <cloudnull> d34dh0r53 ^
16:48:41 <d34dh0r53> ahh, didn't realize that was still on the agenda.
16:49:00 <odyssey4me> d34dh0r53 you cannot escape the agenda
16:50:27 <d34dh0r53> https://wiki.openstack.org/wiki/Bugs#Status according to this the triaged status should be used when "The bug comments contain a full analysis on how to properly fix the issue" which we are not really doing.  Just want clarification as to how we're using the Triaged status
16:50:56 <odyssey4me> I'm +1 on that definition.
16:51:08 <d34dh0r53> as am I
16:51:13 <cloudnull> +1
16:51:28 <cloudnull> so motion carries .
16:51:52 <d34dh0r53> so in our triage meeting we will set bugs to confirmed once they've had the once over (unless of course it contains the appropriate information)
16:51:55 <cloudnull> we should update the contributing with a brub on states
16:52:00 <b3rnard0> #info d34dh0r53: https://wiki.openstack.org/wiki/Bugs#Status according to this the triaged status should be used when "The bug comments contain a full analysis on how to properly fix the issue" which we are not really doing.  Just want clarification as to how we're using the Triaged status
16:52:22 <andymccr> yeh we should be confirming/invalidating bugs in triage meeting, not necessarily resolving them.
16:52:31 <andymccr> and prioritizing
16:52:34 <d34dh0r53> agreed
16:52:58 <cloudnull> so BjoernT back to your bug(s).
16:53:14 <BjoernT> i just have this shiny new one https://bugs.launchpad.net/openstack-ansible/+bug/1442239
16:53:15 <openstack> Launchpad bug 1442239 in openstack-ansible "Commit c5d488059d9407f1b9b96552159ffc298c8dc547 is invalidating sshd_config" [Undecided,New]
16:54:03 <odyssey4me> cloudnull agreed that we should add a blurb on the launchpad states and what they mean to us
16:54:36 <odyssey4me> we should also define the purpose of the two community meetings - it would help to focus them
16:55:26 <cloudnull> odyssey4me +1
16:55:39 <odyssey4me> on to that bug, this is kinda a duplicate of stuff we encountered ages back, eg: https://bugs.launchpad.net/openstack-ansible/+bug/1404343 and perhaps it's a duplication of https://bugs.launchpad.net/openstack-ansible/+bug/1416626
16:55:40 <openstack> Launchpad bug 1404343 in openstack-ansible trunk "External CI failures due to SSH issues" [High,Fix committed] - Assigned to Hugh Saunders (hughsaunders)
16:55:42 <openstack> Launchpad bug 1416626 in openstack-ansible trunk "invalid sshd_config entry after ssh_config.yml task runs" [Low,Confirmed] - Assigned to Miguel Grinberg (miguelgrinberg)
16:56:41 <odyssey4me> it may be a regression which we need to take care of, but it seems to me that https://bugs.launchpad.net/openstack-ansible/+bug/1442239 is a duplicate of https://bugs.launchpad.net/openstack-ansible/+bug/1416626
16:56:42 <openstack> Launchpad bug 1442239 in openstack-ansible "Commit c5d488059d9407f1b9b96552159ffc298c8dc547 is invalidating sshd_config" [Undecided,New]
16:56:44 <openstack> Launchpad bug 1416626 in openstack-ansible trunk "invalid sshd_config entry after ssh_config.yml task runs" [Low,Confirmed] - Assigned to Miguel Grinberg (miguelgrinberg)
16:57:11 <BjoernT> 1404343 is the cause for 1416626 so not duplicate imho
16:58:25 <andymccr> 1416626 seems like the same thing.
16:58:31 <andymccr> so its a bug in the ansible module
16:59:15 <odyssey4me> as I recall, prior to the master refactor we actually did this in a patch - so we have a regression and need to bring if forward
17:00:05 <cloudnull> we are out of time. lets take this convo back to the channel and or the ML.
17:00:14 <BjoernT> andymccr: yes your are right
17:00:28 <cloudnull> thanks everyone
17:00:35 <cloudnull> #endmeeting