18:01:27 <vipul> #startmeeting cue 18:01:28 <openstack> Meeting started Mon Jun 1 18:01:27 2015 UTC and is due to finish in 60 minutes. The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:33 <openstack> The meeting name has been set to 'cue' 18:01:44 <vipul> roll call.. 18:01:56 <sputnik13> here 18:02:40 <vipul> just you and i eh? 18:02:52 <sputnik13> the others must be trolling us :) 18:02:59 <vipul> abitha, esmute ... davideagnello 18:03:14 <abitha> here 18:03:16 <esmute> Hello! 18:03:31 <ekarlso> ello :p 18:03:37 <dkalleg> hello hello 18:03:43 <sputnik13> ekarlso hola 18:03:44 <vipul> welcome ekarlso ! 18:03:53 <vipul> dkalleg: you changed your nick 18:03:56 <dkalleg> i did 18:04:07 <vipul> i like it.. a lot more cryptic 18:04:10 <dkalleg> had to set up everything over again after the ramen heist 18:04:33 <vipul> Agenda.. https://wiki.openstack.org/wiki/Meetings/Cue 18:04:38 <vipul> needs to be updated.. 18:04:43 <sputnik13> http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-04-28-18.02.html 18:04:52 <sputnik13> we have actions from the last meeting, which was a while ago 18:05:06 <vipul> ok.. let's go through that 18:05:09 <vipul> #topic Action Items 18:05:21 <vipul> davideagnello investigate how to run rally tests in CI gate 18:06:16 <vipul> davideagnello: .. ? there? 18:08:19 <davideagnello> vipul: I haven't investigated that portion yet 18:08:19 <vipul> do you still plan on doing this? 18:08:19 <davideagnello> I understand Boris from Rally will be helping us 18:08:19 <vipul> yep.. but we probably need to work with him at some point 18:08:35 <sputnik13> also we don't know where it is on his priority list 18:08:36 <davideagnello> vipul: will be following up with him this week on how we can get it incorporated for Cue 18:08:45 <vipul> ok cool thx 18:08:50 <esmute> davideagnello: Designate has rally test running in CI... They are non-voting 18:08:58 <esmute> that is one place to look into 18:09:10 <vipul> any project have voting turned on esmute ? 18:09:11 <davideagnello> esmute: ok, thanks 18:09:32 <vipul> ekarlso: did you do that work for designate? 18:09:39 <esmute> vipul: What did you mean? 18:09:56 <vipul> esmute: Is anyone gating on Rally yet? 18:10:38 <ekarlso> what work vipul ? 18:10:45 <vipul> rally gate 18:10:58 <esmute> vipul: I dont think so.. i looked at neutron and they also have it non-voting 18:11:42 <vipul> esmute: ok 18:11:53 <vipul> #action davideagnello to look into getting Rally gate job added 18:12:09 <vipul> next item.. 18:12:10 <vipul> esmute enable automatic tempest testing for all cue project repos 18:12:41 <davideagnello> vipul: note taken 18:12:48 <esmute> So cue has now a gate that installs devstack from nodepool, install cue service and run the cue int tests 18:13:15 <esmute> the int tests consist of a happy path (create, list, get and delete) and some negative path 18:13:47 <esmute> The gate is non-voting.. The plan is to leave it running a bit until we make sure it is stable enough to promote it to voting 18:14:09 <vipul> awesome! nice work 18:14:18 <esmute> the gate test normally takes aprox 40mins... 30mins in which is devstack and cue install 18:14:23 <sputnik13> should we set a time bound on "a bit"? 18:14:55 <vipul> esmute: how many runs do you want to see before we promote it 18:15:19 <esmute> sputnik13: i guess it depends how many patches are committed. 18:15:32 <sputnik13> is the gate only on merge or on checkin? 18:15:46 <dkalleg> maybe better to say x number of successful gating outputs rather than a time frame? 18:15:54 <esmute> i would like to have it running around 10 more times...... so perhaps one week? 18:16:23 <sputnik13> if it's a number of iterations, then couldn't we force it by running a recheck on a patch 10 times? 18:16:24 <esmute> sputnik13: just on checking.... Once it is promoted to voting, it will also be set to run on merge 18:16:26 <dkalleg> confidence in the tool is a product of how much work goes into it, not necessarily x days after it come to beta 18:16:45 <esmute> +1 dkalleg 18:17:02 <sputnik13> dkalleg: while generally true there are external factors that play in to this as well, like the CI infrastructure 18:17:10 <esmute> when i said 10, i meant 10 successful run :P 18:17:16 <dkalleg> so maybe say promote to voting after 10-20 successful runs of the gate? 18:17:29 <vipul> do we want to force those runs? or just let them occur naturally over time 18:17:31 <dkalleg> ah, k ) 18:17:34 <dkalleg> :) 18:17:56 <sputnik13> why don't we force those runs 18:18:03 <davideagnello> I agree 18:18:06 <esmute> sputnik13: when there is a failure, we can look at the logs and see the cause... if its CI infra, we wont consider it as a faulire on cue 18:18:41 <vipul> esmute: so pick a couple of existing patchsets.. run recheck until we get to the target ? 18:18:51 <sputnik13> esmute: I would agree but if CI infra has a hard time with it 9 out of 10 times, then gating our merge on the test would be counterproductive 18:19:18 <esmute> vipul: I think we can just leave it naturally.... whoever is working/review patches, make sure to look at the result of the int-test gate 18:19:51 <sputnik13> esmute I think that only works if we have a consistent rate patches being submitted 18:19:58 <vipul> esmute: the issue i have with that is are we going to get 10 runs in a week's time 18:19:59 <esmute> we can start treating them as 'voting' for now... so if there is a failure, we can look into it 18:20:13 <sputnik13> given the things we're currently working on that won't guarantee we have any number of runs in the near future 18:20:29 <vipul> sputnik13: +1 18:20:59 <sputnik13> let's have a dummy patch that we use to exercise the tempest check and run recheck on it a few times a day 18:21:09 <esmute> ok. We can create a dummy patch (one that modifies the README) and run it many times 18:21:10 <vipul> esmute: why dont' we try to making voting by the end of the week.. which may mean rechecks 18:21:25 <sputnik13> are the results from each recheck saved in the patch's logs? 18:21:43 <sputnik13> or are the logs purged after some amount of time? 18:21:58 <esmute> sputnik13: Yes. All the logs are stored... even the config files under /etc and devstack log 18:22:11 <esmute> the only logs that we wont get it is the rabbitmq node logs 18:22:12 <vipul> they do get purged.. not sure what the time frame is 18:22:29 <sputnik13> as long as the time frame is less than say 2 weeks I think it would be good enough 18:22:33 <esmute> ahh right.. yes they do get deleted 18:22:48 <sputnik13> it'll be a single place we can look at to see how many times it succeeded vs failed 18:22:48 <esmute> but we can watch it.. if there is a failure, we look into it 18:23:18 <esmute> ok, ill start a dummy patch and have it run many times 18:23:39 <vipul> ok.. esmute feel free to holler in the cue room if you want others to look at a failure 18:23:54 <sputnik13> let's set a timeframe of 1 week to see how things look, and if we get 90% or more success rate I think it would be good enough 18:23:54 <esmute> vipul: ok no prob 18:24:05 <sputnik13> 90% is something just pulled out of my rear end 18:24:20 <esmute> eww 18:24:25 <esmute> :p 18:24:35 <sputnik13> so your'e free to pick another number if you don't like the source of that number :) 18:24:35 <vipul> #action esmute to making tempest rabbit gate job voting 18:25:09 <vipul> the source is definitely the issue he has with that number ;) 18:25:45 <sputnik13> ok, this conversation will devolve quickly, let's move on :) 18:25:55 <vipul> ok, moving on.. :D 18:25:59 <dkalleg> +1 18:26:01 <vipul> #topic open discussion 18:26:25 <sputnik13> we should start looking at open bugs and decide what to do with them 18:26:36 <davideagnello> +1 18:26:47 <sputnik13> I'll take an action to update the cue meeting agenda each week 18:27:02 <vipul> sputnik13: thx -- any bugs we want to discuss today? 18:27:11 <sputnik13> I'm thinking we should do action items, discussion topics, bugs, then open discussion 18:27:17 <sputnik13> is that a good format? 18:27:30 <vipul> yep works for me 18:27:54 <sputnik13> well, I'm wondering whether we should use the meeting to discuss certain bugs or triage them 18:27:56 <esmute> sputnik13: Do we have an agenda for next week for people to start adding topic to discuss? 18:28:10 <esmute> this can be a bug, BP, idea, questions, concern, etc 18:28:21 <vipul> i think prior to the meeting.. folks should spend a few minutes going through the bug list.. 18:28:30 <vipul> put the ones they want discussed in the agenda 18:28:53 <vipul> agenda is currently here esmute https://wiki.openstack.org/wiki/Meetings/Cue 18:28:54 <sputnik13> ok, then since we didn't do that for this meeting let's spend a couple minutes to look through the bug list 18:28:56 <vipul> needs to be updated 18:29:21 <sputnik13> starting this week I will send out reminders to review the bug list 18:29:27 <sputnik13> on friday 18:29:46 <vipul> sounds good 18:29:52 <vipul> https://bugs.launchpad.net/cue 18:30:03 <vipul> https://bugs.launchpad.net/python-cueclient 18:30:08 <esmute> Is there a link with bugs that we are targetting? 18:30:43 <davideagnello> I think that is up to us to review first 18:30:47 <davideagnello> how was Cue received in OpenStack summit? 18:30:50 <vipul> if we decide something is important to get fix, it will get the appropriate priority 18:31:17 <vipul> so when we are picking bugs to fix, should look at open bugs with higher priority 18:32:16 <sputnik13> we have quite a few bugs in the New state and Undecided priority 18:32:16 <davideagnello> part of the bug Triage would be to review bug priorities as well? 18:32:35 <sputnik13> there are 2 bugs that are marked CRITICAL but haven't been resolved 18:32:40 <sputnik13> I think one of these has alreadyb 18:33:00 <sputnik13> https://bugs.launchpad.net/cue/+bug/1425206 18:33:00 <openstack> Launchpad bug 1425206 in Cue "Setting debug mode also causes Pecan to run in debug mode" [Critical,New] - Assigned to Vipul Sabhaya (vipuls) 18:33:03 <sputnik13> https://bugs.launchpad.net/cue/+bug/1453351 18:33:03 <openstack> Launchpad bug 1453351 in Cue "rabbitmq cluster goes ACTIVE but is unusable after initial boot" [Critical,New] 18:33:14 <vipul> i believe the first one is fixed.. 18:33:17 <sputnik13> The latter is actually resolved 18:33:17 <vipul> let me find the patch 18:33:35 <sputnik13> ok, good, then they're both closed we just haven't done well with due diligence in closing them 18:33:49 <sputnik13> I'll update the latter, vipul will update the former 18:34:20 <sputnik13> do we have an agreed on definition of what each level means? 18:34:24 <sputnik13> as for as priority? 18:34:30 <sputnik13> err importance 18:34:34 <davideagnello> lets review that 18:34:51 <sputnik13> https://wiki.ubuntu.com/Bugs/Bug%20importances 18:35:04 <sputnik13> there's the official definitions from canonical 18:35:20 <sputnik13> https://dev.launchpad.net/BugTriage 18:35:27 <sputnik13> that might be more appropriate 18:35:47 <sputnik13> actually there's a list for openstack 18:35:49 <sputnik13> #link https://wiki.openstack.org/wiki/Bugs#Importance 18:36:23 <sputnik13> that list looks good to me, and since it's openstack we should abide by what's common for openstack 18:36:30 <davideagnello> that's a good reference 18:36:32 <esmute> +1 sputnik13 18:37:14 <esmute> sputnik13: You and vipul can triage it and then we can discuss next meeting as to how is doing what 18:37:20 <sputnik13> if we all follow those definitions, any one of us should be able to triage it 18:37:35 <sputnik13> sure that works too 18:37:37 <esmute> s/how/who 18:37:51 <sputnik13> but we should do that only for bugs that are externally reported 18:38:17 <sputnik13> any that are reported by someone on the team I think we should add the importance when the bug is filed 18:38:20 <esmute> sputnik13: You mean there are other bugs that are 'internal' :P 18:38:57 <sputnik13> esmute no, I mean any one of the team members could come across a bug and file it for later resolution rather than fixing it right away 18:39:20 <sputnik13> in such cases, the person probably already has a good idea of how critical the bug is, so just add it 18:39:36 <esmute> ok.. that sounds reasonable 18:39:51 <sputnik13> if you have any questions, then talk to one of us... otherwise vipul or I may have to find you and talk to you about the bug in order to triage it 18:40:11 <sputnik13> which I think is a bit of overhead we could do without 18:40:17 <sputnik13> vipul what do you think? 18:40:31 <vipul> sorry multiple convos 18:41:04 <sputnik13> tl;dr, if a team member adds a bug add the importance field along with enough detail to reproduce 18:41:35 <sputnik13> for bugs filed by external parties vipul or I will be responsible for making sure they're triaged in a timely manner 18:41:38 <vipul> yep.. agreed, we should have repro steps wherever we can 18:43:22 <sputnik13> vipul: sorry the thing being discussed is more who should add the importance field (critical, high, medium, low, etc) 18:43:55 <sputnik13> bug reported by cue team, just add it when the bug is reported, bug reported by someone else you or I will triage 18:44:10 <vipul> ah ok.. 18:44:28 <vipul> the person filing the bug indicates importance 18:44:29 <sputnik13> definition of what each importance level means, we're going with the openstack definition https://wiki.openstack.org/wiki/Bugs#Importance 18:45:04 <esmute> sputnik13: And then we can discuss about the bug and its importance during the meeting 18:46:06 <esmute> I just stood up and vipul is talking to someone 18:46:08 <sputnik13> well we can discuss the bug and maybe reclassifying the importance, but what I'm proposing we agree to is to have the importance filled out prior to the meeting if at all possible 18:46:16 <esmute> we can start doing this and see 18:47:12 <esmute> so tl;dr: Each bug filer will indicate the importance as he/her perceives it. We can discuss during meeting its importance and who is fixing it.. 18:47:33 <esmute> any bugs that are file externally, vipul and sputnik13 will triage it 18:47:43 <esmute> sputnik13: is that accurate? 18:47:49 <sputnik13> yes 18:48:06 <vipul> Ok i'm good with that 18:48:55 <vipul> sorry guys i got pulled into another discussion.. 18:48:57 <vipul> fully back now 18:49:06 <sputnik13> also it seems like launchpad bugs aren't "closed" when the patch is merged 18:49:18 <vipul> yes.. that happens only when we cut a release 18:49:18 <sputnik13> "fix committed" still shows when you filter by open bugs 18:49:32 <sputnik13> ok 18:49:38 <vipul> typically the oepnstack release management team goes through and closes those on each miilestone / relelase 18:50:19 <vipul> so what bugs are we bringing up to the irc meetings? assuming things are properly classified 18:50:30 <sputnik13> is that still the process given the changes the milestone/release process? 18:50:51 <vipul> sputnik13: good question :)... we'll see how ironic fares with their decoupled releases 18:51:11 <sputnik13> vipul: good question... hopefully we have so few bugs that we can discuss them all :) 18:51:46 <sputnik13> I think maybe we start with the critical and high classified bugs and any bugs that people want to specifically discuss 18:51:47 <davideagnello> 24 active bugs 18:51:47 <vipul> ok so for the next couple we just walk down 18:52:17 <vipul> davideagnello: that number seems too low :P we surely have more bugs than that 18:52:33 <davideagnello> before the next meeting we should be classifying all undecided bugs 18:52:43 <sputnik13> davideagnello +1 18:52:46 <davideagnello> vipul: haha at least reported bugs 18:53:26 <vipul> #action sputnik13 vipul davideagnello esmute start classifying undecided bugs 18:53:26 <sputnik13> I think all the bugs currently on launchpad were reported by the team 18:53:43 <vipul> yep, and we fixed some without reporting 18:54:06 <sputnik13> #link https://bugs.launchpad.net/cue/+bugs 18:54:22 <sputnik13> on the right hand side there's a filter for "bugs reported by me" 18:55:02 <sputnik13> everyone please add "importance" to any bugs you filed that are still "undecided" 18:55:35 * sputnik13 has 6 of 7 bugs "Undecided" 18:55:35 <davideagnello> in advanced search you can filter by various fields, which is handy 18:55:37 <sputnik13> doh 18:55:59 <davideagnello> haha 18:56:19 <vipul> Ok cool.. we have a plan 18:56:22 <sputnik13> we're almost at time 18:56:27 <vipul> let's touch base next monday 18:56:39 <vipul> anyone have anything else? 18:56:46 <sputnik13> cool, nope I'm good 18:57:26 <davideagnello> that's all for me 18:57:40 <vipul> going once.. 18:57:40 <esmute> lets eat lunch.. im hungry 18:57:54 <vipul> +2 +approved 18:57:59 <vipul> #endmeeting