16:00:33 <odyssey4me> #startmeeting OpenStack-Ansible
16:00:33 <openstack> Meeting started Thu Mar  3 16:00:33 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:37 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:49 <prometheanfire> \o/
16:00:52 <odyssey4me> #topic Agenda & rollcall
16:01:03 <odyssey4me> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:09 <cloudnull> o/
16:01:10 <automagically> o/
16:02:01 <mattt> \o for a few mins
16:03:25 <jmccrory> o/
16:03:27 <palendae> o/
16:04:10 <odyssey4me> #topic Topics for Discussion - Newton Summit Planning
16:04:19 <odyssey4me> #link https://etherpad.openstack.org/p/openstack-ansible-newton-summit
16:04:38 <odyssey4me> Hi everyone, and welcome.
16:04:43 <odyssey4me> Thank you for making the time to be here!
16:05:09 <odyssey4me> We've been asked for a count of which types of which rooms we want for what sessions at the Newton/Austin summit.
16:05:46 <odyssey4me> I've taken the liberty to propose some work sessions. These are simply proposals, some of which I'd like volunteers for moderation and to fill out the details.
16:06:03 <odyssey4me> Also, any other sessions can be proposed.
16:06:35 <odyssey4me> We learned from the mid-cycle that discussions need to be centred around a body of work and should have ideal outcomes set up-front.
16:07:01 <odyssey4me> As I recall each work session is typically 40 mins or so, so please bear that in mind when planning for moderation.
16:08:19 <odyssey4me> good proposal automagically
16:08:34 <odyssey4me> please vote on sessions you'd like to see happen
16:08:38 <odyssey4me> and add additional proposals
16:09:32 <odyssey4me> In my personal view, I think we should focus more on having work sessions this summit.
16:09:53 <automagically> +1
16:10:00 <odyssey4me> jmccrory I left out an Ansible 2 work planning session. Please add it as a proposed topic.
16:10:27 <jmccrory> sure
16:13:09 <automagically> Not seeing any votes on MultiOS…FWIW, my opinion is we have much bigger fish to fry before worrying about supporting additional platforms
16:13:56 <odyssey4me> automagically yep, that's fair
16:15:01 <cloudnull> +1
16:15:26 <automagically> Nice addition Nolan
16:15:37 <cloudnull> i'd love to see the multi-os go however there's a ton of work that could be more important.
16:15:43 <palendae> automagically: Eh?
16:15:48 <palendae> I think that's Jesse
16:16:02 <automagically> Whoops, sorry. Too many purples in the Etherpad
16:16:13 <palendae> Fixed
16:17:18 <odyssey4me> lol
16:19:28 <automagically> So, one day for work sessions? Just trying to figure out how many we ultimately will need to winnow the list down to
16:19:48 <automagically> Austin will be my first summit, so excuse the newb question
16:20:08 <palendae> automagically: They can potentially be split across multiple days
16:20:17 <odyssey4me> automagically the design summit typically runs for 3 days
16:20:20 <palendae> Comes down to room allocation
16:20:23 <automagically> Oh cool
16:20:30 <odyssey4me> we will ask for x sessions which will be spread across the days
16:20:34 <automagically> So potentially we could get all of these that have votes
16:20:35 <cloudnull> we also can use the contributor day on Friday/Monday
16:20:48 <cloudnull> depending on how they organize that this go
16:20:51 <odyssey4me> we may not get the number we want, so we may have to prioritise accordingly
16:21:15 <palendae> automagically: Potentially, but they're also balancing slots/rooms across all projects
16:22:24 <automagically> Re Windmill - define “external CI implementation”
16:22:31 <odyssey4me> ok, let me cover that
16:22:44 <odyssey4me> you may have seen pabelanger in channel quite often
16:23:24 <automagically> Indeed
16:23:24 <odyssey4me> he's been working on various ansible roles to implement zuul, disk-image-builder, and other bits which facilitate the implementation of continuous integration tooling based on technologies used by OpenStack-CI
16:23:37 <automagically> Aha
16:23:44 <odyssey4me> his work is looking for a home, and he's familiar with OpenStack-CI
16:24:08 <odyssey4me> he's asked if we'd be keen on having his work as a sub-project or something
16:24:26 <odyssey4me> so I think it'd be great if we could have him tell us about the work he's done
16:24:53 <automagically> odyssey4me: +1, can you drop a link to git repo(s) under that one
16:24:58 <odyssey4me> also, I've spoken to several deployers in the past few months and CI/CD is quite a hot topic
16:25:35 <automagically> Looks like voting and new topics have died off
16:25:38 <automagically> Next topic?
16:26:09 <cloudnull> +1 seems like people will chew on that a bit
16:26:11 <cloudnull> we can move on
16:26:13 <cloudnull> IMO
16:26:19 <odyssey4me> it'd be nice if we could take the lead on providing tooling to make CI/CD go
16:26:58 <odyssey4me> yes, the last word on this is that we need to have this planning sorted asap
16:27:01 <automagically> odyssey4me: Agreed, but priorities wise for deployers/operators using OSA, its bound to be lower priority than adding support for more functionality and getting docs/tests/quality of OSA up
16:27:23 <odyssey4me> so I'd like to ask that everyone put time in to figure out which sessions you want to moderate and add your name to it
16:27:28 <michaelgugino> CI/CD is more important to me than more roles
16:28:01 <automagically> michaelgugino: Interesting, would love to hear why after the meeting
16:28:08 <odyssey4me> right, next topic
16:28:16 <odyssey4me> #topic Discussion - Define core team expectations/Add non-Rackspace cores
16:28:24 <odyssey4me> automagically - your floor :)
16:28:36 <odyssey4me> #link https://review.openstack.org/286858
16:28:37 <automagically> Did you all have a chance to read through and think about https://review.openstack.org/286858
16:29:02 <automagically> I didn’t see many votes and nearly 0 comments from existing cores
16:29:23 <cloudnull> Ive not read that . however i will now.
16:29:29 <automagically> Of course lots of other stuff has been going on
16:29:52 <odyssey4me> should we let it simmer for a week and re-address it in next week's meeting with the view to merge it by the end of next week?
16:29:54 <automagically> I think the key is to call out any misleading and controversial content in the review
16:30:01 <automagically> odyssey4me: That works
16:30:41 <odyssey4me> ok cool - I think wwe're a bit short on time to actually have a full discussion
16:30:46 <automagically> agreed
16:30:50 <odyssey4me> I think it's best to discuss and address in review
16:31:01 <odyssey4me> we have the channel to smoothe out any misunderstandings
16:31:04 <automagically> next topic then
16:31:07 <odyssey4me> next topic
16:31:14 <odyssey4me> #topic Discussion - Pinning pip and related dependencies
16:31:32 <odyssey4me> thanks for all the support in the last few days, I think we're finally out the door on https://review.openstack.org/#/q/status:open+topic:repeatable-build
16:31:57 <odyssey4me> we may have to apply one more patch to kilo for setuptools, or to align the approach at least
16:32:09 <odyssey4me> any questions or comments before we move on?
16:32:27 <automagically> none here
16:32:33 <cloudnull> nope
16:32:37 <odyssey4me> #topic Discussion - Support for multiple availability zones
16:32:44 <odyssey4me> is admin0 around?
16:33:00 <odyssey4me> I think we've kinda discussed this and agreed to address it in the next iteration of the inventory
16:33:11 <cloudnull> ++
16:33:16 <odyssey4me> Are we happy to remove this from the agenda?
16:33:42 <michaelgugino> sure
16:34:01 <odyssey4me> #topic Release Planning and Decisions
16:34:15 <odyssey4me> Alright, we're a week overdue on tagging Liberty & Kilo
16:34:36 <odyssey4me> we have the pip/wheel/setuptools world breaking pain last week this time
16:35:13 <odyssey4me> Once https://review.openstack.org/287161 has merged I think we're good to tag Liberty. Kilo may need a similar patch, then we should be good to go.
16:35:18 <odyssey4me> Any thoughts/comments?
16:35:35 <cloudnull> i think it'd be wise to submit that to kilo
16:35:45 <automagically> cloudnull: +1
16:35:47 <odyssey4me> #action odyssey4me to patch the Kilo branch with a backport of https://review.openstack.org/287161
16:35:55 <odyssey4me> yep, I think so too
16:36:03 <cloudnull> it uses a different wheel building process however downstream deployers will find that valuable
16:36:34 <odyssey4me> I think that Liberty may be missing the repo_build/repo_server changes from master. cloudnull can you patch those in too?
16:36:42 <cloudnull> sure thing
16:37:06 <cloudnull> Im working on fixing my merge conflicts today. ill bang that out too
16:37:20 <odyssey4me> #action cloudnull to patch in the repetable-build changes from repo_build/repo_server in order to finalise the repeatability.
16:38:10 <odyssey4me> I know there are a few packages which aren't covered by upper-constraints, and therefore aren't fully covered by the repeatable deployment... they're fringe though, so not terribly impactful, I think
16:38:38 <cloudnull> i think we're rather safe in that regard.
16:39:07 <odyssey4me> mitaka-3 is effectively now, and we're a bit behind
16:39:28 <odyssey4me> mitaka-3 to rc1 is supposed to be a time of bedding down the code and ensuring that bugs are ironed out
16:39:51 <odyssey4me> so I suggest that we all get behind finishing up getting functional testing into the independent roles
16:40:23 <jmccrory> concern with tagging liberty is that the upgrade script is half implemented, it looks like if someone were to attempt it now it will install independent roles and then remove rabbit queues/exchanges that would still be in use
16:40:37 <jmccrory> breaking a deployment
16:40:40 <cloudnull> i think its ok to be a bit behind on this relaese. I mean we should rev forward however if we dont ship a stable tag on the day of releaes I wont shed any tears.
16:41:30 <odyssey4me> jmccrory sure - perhaps we should make the upgrade script hard exit at the start with a warning that the work is incomplete?
16:41:32 <cloudnull> we have a lot of things in mothion right now .
16:41:35 <odyssey4me> palendae thoughts?
16:41:56 <odyssey4me> cloudnull ++ agreed
16:42:00 <palendae> That's the exact reason I didn't want to submit this work in pieces like this
16:42:19 <palendae> I would appreciate it if someone could take on that exiting patch though
16:42:46 <odyssey4me> jmccrory can you put a note into all the upgrade docs and the script to make sure that it's clear that this is still a WIP
16:43:01 <jmccrory> sure
16:43:04 <odyssey4me> we can smash that through and I'll tag once that's done
16:43:06 <palendae> Thanks
16:44:03 <odyssey4me> #action jmccrory To make the upgrade script for Kilo->Liberty hard exit with a warning that the work is incomplete, and to add notes into the docs to make it clear there too.
16:44:11 <odyssey4me> Thanks jmccrory
16:44:18 <odyssey4me> #topic Blueprint work
16:44:41 <odyssey4me> Any news on any of the blueprint work? michaelgugino automagically logan- vdo ?
16:45:03 <automagically> I haven’t had a chance to touch DVR/OVS, IRR really took over
16:45:13 <michaelgugino> I've been wrapped up in other things, haven't had a change to touch that stuff.  Hoping to finally get to some today
16:45:14 <automagically> That and some test deployments
16:45:57 <odyssey4me> ok, no worries - none of those items were really promised in this cycle anyway... they were late starters and can happily be done next cycle
16:46:22 <odyssey4me> I do think that implementing more functional testing in the roles is top priority.
16:46:33 <odyssey4me> It's a good chance for us to get more familiar.
16:47:06 <automagically> +1
16:47:12 <odyssey4me> cloudnull any thoughts on how we could split up the work?
16:47:41 <automagically> There appear to be some reusable patterns around inventory manipulation and container build out within the IRR tests
16:48:06 <automagically> As well as the testing pattern that was discussed yesterday in channel around standalone tests vs full-on, all deps tests
16:48:27 <automagically> I bring this up, because what would help me is a high level vision of how we want IRR testing to be
16:48:27 <cloudnull> odyssey4me: hard to say . keystone needs to be done first and that pattern copied to all other roles.
16:49:02 <automagically> keystone does look very well fleshed out. However, reading the test impl left me scratching my head at a few points
16:49:08 <odyssey4me> automagically it's kinda hard to say as we're kinda learning as we go here
16:49:13 <automagically> Fair enough
16:49:27 <cloudnull> automagically:  i think we can aim for a full multi node test wich is the OSA use case and the deviate from there.
16:49:28 <automagically> I’m okay with that, I guess I’m suggesting that we converge on a couple core patterns soon
16:49:38 <odyssey4me> yeah, I've been trying to get a standalone build working for ironic and have had similar head scratches :)
16:50:07 <odyssey4me> perhaps we should etherpad some thoughts and coalesce it into a plan?
16:50:09 <michaelgugino> test directory calls other roles necessary for completion?
16:50:10 <automagically> Well, perhaps we can commit to more in-channel conversation around testing patterns
16:50:14 <automagically> And/or etherpad
16:50:18 <cloudnull> the keystone multi-node tests did work (they we're a WIP though) so I'd suggest we start there.
16:50:48 <odyssey4me> cloudnull agreed, perhaps we should assess how it's done there and figure out a pattern we like
16:50:50 <automagically> michaelgugino: Not sure I understand your question
16:51:01 <odyssey4me> once that's done and merged, we can divvy up the rest of the roles and give it a go
16:51:05 <stevelle> limit of in-channel is cross-tz
16:51:06 <jmccrory> odyssey4me looking at bifrost might be helpful for ironic's test https://github.com/openstack/bifrost
16:51:12 <michaelgugino> for the role testing.  If you need keystone to be up, we should be able to call that role.
16:51:27 <odyssey4me> michaelgugino yes, tox.ini contains the basic test execution - it calls the tests/test.yml playbook
16:51:42 <cloudnull> the one thing that we need to figure out is how to run tempest or (something else) to verify the roles functionality. or is a convergence test good enough for now ?
16:51:43 <odyssey4me> the tests directory has its own inventory, custom for the test for that role
16:52:10 <palendae> Testing some of these things in complete isolation probably isn't feasible - as pointed out, many of them will rely on at least keystone
16:52:24 <cloudnull> ++ ^
16:52:25 <odyssey4me> cloudnull I'd say we start with just a convergence test, then add a functional test as a next work item.
16:52:35 <cloudnull> odyssey4me: +1
16:52:39 <automagically> odyssey4me: +1
16:52:51 <automagically> +1 on etherpad vs in-channel
16:52:58 <odyssey4me> right now we have nothing, so we're vulnerable to pretty basic errors
16:52:59 <cloudnull> +1 on etherpad
16:53:09 <odyssey4me> ok, cloudnull can you setup an etherpad
16:53:24 <odyssey4me> #action cloudnull to setup an IRR functional test planning etherpad
16:53:37 <cloudnull> https://etherpad.openstack.org/p/testing-os-roles
16:53:46 <stevelle> please add link to etherpad to the channel topic
16:53:59 <odyssey4me> automagically & jmccrory can you please quizz cloudnull to your heart's content over the evening to figure out a structure and some sort of game plan
16:54:04 <odyssey4me> stevelle ^
16:54:15 <odyssey4me> good idea stevelle
16:54:27 <automagically> odyssey4me: +1
16:54:34 <automagically> I’ll try to be gentle cloudnull
16:54:38 <odyssey4me> #action odyssey4me to set channel topic to include link to IRR functional testing etherpad
16:55:09 <cloudnull> automagically: no need to be gentle
16:55:14 <automagically> ;)
16:55:15 <cloudnull> :)
16:55:15 <odyssey4me> I'll be out after this meeting, so I'll take a look in the morning and mattt and I can do some further quizzing and examinning.
16:55:32 <spotz> o/ really late
16:55:44 <odyssey4me> michaelgugino of course you're welcome to dive in too if you have the time
16:55:49 <odyssey4me> as is anyone else
16:56:00 <odyssey4me> ok, we're close to being out of time, so let's switch topics
16:56:07 <odyssey4me> #topic Open Dicussion
16:56:22 <odyssey4me> o/ spotz
16:57:17 <odyssey4me> any topics for discussion
16:57:21 <automagically> Thoughts on how we get https://review.openstack.org/#/c/242225 as part of gate
16:57:21 <odyssey4me> ?
16:57:30 <automagically> And this: https://review.openstack.org/#/c/287571/
16:58:06 <odyssey4me> I think we should have an inventory-test tox target, then add a job in the integrated gate to execute the test
16:58:11 <automagically> I did some reading on jenkins job builder and project profiles, but I can’t say its entirely clear to me how we would run these tests and whether or not they should be in an existing step or not
16:58:19 <michaelgugino> I like the idea, but the particular check implemented is not very useful IMO
16:58:32 <odyssey4me> we could also add it to the end of the linters tox target
16:58:51 <odyssey4me> michaelgugino probably true, but it's a start :)
16:58:57 <automagically> michaelgugino: Agreed that the testing is limited, but I think we need to get started
16:59:13 <automagically> Next logical step seems to be getting it into tox and running
16:59:25 <automagically> So we can at least be ready to evaluate ongoing inventory changes
16:59:33 <odyssey4me> we could trial it as the last item in the linters target
16:59:42 <automagically> I’ll see what I can do to get it added to the linters target
16:59:57 <odyssey4me> we're out of time
17:00:00 <odyssey4me> thanks all!
17:00:02 <odyssey4me> #endmeeting