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