16:01:09 <cloudnull> #startmeeting OpenStack Ansible Meeting
16:01:09 <openstack> Meeting started Thu Aug 27 16:01:09 2015 UTC and is due to finish in 60 minutes.  The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:13 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:24 <cloudnull> that worked better.
16:01:28 <cloudnull> thank nikhil_k :)
16:01:31 <nikhil_k> :)
16:01:42 <cloudnull> #topic Agenda & rollcall
16:01:51 <cloudnull> who's all here?
16:02:19 <odyssey4me> o/
16:02:24 <d34dh0r53> o/
16:02:27 <Sam-I-Am> mooo.
16:02:36 <evrardjp> yop
16:02:43 <palendae> o/
16:02:48 <Apsu> o/
16:02:50 <serverascode> o/ (just listening in)
16:03:05 <cloudnull> #chair odyssey4me
16:03:06 <openstack> Current chairs: cloudnull odyssey4me
16:03:21 <cloudnull> o/ everybody :)
16:03:29 <cloudnull> ok lets get started we have a bit to cover today .
16:03:45 <cloudnull> #topic Liberty Release Blueprints (note dependencies)
16:03:49 <cloudnull> #link https://blueprints.launchpad.net/openstack-ansible/+spec/liberty
16:04:26 <cloudnull> three are quite a few des inflight right now.
16:04:57 <cloudnull> odyssey4me: you might have a better understanding of where we are at this right now..
16:05:11 <odyssey4me> yep, so we have some in flight
16:05:19 <odyssey4me> including
16:05:24 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/remove-upstream-repo-dependency
16:05:32 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/compartmentalize-rabbitmq
16:05:40 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/upgrade-mariadb-v10
16:05:56 <odyssey4me> then we have a spec for
16:05:57 <cloudnull> #link https://launchpad.net/openstack-ansible/+milestone/liberty-3 # issues in progress as well for lib-3
16:06:01 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/liberty-upgrade-path
16:06:39 <odyssey4me> this bug is pretty key to sort out soon
16:06:41 <odyssey4me> #link https://bugs.launchpad.net/bugs/1486593
16:06:42 <openstack> Launchpad bug 1486593 in openstack-ansible trunk "Neutron db migration issue in master" [Critical,New]
16:07:07 <odyssey4me> I know that mattt has been working on that, but I think someone may need to take it over from him.
16:07:15 <cloudnull> i think so too.
16:07:31 <cloudnull> idk if i have time work it at this point so someone needs to run point.
16:08:02 <cloudnull> this is a migration issue and may not be a major issues / problem however it would be great to be able to leverage some of the soft upgrade processes.
16:08:14 <Sam-I-Am> i dont have time for it either :/
16:08:20 <Sam-I-Am> it is neutrony, however.
16:08:26 <odyssey4me> mattt may need to pick it up again next week - I know that he's been chatting to the neutron team to figure out a better way to facilitate the upgrades
16:08:44 <Sam-I-Am> neutron needs some other changes for liberty
16:09:05 <evrardjp> Sam-I-Am: what do you mean, is it planned in the spec?
16:09:08 <odyssey4me> I'll chat to him next week and figure out a plan of action for neutron upgrades in the plays.
16:09:32 <odyssey4me> the issue is that the upgrade process for neutron has changed somewhat
16:09:39 <Sam-I-Am> evrardjp: there's a lot of changes to neutron in liberty outside of the db
16:09:43 <Sam-I-Am> not for this conversation
16:09:47 <Sam-I-Am> just a note
16:09:54 <odyssey4me> it gives some nice new features, but there isn't an easy way to parse the tool output to figure out whether an jupgrade is needed
16:10:16 <cloudnull> also Sam-I-Am: these "other changes" is that something that you may be able to raise on the ML so that we can target what we want to do accordingly without spelling it out here in this meeting ?
16:10:26 <odyssey4me> it has multiple branches now, and you need to verify several things before you decide what to do
16:10:28 <evrardjp> it's important because it could be part of the liberty readiness, which means it has to be known for the spec
16:10:54 <evrardjp> sorry for my intervention if not relevant
16:11:10 <cloudnull> not at all evrardjp,  its relevant .
16:11:27 <odyssey4me> for now, just add an action item for me to pick this up with mattt next week
16:12:03 <Sam-I-Am> bbl
16:12:11 <cloudnull> #action follow up with mattt regarding neutron changes
16:12:42 <cloudnull> #action Sam-I-Am to drop note on the ML for OSAD to ensure we're making the proper changes for liberty
16:12:49 <cloudnull> Sam-I-Am:  voluntold :)
16:12:57 <evrardjp> :)
16:13:31 <cloudnull> Ill try to have most of my inflight bps updated for reviews by weekend
16:13:41 <odyssey4me> ditto
16:14:05 <cloudnull> the https://blueprints.launchpad.net/openstack-ansible/+spec/remove-upstream-repo-dependency bp has reviews and should be ready for core to verify
16:14:21 <cloudnull> same with https://blueprints.launchpad.net/openstack-ansible/+spec/upgrade-mariadb-v10
16:15:05 <cloudnull> palendae:  you able to follow up with the current upgrade bits ?
16:15:40 <palendae> The liberty upgrade path? Yeah
16:15:49 <cloudnull> sweet!
16:15:50 <palendae> I thought I pushed an initial patch set, too, let me check
16:16:20 <odyssey4me> palendae yep, although I'm not sure that your spec has had enough reviews yet
16:16:26 <palendae> True
16:16:29 <odyssey4me> let me star the specs
16:16:31 <palendae> I would appreciate more
16:16:51 <cloudnull> also this wip change https://review.openstack.org/#/c/215291/ is in merge conflict at this point
16:17:08 <palendae> https://review.openstack.org/#/c/215291/ was the change
16:17:09 <palendae> YUeah
16:17:14 <odyssey4me> #link https://review.openstack.org/#/q/starredby:%22Jesse+Pretorius%22+project:stackforge/os-ansible-deployment-specs,n,z
16:17:19 <palendae> Will rebase it
16:17:27 <cloudnull> tyvm sir
16:18:17 <cloudnull> https://launchpad.net/openstack-ansible/+milestone/liberty-3 looks like its progressing nicely however as before odyssey4me you should have more context on that
16:18:25 <odyssey4me> palendae if you can remove the TODO's and either replace them with n/a's or some content, then we're good to go
16:18:33 <palendae> Ok
16:19:06 <odyssey4me> yeah, we're doing alright with liberty-3
16:19:14 <odyssey4me> in fact I think we've done brilliantly
16:19:30 <cloudnull> yes i agree
16:19:36 <odyssey4me> some items may have to shift to the next milestone, but that's ok
16:20:08 <odyssey4me> ideally we need to start working on changing the deprecated options and doing updates to the conf/policy templates
16:20:28 <odyssey4me> speaking of which - this spec needs more reviews
16:20:30 <odyssey4me> #link https://review.openstack.org/168976
16:20:49 <odyssey4me> cloudnull perhaps a little tl/dr would be useful?
16:21:49 <cloudnull> tl;dr. a new action plugin for ansible that makes it so we can render templates as is done by ansible but also override items in config without having to peramaterize all the things
16:22:11 <cloudnull> the action plugin supports json, yaml, and ini files.
16:22:56 <cloudnull> the plugin can be seen / reviewed here https://review.openstack.org/#/c/216790/1/playbooks/plugins/actions/crud_template.py,cm
16:23:08 <evrardjp> I'll put my comments, but I really like the idea of it
16:23:10 <cloudnull> which is a WIP review to replace the current copy_update plugin
16:23:14 <evrardjp> congrats
16:23:56 <cloudnull> thanks evrardjp !
16:24:14 <odyssey4me> the idea is to stop adding more and more parameters for overrides, make it simpler for deployers to understand how to add .conf settings they want and to reduce the work we have to do when we're looking at deprecations from cycle to cycle
16:24:26 <cloudnull> current naming is crud_template (u have no naming originallity) but that name is subject to change.
16:24:47 <odyssey4me> we'll have to carry current settings/vars for a cycle (liberty) but we can remove them once we ship M
16:24:48 <cloudnull> s/u have/i have/
16:25:01 <cloudnull> thats the running thought
16:25:05 <odyssey4me> perhaps we should chat about the name now
16:25:24 <cloudnull> sure
16:25:45 <odyssey4me> personally I prefer something along the lines of 'template_update' for the module/task and 'update_data' instead of cu_data for the arg
16:25:55 <odyssey4me> maybe rather update_template for the module name
16:26:00 <evrardjp> the important is to know about this module, not the name...
16:26:23 <palendae> Good names are important
16:26:28 <cloudnull> fair enough.
16:26:37 <palendae> +1 for update_template
16:26:39 <evrardjp> easier to remember, so easier to know. I agree
16:26:42 <odyssey4me> evrardjp sure, but the name and args do affect how easily the purpose is understood
16:26:49 <palendae> Or more communicative of intent/purpose
16:26:51 <evrardjp> update_template seems easy to remember
16:27:25 <cloudnull> +1 update_template sounds good to me
16:27:54 <evrardjp> 0118 999 88199 9119 725 ... 3 (for those who understand "that's easy to remember")... Sorry for this intrusion ;)
16:28:31 <cloudnull> so pleaes review the spec/code its much appreciated.
16:28:37 <evrardjp> will do
16:28:49 <cloudnull> after some reviews come through ill update the naming
16:29:04 <cloudnull> and fix other bits noted
16:29:24 <cloudnull> moving on, unless theres something else to note about the spec ?
16:29:28 <cloudnull> or other specs ?
16:29:40 <odyssey4me> #link https://review.openstack.org/213779
16:29:59 <odyssey4me> I'd like to revise it based on comments this weekend, so please review and comment.
16:30:07 <cloudnull> kk
16:30:35 <odyssey4me> Note to all that approving the spec will not result in an immediate repo split. It will simply allow us to create new repositories for new roles.
16:30:52 <odyssey4me> any splits from the current repo will still require their own blueprint or spec.
16:30:52 <cloudnull> ++
16:30:58 <odyssey4me> *and
16:31:03 <lbragstad> odyssey4me: so the roles will exist in each temporarily, right?
16:31:16 <odyssey4me> this is because the split of each role will require a lot of planning
16:31:46 <odyssey4me> lbragstad I'm not sure I understand what you mean?
16:33:03 <evrardjp> I have a question, what's the plan for future roles? should we plan with the split in mind or include as usual?
16:33:20 <evrardjp> because there is no mention of real date in the spec
16:33:28 <cloudnull> evrardjp:  i'd include as usual for now.
16:33:33 <evrardjp> ok
16:33:35 <lbragstad> odyssey4me: I think I answer my own question :)
16:34:26 <odyssey4me> evrardjp it kinda depends on what the role is - if it'll be part of a core deployment, then plan to include right now
16:34:42 <palendae> ^ I like that plan
16:34:48 <odyssey4me> if it's independant and optional, then perhaps plan for a separate repo
16:34:51 <evrardjp> I'll publish a PoC code, and we'll adapt according to
16:34:57 <palendae> At the moment, OSAD is very much a highly coupled system
16:35:04 <odyssey4me> eg: there is a rally role in the wings - that should be planned to be seperate
16:35:46 <cloudnull> evrardjp:  theres no real plan for splitting anything up at this point. and if you have work inflight to add into the main repo I'd keep that going on that. if we get this spec in and we feel its best to create a new repo we'll have to bring it up to the ML , meeting , the maintinaer, etc. . . to do all the work.
16:35:58 <odyssey4me> +1
16:36:38 <evrardjp> agree, it just needs to be clear for all the possible contributors, and set a date of the possible move, that was my point
16:36:49 <cloudnull> the process will be fully transparent. so while I want this to make the project better, like odyssey4me said, its going to take work and planning.
16:37:03 <evrardjp> ok
16:37:07 <odyssey4me> yeah, the the moves will take place over an entire cycle - not all in one day
16:37:54 <odyssey4me> we have to look after our downstream consumers, some of which (like evrardjp) are largely following on a per commit basis
16:38:09 <cloudnull> ++
16:38:35 <cloudnull> moving on
16:38:36 <cloudnull> #topic Mitaka Summit Discussion Agenda (input required)
16:38:45 <cloudnull> #link https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit
16:39:13 <cloudnull> we need people to think about and contribute to our efforts at the summit .
16:39:56 <cloudnull> ideally id like to see what type of rooms we'll need @ tokyo so i can make the request to ttx sooner than later.
16:40:24 <evrardjp> I'll be there
16:40:29 <cloudnull> sweet!
16:40:33 <odyssey4me> awesome evrardjp :)
16:40:37 <cloudnull> first rounds on me :)
16:40:51 <evrardjp> I have a question about that I'll keep for open topics
16:41:14 <odyssey4me> personally I think it'd be great to have a fishbowl discussion early on to hash out ideas and thoughts
16:41:26 <cloudnull> ++ i like the fish bowls
16:41:32 <odyssey4me> then have a contributors meetup on fri to take the ideas and plot out a roadmap
16:41:45 <cloudnull> however space is a bit limited in tokyo so access will be limited .
16:41:56 <odyssey4me> that way we can seperate the critical thought from the creative thought
16:42:02 <cloudnull> and other projects, like nova, will have more presedence if push comes to shove
16:42:32 <cloudnull> workrooms should be more available
16:42:43 <cloudnull> and for sure we'll regester a contributors meetup on friday
16:42:46 <odyssey4me> alternatively, perhaps we could arrange a fish bowl type session on fri morning, then do a meetup in the afternoon for the rest?
16:43:02 <cloudnull> thatll work
16:43:23 <evrardjp> Isn't something already planned for Tue?
16:43:37 <odyssey4me> that will be nice because it'll give us all a chance to attend presentations and be free to attend other design discussions
16:44:46 <cloudnull> indeed.
16:45:16 <cloudnull> i think , as a deployment project its key for us to participate in the design sessions for other porjects.
16:45:25 <evrardjp> +1
16:45:44 <evrardjp> we need to know what's going on at all times
16:45:55 <cloudnull> their changes effect us and with our "from source" nature we're able to consume these changes sooner.
16:46:04 <cloudnull> evrardjp:  +1
16:46:33 <evrardjp> the important is to let us have the room to understand the changes applied
16:46:45 <evrardjp> I'm not sure if it's correct english
16:46:52 <evrardjp> anyway
16:46:57 <evrardjp> we agree
16:47:01 <cloudnull> :)
16:47:04 <odyssey4me> :)
16:47:14 <evrardjp> decision?
16:47:40 <evrardjp> Tue fishball session and small meeting friday?
16:48:06 <odyssey4me> I'm preferring a room all day fri, if we can get it.
16:48:29 <odyssey4me> otherwise a fall back to what evrardjp  said
16:49:42 <cloudnull> * tuesday 1 fishbowl would be great. wensday 1 workgroup to talk about inflight items and issues that have result ed in bad life choices. friday 1 meetup lasting a couple of hours if possible.
16:50:16 <odyssey4me> sounds good to me
16:50:22 <cloudnull> idk if people will be available monday but we might be able to team up with some of the guys @ ansible to have a community day again
16:50:40 <cloudnull> and if so maybe we cut out wed ?
16:51:11 <cloudnull> the community day at vancouver seemed to work out nicely .
16:51:30 <odyssey4me> I like the idea of having that on the Mon so we don't miss out on so much of the summit
16:51:39 <odyssey4me> I barely managed to attend anything last summit\
16:51:55 <cloudnull> yea +1
16:52:04 <cloudnull> ok lets get some of this in the etherpad
16:52:35 <cloudnull> and well make the decision EOD on Friday/Saturday.
16:52:56 <cloudnull> based on general majority from what folks put down there.
16:53:08 <odyssey4me> cool - will add bits after the meeting
16:53:12 <cloudnull> k
16:53:22 <cloudnull> #topic Open discussion
16:53:32 <cloudnull> evrardjp:  you had something you wanted to bring up ?
16:54:04 <evrardjp> yeah, and it's linked to previous discussion
16:54:12 <evrardjp> I've seen there was 3 ansible meetings here
16:54:20 <evrardjp> https://libertydesignsummit.sched.org/
16:54:36 <evrardjp> am I on the good page?
16:54:38 <evrardjp> damn
16:54:49 <evrardjp> I just realized I'm not on the right one
16:54:55 <odyssey4me> haha, that's the last summit
16:55:11 <evrardjp> I was thinking about lobying
16:55:16 <odyssey4me> https://mitakadesignsummit.sched.org/
16:55:21 <evrardjp> to gather the community
16:55:47 <evrardjp> it's not relevant anymore, sorry.
16:55:52 <evrardjp> Next?
16:56:23 <lbragstad> if something is put together with the ansible folks for monday, will that be a word of mouth thing?
16:56:42 <lbragstad> since nothing officially starts on monday?
16:56:50 <cloudnull> last time they added it in shed late
16:57:10 <cloudnull> im not sure what theyll do, if anything, this go around .
16:57:18 <lbragstad> ok
16:58:46 <cloudnull> ok well then if theres nothing else i think we're done here.
16:59:34 <evrardjp> Ok thanks for the meeting
17:00:20 <cloudnull> thanks everyone
17:00:24 <cloudnull> :)
17:00:26 <cloudnull> have a good one
17:00:31 <cloudnull> #endmeeting