16:01:49 <b3rnard0> #startmeeting OpenStack Ansible Meeting 16:01:51 <openstack> Meeting started Thu Feb 19 16:01:49 2015 UTC and is due to finish in 60 minutes. The chair is b3rnard0. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:55 <openstack> The meeting name has been set to 'openstack_ansible_meeting' 16:02:05 <b3rnard0> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:02:17 <b3rnard0> #topic RollCall 16:02:27 <cloudnull> present 16:02:34 <b3rnard0> presente 16:02:44 <stevelle> present 16:02:48 <VW_> hmm - we have meeting room conflict 16:02:50 <sigmavirus24> gift 16:03:09 <sigmavirus24> VW_: os-ansible-deployment has had this room for >1 month I think 16:03:16 <palendae> present 16:03:20 <VW_> yeah, we had it back in December 16:03:28 <VW_> but we are alternating timeslots 16:03:55 <sigmavirus24> VW_: interesting we haven't run into each other yet 16:04:03 <b3rnard0> VW_: what time is your meeting? 16:04:17 <alextricity> Morning 16:04:28 <sigmavirus24> o/ alextricity 16:04:47 <VW_> 16:00 UTC, sigmavirus24 / b3rnard0 16:04:54 <VW_> it's new as of December, though 16:04:58 <VW_> you guys carry on 16:05:05 <VW_> I'll see what I can do to work around 16:05:18 <b3rnard0> VW_: sorry about the confusion 16:05:38 <mdorman> VW_: reasonable to move to #openstack-operators? 16:05:59 <d34dh0r53> presente 16:06:19 <b3rnard0> cloudnull: we didn't have any action items from last week, do we want to just jump onto contributor guidelines discussion? 16:06:24 <Sam-I-Am> hi 16:07:07 <belmoreira> VW_: fine for me 16:07:24 <VW_> cool 16:07:46 <b3rnard0> thanks VW_ 16:08:27 <cloudnull> VW_ belmoreira mdorman i dont see anything on https://wiki.openstack.org/wiki/Meetings for your meeting at this time, but we can move our meeting to another time slot / room moving forward if needed. 16:08:49 <b3rnard0> #action b3rnard0 Make sure there are no meeting conflicts and update meeting time if necessary. 16:09:28 <cloudnull> any who, lets get started? 16:09:40 <VW_> nah - we'll sort it out, cloudnull 16:09:59 <cloudnull> alright, sorry for the confusion :) 16:10:19 <cloudnull> so lets get right into Contributor guidelines discussion 16:10:22 <b3rnard0> #topic Contributor guidelines discussion 16:10:30 <b3rnard0> #link https://etherpad.openstack.org/p/ansible-contrib 16:10:38 <cloudnull> mancdaz started ^ 16:11:03 <cloudnull> i think we need to lay out specific guidelines for contributions and begin adhering to them. 16:11:19 <cloudnull> and i know that i've been part of the problem 16:12:00 <cloudnull> so moving forward, i like where this is going. but i'd like to get everyone to start looking at that and add bits that may be missing. 16:12:54 <cloudnull> anyone have any thoughts on taht ? 16:13:45 <cloudnull> anyone here ? 16:13:50 <palendae> I agree with what mancdaz has outlined there 16:13:57 <Apsu> Personally, I think that there will probably be need for exceptions with respect to 1 blueprint = 1 feature = 1 patch set, mostly because "feature" is such a vague target. 16:14:01 <mattt> here, and no real arguments w/ what is there 16:14:03 <Apsu> But I generally agree with it. 16:14:29 <Apsu> The whole blueprint/voting aspect is a given 16:14:31 <mattt> we need clarification on whether features get backported too tho 16:14:36 <Sam-I-Am> bluesprints/specs ? 16:14:51 <cloudnull> so lets start with the etherpad and then once we have something that is mutually agreeable we should add it to the contributing guidelines. 16:15:00 <Apsu> +1 16:15:22 <mattt> +1 16:15:38 <Sam-I-Am> Apsu: a lot of bps generally have > 1 patch 16:15:50 <cloudnull> so lets get eyes on that, and later today we'll pr to master in the contributing guidelines. 16:16:00 <Sam-I-Am> smaller patches are easier to vote on than huge ones 16:16:01 <odyssey4me> o/ (sorry I'm late) 16:16:09 <cloudnull> np odyssey4me 16:16:11 <b3rnard0> we forgive you odyssey4me 16:16:27 <Apsu> Sam-I-Am: I know, not really what I meant. I'm moreso talking about what constitutes a "feature" and whether a single bp should subsume multiple ones or not. But we can discuss that separately 16:16:36 <Sam-I-Am> mmkay 16:17:26 <Apsu> If the feature is "restructure playbook style", you end up with a huge patchset. Some "features" are huge and invasive. That's what brought this issue up in the first place, so just pointing out that "feature" is vague and sometimes it hurts :) 16:18:48 <cloudnull> ok moving on to "Blueprints" 16:19:01 <b3rnard0> #topic Blueprints 16:19:13 <b3rnard0> #link https://blueprints.launchpad.net/openstack-ansible/+spec/additional-tempest-checks 16:20:17 <cloudnull> so i think that bp is in line with our whole, "if your not working on gating your not working" mantra. but the BP needs some more data. 16:20:43 <palendae> Are we conflating rackspace sprints with os-ansible-deployment goals then? 16:20:47 <b3rnard0> also, did we want to start using a blueprint or spec template? 16:21:05 <hughsaunders> this patch should be more inline with that bp https://review.openstack.org/#/c/156831/ 16:21:16 <cloudnull> palendae no, the integration with tempest should be a project goal . 16:22:23 <cloudnull> i think if we're going to have a successful project we need better testing and per OpenStack tempest == testing. 16:22:34 <palendae> Sure, not saying that 16:22:52 <palendae> I'm more confused where the mantra came from - don't remember it as part of the last os-ansible-deployment meeting 16:23:03 <palendae> Anyway 16:23:12 <palendae> More testing more good 16:23:58 <Apsu> America 16:23:59 <Sam-I-Am> who is testing the tests? 16:24:01 <d34dh0r53> going to update that BP today to the spec format that cloudnull uses 16:24:05 <d34dh0r53> btw 16:24:17 <cloudnull> d34dh0r53 great 16:24:20 <Apsu> Sam-I-Am: Quis custodiet ipsos custodes? 16:24:25 <d34dh0r53> cloudnull: I can haz link to gist? 16:24:39 <sigmavirus24> == Sam-I-Am 16:24:42 <b3rnard0> d34dh0r53: what is the link to the spec format so that we can add that to the guidelines? 16:24:55 <sigmavirus24> Apsu: the cores are the watchpersons and the community watches them 16:25:00 <d34dh0r53> b3rnard0 meet cloudnull 16:25:03 <cloudnull> d34dh0r53: https://gist.githubusercontent.com/cloudnull/91f23c49c2a86ffd1309/raw/bea7862563c53553df1eaaf490ba5d249d75b985/blueprint-template.rst 16:25:16 <Apsu> sigmavirus24: Slightly creepy. But I can dig it 16:25:22 <odyssey4me> I think that perhaps we need to figure out, for this project, what sort of change to the project requires a blueprint and what can simply be logged as a bug. 16:25:22 <b3rnard0> #link https://gist.githubusercontent.com/cloudnull/91f23c49c2a86ffd1309/raw/bea7862563c53553df1eaaf490ba5d249d75b985/blueprint-template.rst 16:25:24 <d34dh0r53> 👍 16:25:49 <Sam-I-Am> features usually = bp, bugs usually = bugs ? 16:25:52 <cloudnull> so this brings up another issue around Blueprints / Specs. I feel like we should be using specs and abandon blueprints. 16:25:56 <Apsu> odyssey4me: Simple. If it's a bug, fix it. If it's a feature, blueprint it. Pefectly clear, right? 16:26:01 <b3rnard0> d34dh0r53: meet action item 16:26:13 <b3rnard0> #action d34dh0r53 update blueprint with template from cloudnull 16:26:17 <stevelle> It seem the scope of the fix should influence that decision odyssey4me 16:26:25 <d34dh0r53> thank you sir, may I have another? 16:26:31 <Sam-I-Am> cloudnull: for upstream, we have a BP for general management, but it links to a spec for the actual discussion/voting 16:26:44 <cloudnull> yes that ^ 16:27:13 <palendae> Sounds like a good appraoch. BPs don't really allow for discussion 16:27:17 <cloudnull> in this way we'd have a repo of specs that people can comment and vote on. 16:27:27 <cloudnull> at present the launchpad whiteboard is terribad. 16:27:29 <Sam-I-Am> launchpad doesnt understand specs, but it does know how to manage targets and stuff. 16:27:41 <b3rnard0> +1 to specs 16:27:44 <Sam-I-Am> launchpad is the b3rnard0 of feature management 16:27:55 <hughsaunders> cloudnull: could we have in-repo specs to save having another repo? 16:28:05 <b3rnard0> Sam-I-Am: and you are the diagram editor for os-ansible? 16:28:16 <cloudnull> hughsaunders sure. 16:28:17 <palendae> hughsaunders: So we get specs on every checkout? 16:28:22 <Sam-I-Am> b3rnard0: say my name! 16:28:35 <cloudnull> ^ palendae beat me to my comment on that. 16:28:43 <palendae> Er, clone 16:29:14 <hughsaunders> yeah, I guess they would be quite small, and it would save having another repo to keep track of 16:29:44 <hughsaunders> but git-harry tells me that all the openstack projects use external specs repos, so maybe we should follow suit? 16:29:52 <Sam-I-Am> most of the upstream projects have separate repos 16:29:54 <Sam-I-Am> like -specs 16:30:00 <odyssey4me> in-repo may mean that the automated spec building may not work - assuming that this can be done for stackforge projects 16:30:20 <odyssey4me> also, perhaps the approvers for specs should be different to the approvers for the code? 16:30:20 <sigmavirus24> odyssey4me: I think it can 16:30:27 <sigmavirus24> odyssey4me: specs live on specs.openstack.org 16:30:27 <Sam-I-Am> odyssey4me: +1 16:30:41 <sigmavirus24> odyssey4me: typically there's overlap but they're not the same team 16:30:44 <palendae> Well, if the goal is to be more like upstream OpenStack, then separate repos sounds like the way to go 16:30:55 <cloudnull> so lets ping "jhesketh" to see about getting another repo. 16:32:33 <b3rnard0> #info palendae: Well, if the goal is to be more like upstream OpenStack, then separate repos sounds like the way to go; cloudnull: so lets ping "jhesketh" to see about getting another repo. 16:33:00 <b3rnard0> who would like to ping jhesketh for the repo? 16:33:14 <cloudnull> ill hit him up today . 16:33:21 <cloudnull> but he's likely sleeping right now. 16:33:51 <cloudnull> anything else we want to talk about regarding blueprints ? 16:34:24 <cloudnull> ok moving on 16:34:24 <b3rnard0> #action cloudnull ping jhesketh about creating a separate repo 16:34:34 <b3rnard0> #topic Milestones 16:34:49 <b3rnard0> #link https://launchpad.net/openstack-ansible/+milestone/next 16:34:53 <cloudnull> presently we have 2 milestone. 10.1.2 and 9.0.7 16:35:34 <cloudnull> imo 10.1.2 is close to being done. 16:35:53 <cloudnull> while 9.0.7 has a few items that need to go in, IE tempest commit_aio testing. 16:36:17 <cloudnull> for the most part things are passing, that said we need reviewers. 16:36:32 <cloudnull> please do the needfuls on items in https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment,n,z 16:36:51 <cloudnull> there are 7 commits for icehouse 16:36:52 <b3rnard0> #link https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment,n,z 16:37:05 <cloudnull> 5 for juno. 16:37:48 <cloudnull> odyssey4me do we know when infra will can get our gate change commit in ? 16:38:29 <odyssey4me> cloudnull it's been waiting in the queue since monday... I'm trying to be patient and wait for a week before starting to escalate. :p 16:38:42 <cloudnull> thats fair. 16:38:53 <cloudnull> i think we've bothered them a enough for a while :) 16:39:07 <odyssey4me> the supposed expected time for a review to sit in the queue is 5-7 days 16:39:08 <cloudnull> odyssey4me you have the link for that review . 16:39:23 <odyssey4me> #link https://review.openstack.org/156229 16:39:47 <cloudnull> if we can get some other reviewers on that ^ it would also be great. 16:39:56 <Apsu> Already doing 16:41:19 <cloudnull> so anything else regarding present milestones? 16:42:01 <cloudnull> ok moving on 16:42:10 <b3rnard0> #topic Open discussion 16:42:49 <BjoernT> So pinning will be backported to icehouse branch and we will use the same versions as 10.1.2? 16:43:08 <cloudnull> BjoernT it looks like it. 16:43:12 <odyssey4me> BjoernT yes, the patches are already in-flight 16:43:17 <cloudnull> odyssey4me has put through that work . 16:43:27 <cloudnull> ^ what odyssey4me said :) 16:43:45 <BjoernT> Nice 16:44:12 <cloudnull> BjoernT if you have time please review the open PRs @ https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment,n,z we'd love some external feedback . 16:44:22 <odyssey4me> BjoernT obviously the openstack service versions will not be the same - the pinning backport and version pin will only apply to the infrastructure 16:44:34 <BjoernT> ok, I'llk do 16:44:42 <BjoernT> sure 16:45:18 <BjoernT> is there a reason why we didn't backport 1410437 to icehouse ? or are we reducing development on 9.x ? 16:45:37 <cloudnull> BjoernT 9.x is in maintenance. 16:45:54 <b3rnard0> #action BjoernT to help out with reviewing open PRs https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment,n,z 16:45:54 <BjoernT> What issues are fixed in that state ? 16:46:14 <cloudnull> critical / some high 16:46:47 <cloudnull> that said odyssey4me : do we think getting that in for 9.0.7 is a worthwhile effort? 16:47:07 <BjoernT> OK, we talked internally yesterday and we think 1410437 is critical (PATH missing in keystone token_flush cronjob) 16:47:10 <odyssey4me> what are we talking about here? 16:47:38 <odyssey4me> oh - the keystone path thing? 16:47:55 <BjoernT> I meant the support team talked internally about what can happen to customer environments if the token table grows to big 16:47:58 <cloudnull> BjoernT: from the prospective of the deployer , we dont know what pains you unless you and others join in here, in the community forum 16:48:07 <odyssey4me> well, I don't think it was backported in the previous run because nobody lobbied to have that done - it was never marked as backport potential for icehouse (until today) 16:48:28 <BjoernT> yes I know that's why we talked about it yesterday. is 9.0.7 already frozen? 16:48:43 <odyssey4me> it's probably an easy backport 16:48:48 <BjoernT> Can I mark bugs myself as backport potential ? 16:48:51 <Sam-I-Am> imho, the token-flush thing is a pretty big issue 16:48:58 <stevelle> action item? 16:49:09 <odyssey4me> I did try to cherry-pick through gerrit already, and it doesn't... so there's clearly a conflict. 16:49:29 <cloudnull> so lets prioritize it and get it in for 9.0.7 16:49:59 <odyssey4me> BjoernT it would often be best to include the versions that you think it applies to in the description or a follow-on message. 16:49:59 <BjoernT> +1 16:50:03 <cloudnull> that said , BjoernT can you talk to your team about joining the tuesday triage meeting? 16:50:10 <odyssey4me> That way the bug triage can target it in the process. 16:50:32 <BjoernT> yes it is usually me but this week was bad, we will have a secondary joining 16:50:36 <odyssey4me> and yeah, join the meetings and advocate 16:50:46 <cloudnull> ok. 16:50:51 <cloudnull> anything else? 16:51:03 <BjoernT> Not from me 16:51:15 <b3rnard0> thanks BjoernT 16:51:23 <cloudnull> ok , lets call it 16:51:28 <b3rnard0> thanks everyone 16:51:30 <cloudnull> thanks everyone 16:51:49 <BjoernT> Thanks 16:51:53 <b3rnard0> #endmeeting