18:02:36 <sputnik13> #startmeeting cue
18:02:38 <openstack> Meeting started Mon Jun 15 18:02:36 2015 UTC and is due to finish in 60 minutes.  The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:41 <openstack> The meeting name has been set to 'cue'
18:02:47 <sputnik13> role call~
18:03:02 <abitha> here
18:03:03 <dkalleg> 1
18:03:47 <sputnik13> we're missing a couple people
18:04:29 <vipul> o/
18:04:50 <sputnik13> someone go kick esmute
18:04:53 <sputnik13> :)
18:05:29 <sputnik13> #topic Open Action Items
18:05:33 <sputnik13> #link http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-06-08-18.02.html
18:06:01 <davideagnello> 2
18:06:11 <sputnik13> o/
18:06:11 <esmute> Hello!
18:06:23 <sputnik13> ok we have quorum, let's get to the agenda
18:06:47 <sputnik13> #info AI #1, davideagnello to follow up on rally job merge
18:06:55 <sputnik13> davideagnello?
18:07:05 <davideagnello> yes, the job is merged
18:07:16 <sputnik13> cool, does it look to be working?
18:07:25 <sputnik13> working as in executing the rally job?
18:07:37 <davideagnello> I don't see it in our patches yet
18:07:47 <sputnik13> that sounds like a no
18:07:56 <vipul> it's an experimental job
18:07:59 <sputnik13> do we need a new patch before it shows up?
18:08:10 <sputnik13> experimental is fine, but shouldn't it show up somewhere?
18:08:12 <esmute> you can run it with 'check experimental'
18:08:16 <vipul> you have to comment 'check experimental'
18:08:18 <sputnik13> ic
18:08:31 <davideagnello> ok
18:08:32 <vipul> i saw Sergey tried to run it on one of my patches
18:08:38 <vipul> but it failed immediately
18:08:42 <davideagnello> I noticed that too but it failed
18:08:47 <sputnik13> that doesn't sound good
18:08:50 <vipul> so it's definitely not set up correctly
18:09:01 <sputnik13> ok, sounds like we need more followup then
18:09:15 <vipul> yea follow up with Sergey or fix the job
18:09:45 <davideagnello> what is Sergey's handle or irc?
18:09:47 <sputnik13> #action davideagnello to follow up on rally job merge, work with Sergey to fix job and ensure it runs on some patches
18:10:06 <sputnik13> #info rally job merged but is failing right away
18:11:06 <sputnik13> ok, next?
18:11:15 <sputnik13> #info vipul and sputnik13 to review https://review.openstack.org/#/c/187620/ and +1 it
18:11:47 <vipul> davideagnello: just ask someone in the rally room
18:12:03 <davideagnello> vipul: ok
18:12:06 <sputnik13> oh this is directly related
18:12:15 <sputnik13> AI#2
18:12:16 <vipul> #done
18:12:20 <sputnik13> yup
18:12:33 <esmute> who is doing this work?
18:12:33 <sputnik13> #info https://review.openstack.org/#/c/187620/ has merged, directly related to AI#1
18:12:35 <esmute> Serget?
18:12:41 * sputnik13 elects esmute
18:12:42 <sputnik13> :)
18:13:14 <davideagnello> sputnik13: merged on June 10th
18:13:18 <esmute> if the rally test is failing during the devstack install, you can look at the integration tests setup
18:13:26 <esmute> i had to do some things to get devstack up and running
18:14:06 <esmute> https://github.com/stackforge/cue/tree/master/tests
18:14:17 <esmute> look at the gate_hook.sh, pre_test_hook.sh
18:14:28 <esmute> these will setup devstack
18:15:10 <sputnik13> davideagnello can you take a look at these and follow up with esmute if you have issues/questions?
18:15:36 <vipul> Yea if there are certain things that we need to do that are unique then Sergey will not know those
18:15:44 <davideagnello> sputnik13: this is related to get the rally job running, correct?
18:15:47 <vipul> we're probably better off fixing the job
18:15:47 <sputnik13> yes
18:15:59 <davideagnello> sputnik13: already noted :)
18:16:03 <sputnik13> ok, good
18:16:12 <sputnik13> vipul the action is to "work with Sergey" so I think we're covered ;)
18:16:21 <sputnik13> next AI?
18:16:41 <sputnik13> #info AI #3 esmute to classify https://bugs.launchpad.net/cue/+bug/1439329 and https://bugs.launchpad.net/cue/+bug/1439330
18:16:43 <openstack> Launchpad bug 1439329 in Cue "Cluster goes to ERROR when creating it with flavor passed by name" [Undecided,New]
18:16:44 <openstack> Launchpad bug 1439330 in Cue "Cannot delete cluster by name" [Undecided,New]
18:17:05 <esmute> sputnik13: i tried to do it but it was grey out for me
18:17:11 <sputnik13> these two issues are still in "Undecided"
18:17:28 <sputnik13> esmute: do you not get the edit button?
18:17:36 <vipul> esmute: you are in cue-drivers
18:17:39 <esmute> ok it is working now
18:17:39 <vipul> should work for you
18:17:50 <esmute> it didnt work last week when i tried.. hmm
18:18:09 <sputnik13> right, when you mentioned that vipul added you to cue-drivers
18:18:15 <vipul> Yep
18:18:16 <esmute> ok.. i just classified them as medium since we can still reference them by their id
18:18:34 <sputnik13> it needs to meet the agreed definition
18:18:45 <vipul> so esmute does nova actually support booting vms by flavor name?
18:18:56 <esmute> it does vipul
18:19:05 <vipul> are you sure it's not a nova-client thing?
18:19:09 <esmute> you can pass in m1-small or something like that as teh flavor
18:19:14 <esmute> ohh hmm
18:19:24 <esmute> could be a nova client thing :p
18:19:33 <sputnik13> esmute: https://wiki.openstack.org/wiki/Bugs
18:19:34 <esmute> i can try the rest API and see
18:20:01 <sputnik13> it's not a bug if it's not a supported feature
18:20:38 <vipul> afaict, the nova api accepts a flavorRef
18:20:42 <vipul> which is.. "The flavor reference for the desired flavor for your server instance.
18:20:42 <vipul> Specify as an ID or full URL."
18:20:45 <esmute> ok.. ill check whether it is a bug or not... ill check the nova api and see if it does support referencing flavor by name
18:20:47 <sputnik13> to me this is more a feature, a minor one but a feature
18:20:54 <vipul> #link http://developer.openstack.org/api-ref-compute-v2.html
18:21:09 <esmute> if its not a bug in cue, then it is a bug in cue-client
18:21:21 <vipul> it's a nice-to-have
18:21:36 <sputnik13> so it's more a wishilist item I think
18:21:57 <esmute> it is.. but dont we want to have nova as our role model for the client?
18:22:43 <vipul> does the openstackclient do this
18:22:46 <esmute> meaning, if nova references flavor by name or delete resources by name, cue client should too
18:22:47 <sputnik13> I think we should definitely have these but a lack of a feature is not a bug, a bug is a failure of a feature
18:23:19 <esmute> So should this be a BP then?
18:23:28 <davideagnello> that makes sense
18:23:34 <sputnik13> no, it doesn't need to be a BP, it's small enough i don't think we need that much formality
18:24:05 <sputnik13> but whether something's a defect vs a feature, we should be consistent
18:24:15 <davideagnello> do we just track it as a "wish list" item?
18:24:17 <esmute> so what do these ticket need to be made correct?
18:24:23 <sputnik13> defect = bug, minor feature = wishlist, major feature => bp
18:24:29 <sputnik13> something like that?
18:24:40 <sputnik13> esmute there's a "wishlist" category
18:24:45 <esmute> yeah i just saw that
18:24:47 <sputnik13> you can classify it as thus
18:24:50 <esmute> ok..
18:24:55 <sputnik13> just don't leave it "undefined"
18:25:54 <sputnik13> are we good with this AI?
18:26:03 <davideagnello> +1
18:26:03 <esmute> ok.. i just classified it as wishlist
18:26:14 <sputnik13> ok, thanks
18:26:20 <sputnik13> #info AI #4 sputnik13 to harass josh barry to classify https://bugs.launchpad.net/cue/+bug/1450931
18:26:21 <openstack> Launchpad bug 1450931 in Cue "Readme doc link incorrect" [Undecided,New]
18:26:47 <sputnik13> I dropped the ball on that, I will get it reclassified and close the loop with Josh
18:27:13 <sputnik13> #action sputnik13 to classify https://bugs.launchpad.net/cue/+bug/1450931 and talk with Josh about classifying submitted bugs
18:27:33 <sputnik13> #info AI #4 sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:27:57 <sputnik13> this one has not started yet, I will be working on it this week and should have more information next week
18:28:05 <sputnik13> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:28:23 <sputnik13> ugh I'm messing up the numbers :(
18:28:27 <sputnik13> that was AI #5 not 4
18:28:47 <sputnik13> wish there was a meetbot feature for referring to AIs for closure
18:28:58 <sputnik13> #info AI #6 davideagnello to add detail to https://blueprints.launchpad.net/cue/+spec/rally-scenario-tests based on existing rally tests and gate testing things in process
18:29:13 <sputnik13> davideagnello did you have a chance to close this out?
18:29:47 <sputnik13> I don't see any updates to it from last week, does it still make sense to do this?
18:29:52 <davideagnello> I added some, at what level do we need?
18:30:28 <sputnik13> not sure, vipul do you have thoughts on how much detail we should have in BP?
18:30:42 <davideagnello> sputnik13: I referenced the two patches that where submitted for this blueprint
18:30:58 <vipul> for things that are already done.. i don't know if it makes sense to go back and add a lot of detail
18:31:09 <sputnik13> ok, we'll call that done then?
18:31:11 <vipul> davideagnello: did you add those or did that happen via gerrit
18:31:16 <vipul> i hope it happened automatically
18:31:22 <vipul> yea i think so
18:31:26 <davideagnello> I added it
18:31:48 <davideagnello> blueprints don't seem to link automatically because gerrit looks in openstack vs. stackforge
18:31:51 <vipul> davideagnello: ok.. then something might be broken with how we refernced the bp in the commit message
18:32:01 <sputnik13> right...
18:32:03 <davideagnello> vipul: ok
18:32:10 <vipul> davideagnello: ok that might be it
18:32:13 <sputnik13> yeah blueprint links are all kinds of broke for stackforge projects
18:32:28 <sputnik13> when I click a link even in gerrit it doesn't take you to the correct bp page
18:32:50 <sputnik13> because it assumes openstack not stackforge
18:33:04 <davideagnello> I think for now we should update blueprints with patches as we commit them for now..
18:33:27 <sputnik13> #info davideagnello added links to implementation patches to BP
18:33:55 <sputnik13> ok, let's go on we're halfway through the meeting with just AIs :(
18:34:05 <sputnik13> #info AI #7 davideagnello to add link and information to v1 API in https://blueprints.launchpad.net/cue/+spec/v1-api
18:34:33 <sputnik13> davideagnello that doesn't look done, can you add the link and any necessary information?
18:34:38 <davideagnello> sputnik13: didn't do that one..
18:34:48 <davideagnello> yes, I will dig back and get those references in
18:34:50 <sputnik13> #action davideagnello to add link and information to v1 API in https://blueprints.launchpad.net/cue/+spec/v1-api
18:35:19 <sputnik13> #info AI #8 sputnik13 reproduce bug that fails to rollback a cluster create and file a bug with the details
18:35:54 <sputnik13> so, the cluster rollback wasn't happening because of a taskflow feature we were using improperly
18:36:28 <sputnik13> retry controllers that come with taskflow "out of the box" don't support "REVERT_ALL" on failure which is what we need in order for a complete rollback to happen
18:37:01 <sputnik13> so actually, rather than we were using it improperly, it's more accurate to say we didn't understand the ramifications fully
18:37:27 <sputnik13> a patch was submitted to taskflow to add a flag to retry controllers to choose REVERT_ALL vs REVERT on failure
18:38:00 <sputnik13> #link https://review.openstack.org/#/c/190078/
18:38:10 <davideagnello> sputnik13: makes sense
18:38:22 <sputnik13> that has merged, so as soon as a release with that patch is made we will move the following patch in to the code base
18:38:31 <sputnik13> https://review.openstack.org/#/c/190081/
18:38:36 <sputnik13> #link https://review.openstack.org/#/c/190081/
18:39:01 <sputnik13> #action sputnik13 to track release of new taskflow version and ensure https://review.openstack.org/#/c/190081/ is merged
18:39:28 <sputnik13> ok last AI from last meeting
18:39:36 <sputnik13> #info AI #9 vipul davideagnello esmute abitha dkalleg to check that existing bugs have the correct classification
18:39:59 <sputnik13> not going to go over those individually, please all make sure you go through your bugs if you haven't already and make sure they're correctly classified
18:40:00 <davideagnello> sputnik13: went over my set
18:40:10 <sputnik13> cool
18:40:35 <sputnik13> I'm not going to mention that one again, we'll just let it all fall out from this point forward while reviewing bugs
18:41:05 <sputnik13> questions or anything anyone wants to raise about the Action Items?
18:41:35 <sputnik13> no? next topic
18:41:48 <vipul> i'm good..
18:41:57 <sputnik13> #topic Tempest gate
18:42:19 <sputnik13> that's not on our agenda but I'm adding it because there was a vote on it last week to postpone a decision until today
18:42:39 <sputnik13> esmute davideagnello can you update us on the tempest gate?
18:42:43 <esmute> we have been adding more fixes to stabilize the test
18:42:51 <sputnik13> what's the failure/success rate, is it ready to mege, etc
18:42:58 <sputnik13> s/mege/merge
18:43:27 <sputnik13> esmute: when was the last fix?
18:43:29 <esmute> since last friday, it has failed around 5 times out of 18 runs
18:43:55 <sputnik13> do we know what is causing the failures?  Is it anything under our control?
18:43:55 <esmute> but i feel that it is more stables than that since we have added some fixes last week
18:44:33 <sputnik13> but if it's 5/18 since friday, are you saying there were changes merged over the weekend?
18:44:46 <esmute> not really.. the test was failing becasue the cue cluster didnt come active in 30 mins... so i added a function to grab the logs from the rabbitmq as well as console-log from nova
18:44:51 <esmute> this was merged last week.
18:45:19 <esmute> there hasnt been that many patches in stackforge/cue recently to see how stable it has become
18:45:43 <davideagnello> do the logs have hints on what is wrong?
18:45:47 <esmute> 5/18 was the run done by https://review.openstack.org/#/c/187273/
18:45:47 <sputnik13> well, I think the question is does the tempest job do what it's supposed to
18:45:48 <sputnik13> not is cue stable
18:46:01 <sputnik13> cue stability is something that the tempest job is supposed to tell us about
18:46:27 <vipul> i think we want to get the job passing consistently before i'd make it a gate to merge
18:46:44 <vipul> if it's because cue isn't stable.. then we should address those issues
18:46:50 <sputnik13> so the decision on whether to make the tempest gate voting or not should be based on our confidence in the job doing what it's supposed to
18:46:56 <vipul> if we make it voting and it's not stable.. it will be very counter productive
18:46:57 <esmute> since we havent had that many patches in, i will continue to manually do recheck
18:47:23 <sputnik13> vipul but wouldn't that make it a forcing function...  and that's the point of the gate isn't it?
18:47:42 <esmute> now that we have added the logs to the tests, we should get more information about why the cluster fails to become active
18:48:03 <vipul> yes it is but we'll essentially block all non-related work as well that's teh concern
18:48:46 <esmute> what is your impressions in your patches?
18:48:47 <sputnik13> vipul I agree, but I'm also not 100% confident in the gate yet either
18:48:52 <esmute> has it been failing a lot?
18:49:01 <vipul> you think the gate itself is the issue?
18:49:02 <esmute> keep in mind that we have added some fixes recently
18:49:14 <vipul> i'd like to find out why it's failing 5/18 times
18:49:15 <sputnik13> vipul I think we don't know is the thing
18:49:34 <esmute> we have ways to get the logs now
18:49:38 <sputnik13> I'm wondering whether the default resource limits are affecting the tests
18:49:42 <esmute> and ill keep running the test manually
18:50:14 <vipul> ok as it's failing please try to dig into why.. otherwise this will lead us nowhere
18:50:19 <esmute> guys, that 5/18 was from june 1
18:50:40 <vipul> ok can you rebase to now, and let's run it 20 times and see what the current state is
18:50:41 <esmute> and i havent been manually triggering the test that much recently
18:50:47 <sputnik13> ok, you said since last friday...
18:50:56 <esmute> and we dont have enough patches.
18:51:06 <vipul> we don't need patches to exercise this
18:51:06 <sputnik13> let's rebase as vipul said and recheck 20 times
18:51:10 <esmute> sputnik13: sorry.. that was a mistype
18:51:25 <esmute> since friday i have run it twice and they both passed
18:51:30 <sputnik13> esmute we've said before that we're going to use the check job to just run recheck manually
18:51:38 <sputnik13> not relying on new patches
18:51:46 <esmute> 5/18 is from the begining until friday
18:52:10 <sputnik13> because the number of patches we have are so low that wouldn't be a good indicator of whether the tempest job runs in a reliable manner
18:52:26 <esmute> sputnik13: correct.. i've been doing that but i havent done it since recently due to vacation and other stuff
18:52:37 <vipul> esmute: i think we need new data, let's rebase and recollect data
18:52:40 <esmute> and recently, we have just added a bunch of fixes
18:53:17 <vipul> esmute: good?
18:53:28 <sputnik13> ok, just so we're all on the same page...
18:53:33 <sputnik13> we're talking about https://review.openstack.org/#/c/187273/
18:53:35 <esmute> yes . that is what im proposing too
18:53:38 <sputnik13> let's not talk about new patches
18:53:48 <esmute> sputnik13: yes...
18:53:59 <sputnik13> the action now is to rebase https://review.openstack.org/#/c/187273/
18:54:10 <sputnik13> then run recheck on it at least 20 times this week
18:54:33 <sputnik13> and for any failed runs assess what is causing the failure
18:54:47 <sputnik13> is this accurate?
18:55:21 <vipul> #agree
18:55:22 <esmute> yeah
18:55:25 <esmute> #agree
18:55:49 <sputnik13> #action esmute to rebase https://review.openstack.org/#/c/187273/ then run a minimum of 20 rechecks on it by 6/22
18:56:25 <sputnik13> #action esmute to present success/failure rates on tempest checks for https://review.openstack.org/#/c/187273/ and root cause analysis for failures
18:56:51 <sputnik13> we should have closure on this, it's been on the list for a while now
18:57:17 <sputnik13> we have 3 minutes left
18:57:31 <esmute> yes.. i started it in at the beginning of the month
18:57:54 <sputnik13> so we can't really talk about bugs or have open discussion today :(
18:58:10 <sputnik13> starting next meeting we need to try and blast through AIs more quickly
18:58:11 <esmute> ill try to be on top of this but if you see that a run finished and there is no 'recheck no bug', feel free to add it to https://review.openstack.org/#/c/187273/
18:58:39 <sputnik13> esmute: ok
18:59:18 <sputnik13> abitha dkalleg you're both too quiet
18:59:23 <sputnik13> :P
18:59:29 <dkalleg> Just reading along :)
18:59:35 <abitha> me too
18:59:46 <dkalleg> Havn't been part of any AIs
18:59:47 <sputnik13> you can at least agree or disagree to things :P
19:00:10 <vipul> time's up
19:00:18 <sputnik13> I don't want this to be meetings about AIs, so starting next meeting I will try and just push through them as quickly as possible
19:00:28 <vipul> +1
19:00:34 <dkalleg> #agree
19:00:46 <esmute> lunch time!!
19:00:47 <sputnik13> anyone who has AIs should come having reviewed their list beforehand
19:00:48 <sputnik13> so we can blast through
19:01:02 <sputnik13> good?
19:01:10 <sputnik13> yeah #lunchtime
19:01:11 <sputnik13> :)
19:01:17 <sputnik13> thanks everyone
19:01:19 <sputnik13> #endmeeting