22:02:18 <vipul> #startmeeting reddwarf
22:02:19 <openstack> Meeting started Tue Jan  8 22:02:18 2013 UTC.  The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:20 <juice> maybe it's just me
22:02:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:23 <openstack> The meeting name has been set to 'reddwarf'
22:02:36 <annashen> cool
22:02:43 <vipul> #topic Action Items
22:03:03 <cp16net> i updated the evesdrop from last time we talked
22:03:09 <vipul> Ok we'll go through the Action items from the previous meeting -- seems like ages
22:03:17 <vipul> #Link http://wiki.openstack.org/Meetings/RedDwarfMeeting
22:03:23 <vipul> #link http://wiki.openstack.org/Meetings/RedDwarfMeeting
22:03:46 <vipul> 1. vipul to file blueprint on quota support in Reddwarf
22:03:54 <dkehn> http://eavesdrop.openstack.org/meetings/reddwarf/2012/reddwarf.2012-12-18-22.00.html
22:03:57 <vipul> Have not filed blueprint yet.
22:04:09 <jcooley> we may have to delay on blueprint filing :(
22:04:16 <vipul> We may still have some legal issues around blueprints, and may need to revert to you guys filing
22:04:27 <vipul> yep
22:04:27 <dkehn> who guys
22:04:27 <jcooley> unless we can get one of the rackspace folks to start it :)
22:04:31 <cp16net> alright what ever we can do :)
22:04:39 <datsun180b> who guys == rax
22:04:47 <dkehn> thx
22:05:07 <vipul> #Action Vipul to file blueprint on quota support in Reddwarf
22:05:17 <vipul> i wonder if capitalization matter.. meh
22:05:28 <vipul> 2. hub_cap SlickNik vipul to discuss w/ mordred the implications of multiple images housed in reddwarf and how we woudl do it
22:05:39 <esp1> I guess I need one for getting testr into reddwarf as well
22:05:56 <cp16net> esp1: yeah that wouldnt hurt
22:06:00 <vipul> esp1: there is an open review started by steveleon
22:06:05 <vipul> that will bring in testr
22:06:12 <jcooley> what is testr?
22:06:20 <esp1> #Action Dan file a blue print for planning testr -> reddwarf
22:06:35 <esp1> testr is the preferred testing framework of openstack?
22:06:36 <jcooley> are we the only openstack project using it?
22:06:45 <esp1> at least that's the word on the street.
22:06:48 <grapex> No, other projects recently switched.
22:06:53 <jcooley> ah, thought openstack's test framework was tempest
22:06:58 <vipul> jcooley: no, it's becoming the replacement for nose
22:07:07 <jcooley> ah.. one level removed.
22:07:23 <SlickNik> coming back to action items...
22:07:28 <vipul> ok for #2, anyone talk to mordred?
22:07:33 <SlickNik> Still been waiting on getting the initial diskimage-builder drop workign, so haven't had a chance to talk to mordred yet.
22:07:59 <jcooley> mordred's in UK this week.  still on irc, just harder to reach
22:08:15 <vipul> #action SlickNik, hub_cap, juice, vipul talk to mordred about housing multiple images (elements) in reddwarf
22:08:21 <SlickNik> Will have to get the conversation started as yet. So this is still needed.
22:08:39 <esp1> I saw mordred walk pass my bus stop the other day if that counts
22:08:40 <juice> we can do this when mordred is back in the states
22:08:45 <jcooley> can you guys talk with robert c/lifeless?
22:08:53 <jcooley> or devananda?
22:08:57 <vipul> how far are we off on getting the first drop of image builder in?
22:08:58 <juice> sure
22:09:16 <dkehn> mordred's in bristol at the moment
22:09:16 <juice> I'll have it wrapped up today (fingers crossed)
22:09:28 <juice> just one issue with mysql password which I need to get from the old process
22:09:32 <juice> …on how it was set
22:09:40 <juice> prior to diskimage_builder
22:09:59 <vipul> #info diskimage builder first-drop shoudl be landing this week
22:10:15 <vipul> ok, next item was for hub_cap, #3 hub_cap to look into slowness issues w/ qemu
22:10:28 <cp16net> i talked with him last week about this
22:10:43 <dkehn> I can take up the issue of the multiple images with Robert and or Monty
22:10:56 <cp16net> and found out that it was just a option that we needed to enable.
22:11:12 <vipul> cp16net: ok, this was the fusion fix?
22:11:15 <cp16net> this sped up the build process for me from about ~10-15 min to ~2-3 min
22:11:33 <cp16net> vipul: yea it was specific for me to vmware fusion
22:11:59 <cp16net> i plan on writing up a doc on the reddwarf-integration README.md so that it will be doced some where
22:12:13 <SlickNik> cp16net: is there something that Virtualbox users can do? If so, I'll talk to you offline :)
22:12:13 <vipul> dkehn: great, let's figure out what their thoughts are for this
22:12:31 <cp16net> SlickNik: maybe i'll let you know offline.
22:12:34 <dkehn> vipul, will do, been talking to Robert pretty regular of late
22:12:45 <SlickNik> cp16net: cool, thanks!
22:12:48 <cp16net> np
22:12:57 <vipul> ok, next item was for me.. vipul to investigate volume_support on/off in fake mode
22:13:01 <cp16net> SlickNik: maybe you can add to the doc that i will update
22:13:11 <vipul> I did not really get muh of a chance to look into fake mode tests
22:13:16 <vipul> will plan on doing that this week
22:13:24 <cp16net> cool
22:13:38 <vipul> cp16net, is this still something to look into? or do your fixes resolve this
22:13:43 <grapex> vipul: Let me know if you need anything.
22:13:59 <cp16net> i dont think this is the same as what i have been working on
22:14:10 <cp16net> i've been working on the real mode tests
22:14:12 <vipul> ok, so there are still questions on where volume_support is..
22:14:25 <vipul> if so, i'll plan to look at it
22:14:40 <esp1> vipul: you probably just need to run the reddwarf tests with tox I think
22:14:49 <cp16net> yeah if i get some time i will peak into the volume support
22:15:02 <vipul> #action vipul, cp16net to look into volume support in fake/real mode
22:15:38 <vipul> that's all the action items we had on the list, anything else we may have forgotten to capture?
22:16:13 <SlickNik> There's a couple of items related to the devstack integration piece I can update on.
22:16:19 <vipul> ok let me change topic
22:16:25 <vipul> #topic Devstack Integration updates
22:16:29 <dkehn> heads up SlickNik making changes to the local.sh file to detect DATABASEPASSWORD not set
22:16:43 <dkehn> and will be changing the messaging
22:16:56 <SlickNik> dkehn, you need to set that in localrc
22:17:01 <dkehn> to conform to the stack\.sh and devstack-vm-gate studff
22:17:03 <SlickNik> we can take this offline.
22:17:16 <dkehn> SlickNik, true, but its its not it hangs
22:17:21 <dkehn> true
22:17:21 <vipul> for those that may have missed the discussion in #openstack-dev, the Devstack folks pushed back on getting Reddwarf Integrated..
22:17:33 <vipul> SlickNik, can you talk about the new approach
22:17:37 <dkehn> did they give a reason?
22:17:52 <SlickNik> devstack is getting too big and unmaintainable.
22:18:02 <dkehn> lol, no kidding
22:18:05 <SlickNik> with lots of components.
22:18:07 <vipul> they don't want non-core projects
22:18:09 <cp16net> and harder to test
22:18:20 <SlickNik> So they don't want non-core components included.
22:18:37 <SlickNik> But they have a hook where they run the local.sh script if it exists.
22:19:04 <SlickNik> So they suggested refactoring all the changes into local.sh and using that option.
22:19:35 <SlickNik> They local.sh to use is checked in under scripts under the reddwarf-integration project.
22:19:40 <jcooley> well, it's one step closer...
22:19:53 <cp16net> yeah i think that makes sense and gives us more control over how things work in side of our project
22:19:58 <jcooley> can we get it included into devstack/samples?
22:20:03 <vipul> #info Devstack team pushed back on full-on integration of Reddwarf, in favor of local.sh approach
22:20:18 <cp16net> although there is another side that make it if they change things in devstack it can break us without noticing
22:20:23 <SlickNik> jcooley: I've pinged the devstack devs about that, but still waiting on an answer
22:20:33 <SlickNik> so will update you guys on that.
22:20:40 <vipul> yea, would be nice to be visible in devstack somewhere
22:20:48 <vipul> SlickNik, what does it mean for redstack?
22:20:49 <SlickNik> #agreed
22:21:08 <vipul> still remains a wrapper, but much smaller?
22:21:18 <jcooley> cp16net: can you refresh me on the diff between reddwarf & reddwarf-integ?
22:21:42 <SlickNik> there's still some cleaning/refactoring that is needed for redstack to clean it up.
22:21:55 <SlickNik> Yes, it would make it smaller/cleaner.
22:22:06 <cp16net> jcooley: reddwarf is the code base and rd-int is the setup/conf/testing part
22:22:22 <vipul> jcooley: reddwarf is our core source tree, only unit tests -- redddwarf-int is where redstack and integration tests live
22:22:43 <SlickNik> jcooley: also redstack is a script in reddwarf-int
22:23:24 <jcooley> ah. kind of get it.  wondering if some of this can go to reddwarf? but maybe I'm not seeing this clearly.
22:23:34 <grapex> reddwarf-int is like devstack + tests for reddwarf.
22:23:45 <SlickNik> Right now I'm working with clarkb on configuring the gate to run devstack-vm-gate with a build of reddwarf.
22:24:01 <SlickNik> will look at refactoring redstack (reddwarf-int) soon after.
22:24:22 <vipul> nice
22:24:23 <jcooley> cool.  just looking at the model we present to non-rd'ers.
22:24:27 <SlickNik> #action Slicknik working on configuring gate to run devstack with reddwarf's local.sh
22:24:38 <vipul> SlickNik, will the gate be on Reddwarf or Rd-int or both
22:25:07 <dkehn> SlickNik, we need to discuss devstack-vm-gate
22:25:10 <SlickNik> Working on putting it on Reddwarf.
22:25:31 <SlickNik> We can have it on rd-int if we think it's necessary as well.
22:25:53 <SlickNik> Wanted to discuss that with grapex, esp since I'm not sure which tests we want to run for which gate.
22:26:09 <esp1> I've been wondering myself
22:26:13 <vipul> SlickNik, we need some gates to RD-Int
22:26:16 <SlickNik> But it seems legit to have it for both.
22:26:18 <vipul> since there really aren't any
22:26:20 <SlickNik> Yeah.
22:26:23 <cp16net> i would think we should run the real mode tests if we can
22:26:25 <SlickNik> right now it's a no-op.
22:26:42 <vipul> #agree with cp16net, run full on real mode tests
22:26:59 <cp16net> they are *working* right now for me :)
22:27:01 <esp1> yeah if we are saying time is not an issue for running the tests I guess real mode would catch more stuff
22:27:23 <SlickNik> #agreed
22:27:24 <SlickNik> #action SlickNik to look at updating both reddwarf and reddwarf-int gates.
22:27:24 <vipul> #info devstack-vm-gate will be on both Reddwarf and Reddwarf-Int
22:27:31 <cp16net> yes but make sure we run through the fake-mode first because it should catch all the silly mistakes first
22:27:54 <esp1> makes sense
22:27:58 <SlickNik> okay.
22:27:58 <datsun180b> like pep 8 :3
22:28:15 <esp1> do you think we should pull on the simple-test groups in favor now?
22:28:27 <SlickNik> dkehn: will sync with you on the devstack-vm-gate offline after meeting
22:28:35 <dkehn> SlickNik, k
22:28:57 <vipul> esp1: you mean get rid of that group?
22:29:14 <vipul> seems like blackbox is now working, so switch to that?
22:29:16 <esp1> vipul: yeah sorry, bad sentence
22:29:29 <jcooley> slicknik: re- tests. probably want one gate (ie one set of tests that's run from multiple triggers) unless there's a clear subset that would need to be run in some cases.
22:30:17 <esp1> vipul: I'll fly the idea around and see what the consensus is.
22:30:21 <SlickNik> jcooley: That makes sense. I'm not aware of any subsets at the moment.
22:30:42 <vipul> SlickNik, i think just run 'blackbox' group to start with
22:30:57 <cp16net> #agreed
22:31:01 <datsun180b> right
22:31:02 <SlickNik> so blackbox in fake and then blackbox in real?
22:31:27 <vipul> yep, if that's possible
22:31:40 <grapex> We may be able to run blackbox in fake for multiple configurations as well, such as with volume support turned off.
22:32:15 <SlickNik> good point, grapex. I'll sync with you and esp to see what configs make sense for the gate tests.
22:32:17 <cp16net> yeah that shouldnt be to difficult... just changing up the test.conf
22:32:21 <vipul> grapex: yea, we should toggle config, maybe only do that in fake
22:32:36 <vipul> may take too long in real mode to go through every permutation
22:32:54 <vipul> ok, anything else for Devstack?
22:33:07 <SlickNik> That's pretty much all I had on the devstack integration piece.
22:33:07 <vipul> if not..
22:33:14 <vipul> #topic Testing Updates
22:33:38 <cp16net> great news
22:33:49 <cp16net> i've fixed lots of issues :)
22:34:04 <esp1> yay!
22:34:12 <vipul> gotta get that basket of fruit approved! :)
22:34:16 <esp1> thx!
22:34:19 <SlickNik> yeah, nice work!
22:34:34 <cp16net> i made blackbox run all the way through and ran it multiple times now
22:34:46 <vipul> w/o rebuildling?
22:34:56 <cp16net> yeah no rebuild
22:35:04 <cp16net> just make sure that there are no instances alive
22:35:06 <esp1> cp16net: I'm just about to grab the latest
22:35:19 <cp16net> yeah and esp1 has been running it through as well
22:35:25 <vipul> sweet
22:36:06 <vipul> are thre more patches you need to push up? or should we start merging the existing one
22:36:07 <cp16net> one weird issue i found was when calling the confirm resize method to nova right after the instance changes to verify_resize state it fails
22:36:23 <cp16net> i think there is some kind of race condition there so i put a sleep for 5 seconds
22:36:31 <cp16net> this seems to solve it for now
22:36:46 <cp16net> vipul: there are 2 patches
22:36:49 <cp16net> 1 to reddwarf
22:36:55 <cp16net> and 1 to reddwarf-integration
22:37:07 <vipul> ok, i've only seen the one you had for rd-i
22:37:17 <cp16net> #info reddwarf https://review.openstack.org/#/c/18962/
22:37:33 <vipul> there we go
22:37:34 <cp16net> #info reddwarf-integration https://review.openstack.org/#/c/19241/
22:38:18 <vipul> ok cool... let's try to get these merged today if we can
22:38:22 <SlickNik> cp16net: yeah, I saw that. Almost commented that your log message says to "wait a sec", but you sleep for 5. :P
22:38:41 <cp16net> i'd like everyone to look it over them and get them in
22:38:44 <SlickNik> working my way through the review.
22:39:01 <cp16net> awesome let me know if anyone has q's
22:39:25 <vipul> other testing updates... annashen is basically adding a bunch for guestagnet
22:39:46 <annashen> right, i did
22:40:17 <cp16net> awesome
22:40:25 <vipul> we're also going to start adding 'unit tests' for reddwarf, sort of method-levle tests for the models, controllers, etc
22:40:36 <cp16net> can we run converage on it?
22:40:44 <cp16net> so we can see whats covered?
22:41:08 <cp16net> grapex/datsun180b: didnt you do this at some point?
22:41:26 <vipul> we did this before as well, i'd have to find where it is
22:41:30 <grapex> Yes, the current tests will generate a coverage report with "tox -ecoverage"
22:41:34 <datsun180b> Coverage? tox -ecover
22:41:36 <esp1> I think we were just eyeballing code and were looking to write tests that directly test the model layer etc
22:42:01 <grapex> But ultimately it'd be cool to have two sets of coverage, one just for the unit tests.
22:42:05 <esp1> datsub180b: yeah that still works.  we ran that at one point
22:42:08 <vipul> grapex, datsun180b, cp16net: what are your thoughts on sqllite based tests?
22:42:25 <esp1> grapex: yeah that's what I think we are shooting for
22:42:25 <vipul> basically to test the models, we don't do this now
22:43:02 <grapex> vipul: I say we use sqlite from unit tests tactically. If that makes it easier than using mock, and the code is easy to read, I think we should avail ourselves of it.
22:43:24 <datsun180b> Gosh, I was going to say the exactly the same thing but he typed quicker
22:43:26 <grapex> I think in some cases using sqlite can get in the way - like datsun180b's recent pull request to change the resize code paths, there using mocks was easier.
22:44:11 <dkehn> guys have to step out for a bit, will read the trasscript later.
22:44:36 <vipul> grapex: sounds good, i think it may make sense for things taht actually read from the DB to be tested against a db
22:44:45 <esp1> grapex: yeah that could work.  I think I have a task to look into that further.  for sure some of the tests are already using sqlite in fake mode
22:44:47 <datsun180b> I'd appreciate having consistent/reusable entries in a handy sqlite database (like instances) instead of having to mock out everything, but there are cases where it's just easier to mock something and take off running with it
22:44:48 <vipul> but yes, so we use both approaches where appropriate
22:46:06 <vipul> ok, anything else around testing?
22:46:09 <cp16net> yeah i agree if it gives us better coverage i am for it
22:46:22 <SlickNik> #info Use either sqllite or mock for tests, tactically choosing whichever is appropriate
22:46:44 <esp1> cool, I was gonna fold all this into the blue print for using testr if that works
22:46:56 <vipul> esp1: Yep, go for it
22:47:08 <SlickNik> sounds good.
22:47:17 <vipul> #action esp1 to add unit testing details to testr blueprint sqlite vs fakes
22:47:17 <esp1> use of mocks, sqlite3 etc to test models and friends
22:47:22 <esp1> thx
22:47:28 <vipul> #topic Image Builder Updates
22:47:46 <vipul> I think we touched on this a bit earlier
22:47:50 <vipul> juice?
22:48:34 <SlickNik> yeah, he mentioned that he was really close to having this done and checked in.
22:49:21 <vipul> K, looks like we should have Percona image soon after
22:49:24 <SlickNik> was having one last issue with the initial myssql password that he was close to figuring out.
22:49:29 <vipul> once we figure out where to put it
22:50:16 <vipul> SlickNik, is image building part of local.sh?
22:50:22 <vipul> or is that still going to be done via Redstack
22:50:44 <SlickNik> It's not yet part of local.sh.
22:51:36 <SlickNik> But if we want to run any real tests involving the instances/guest agent, it will have to be.
22:52:04 <SlickNik> So once juice is done with building it into redstack, I will have to integrate it into local.sh.
22:52:13 <vipul> #info Image Building will be integrated into local.sh
22:52:18 <vipul> cool
22:52:30 <vipul> any other items around Image building?
22:52:41 <SlickNik> I think we have real mode tests that depend on the image being built and uploaded to glance, correct?
22:52:54 <juice> sorry back now
22:53:09 <juice> updates were reported earlier
22:53:17 <juice> done with support task and getting back to that now
22:53:51 <vipul> SlickNik: yes, thre are tests that spin up instances via the mysql image
22:54:33 <vipul> #topic Open Discussion
22:54:39 <cp16net> Ran 112 tests in 1166.799s
22:54:57 <esp1> cool :) I'm running them now.
22:55:13 <vipul> is that all of em?
22:55:15 <esp1> waiting for guest
22:55:21 <cp16net> all blackbox tests
22:55:33 <SlickNik> neato.
22:55:51 <vipul> the longest ones are the ones that wait for the guest to come up?
22:56:01 <cp16net> yup
22:56:03 <cp16net> always
22:56:07 <esp1> pretty much
22:56:16 <SlickNik> makes sense.
22:56:32 <cp16net> because its waiting on nova to "do stuff"
22:56:40 <esp1> it's good for day dreaming or going to meetings though
22:56:53 <vipul> lol, or coffee
22:56:53 <cp16net> hah yea
22:57:07 <cp16net> sleeping
22:57:09 <SlickNik> heh, I don't know if that's enough time for a meeting, esp1 :P
22:57:24 <vipul> One thing collectively we could do better is reviews :)
22:57:30 <cp16net> play a game of foosball
22:57:40 <vipul> we should +1 or +2 thing more frequently
22:58:10 <cp16net> yeah its not that bad when there are only like 5 reviews
22:58:41 <esp1> yeah foosball would be great.  I won the tournament one year when I work at the UW.
22:58:43 <cp16net> anyone have abandon priv?
22:58:55 <SlickNik> abandon priv?
22:58:57 <cp16net> https://review.openstack.org/#/c/17133/
22:59:02 <cp16net> abandon that review
22:59:08 <vipul> I think if it's your own, you can abandon
22:59:13 <vipul> kaganos: ^^
22:59:23 <vipul> can you click 'abandon'?
22:59:31 <kaganos> i'll try ...
22:59:33 <SlickNik> oh, I see.
22:59:43 <cp16net> thanks!
22:59:43 <cp16net> :)
23:00:08 <vipul> ok, anything else?
23:00:13 <vipul> right on time..
23:00:26 <SlickNik> nope, all good here.
23:00:37 <cp16net> good to go home...
23:00:39 <cp16net> :)
23:00:50 <vipul> is hub_cap on vacay?
23:01:20 <cp16net> i dunno where he disappeared to
23:01:28 <cp16net> i thought he was going to be back today
23:01:32 * cp16net shrugs
23:01:47 <vipul> fair 'nuf
23:01:52 <vipul> we're done
23:01:54 <vipul> #endmeeting