21:59:53 <hub_cap> #startmeeting reddwarf
21:59:54 <openstack> Meeting started Tue Mar  5 21:59:53 2013 UTC.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:59:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:59:57 <hub_cap> come one come all
21:59:58 <openstack> The meeting name has been set to 'reddwarf'
22:00:17 <esp1> hello
22:00:55 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting
22:01:07 <hub_cap> #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-26-21.59.html
22:01:23 <SlickNik> woot
22:02:13 * hub_cap starts a timer for 60s
22:02:22 <SlickNik> Give people a minute or so to show up?
22:02:24 <SlickNik> sounds good.
22:02:37 <hub_cap> :)
22:03:00 <hub_cap> import time
22:03:17 <vipul> here
22:03:18 <vipul> sorry late
22:03:28 <hub_cap> np we havent started yet
22:03:47 <SlickNik> no problem, still waiting maybe 15 seconds.
22:03:51 <steveleon> hello
22:04:06 <hub_cap> timers done
22:04:27 <hub_cap> vipul: yer up w/ the update snapshots wiki
22:04:54 <vipul> crap, nope.. was going to do it today but stuck in meetings
22:04:59 <hub_cap> lol so did we
22:05:04 <hub_cap> its been meeting hell today
22:05:05 <vipul> #action vipul to update snapshot wiki w/snapshots deleted in swift
22:05:22 <hub_cap> SlickNik: secgroups extension
22:05:38 <SlickNik> Still working on it.
22:05:51 <SlickNik> Got the object model done, working on the controllers.
22:05:53 <hub_cap> cool. had a chance to do any work w/ the API?
22:05:57 <hub_cap> as in the api docs
22:06:04 <hub_cap> (im covering your other action item)
22:06:05 <SlickNik> Yes, I've uploaded a review to gerrit.
22:06:06 <hub_cap> OH NOEZ
22:06:11 <hub_cap> #topic action items
22:06:15 <SlickNik> whoops.
22:06:17 <SlickNik> lol
22:06:17 <kagan> btw, quick Q, when is the time to discuss out of band issues ?
22:06:30 <hub_cap> kagan: the end of meeting durin open discussion
22:06:35 <kagan> ok
22:06:35 <SlickNik> usually at the end of the meeting, kagan.
22:06:49 <SlickNik> #link https://review.openstack.org/#/c/23618/
22:06:53 <hub_cap> everyone go in and update thier watchd projects!!
22:07:18 <datsun180b> #link https://review.openstack.org/#/q/is:watched+status:open,n,z
22:07:34 <esp1> datsun180b: thx!
22:07:35 <SlickNik> I've marked that as work in progress since I still need to put in the request-response snippets.
22:07:37 <hub_cap> datsun180b: assuming database-api is in your watched projects list ;)
22:07:40 <hub_cap> SlickNik:  kk
22:07:48 <datsun180b> configuration detail
22:07:50 <SlickNik> But info on the entities/API calls are up there already.
22:07:51 <hub_cap> still nice to see whats going on
22:07:54 <datsun180b> it also assumes you're logged in
22:08:11 <hub_cap> lol datsun180b
22:08:28 <hub_cap> SlickNik: one thing to note, plz make the lines < 80 char
22:08:36 <hub_cap> check out the begin (lines 4~7)
22:08:41 <hub_cap> vs line 475
22:08:49 <SlickNik> Ah, okay will snip em...
22:08:52 <hub_cap> <3
22:08:55 <hub_cap> great work
22:09:05 <SlickNik> np.
22:09:25 <vipul> who was going to add snapshots api there/
22:09:30 <hub_cap> so vipul kagan, i barely touched base w/ u wrt the group stuff in reddwarf + percona
22:09:50 <kagan> what does that has to do with percona ?
22:09:51 <hub_cap> is someone working on that vipul? the snaps feature?
22:09:51 <SlickNik> #action SlickNik still working on Security-Groups. Hope to have patch up for review by beginning next week.
22:10:11 <vipul> #action vipul to update api-specs wiht Snapshot API
22:10:12 <hub_cap> as per last wk kagan
22:10:13 <hub_cap> vipul hub_cap and kagan to look into making the service_type code work properly w/ percona image
22:10:24 <juice> hub_cap: kmansel and I are working on some prep stuff but I don't know how has the meat of the work
22:10:44 <vipul> hub_cap: i think we covered that?
22:10:47 <hub_cap> cool. looks like vipul is gonna take a stab at the api juice
22:10:59 <vipul> the percoan service type piece
22:11:02 <hub_cap> we covered it, id like to get a finalization for the group
22:11:03 <kagan> if i understand you guys correctly, i think i've done that already
22:11:11 <hub_cap> im not saying u havent
22:11:17 <hub_cap> jsut want to cover the action item from last wk :)
22:11:24 <vipul> So kagan added code to support 'percoan' and 'mysql' as types in the API request, defaulting to 'mysql'
22:11:31 <vipul> this is a conf value in reddwarf.conf
22:11:33 <hub_cap> perfect vipul thx!
22:11:46 <hub_cap> was it a ton of work?
22:11:47 <vipul> when the image is updated by redstack, it's added to service_images as percona or mysql
22:12:03 * hub_cap hopes it was not a lot of work
22:12:14 <vipul> only kagan would know :)
22:12:15 <kagan> no it wasn't
22:12:18 <hub_cap> sweet
22:12:35 <hub_cap> cp16net: go home
22:12:40 <hub_cap> did u do that last wk?
22:12:48 <SlickNik> I sure hope so :)
22:13:07 <cp16net> yup
22:13:12 <cp16net> i'm at home now
22:13:19 <cp16net> success!
22:13:32 <hub_cap> perfect!!
22:13:40 <hub_cap> ok done w/ teh action items
22:13:42 <esp1> I wish I was home
22:14:17 <hub_cap> #topic Quotas / Limits Updates
22:14:39 <esp1> lookes like Quotas got merged :)
22:14:50 <grapex> Limits looks good to me
22:14:50 <datsun180b> sounds done to me
22:14:50 <hub_cap> yuuuuup
22:14:57 <SlickNik> hellz yea!
22:15:07 <grapex> Only question I have is mockito
22:15:08 <vipul> woohoo
22:15:20 <esp1> I've started planning out the next few steps to bring quota's into the API call and update the python reddwarf cli
22:15:21 <hub_cap> grapex: thas not a question :)
22:15:32 <esp1> grapex: good eye :)
22:15:44 <grapex> I'm ok with us adding that, but won't it not tie into the standards or something?
22:16:06 <hub_cap> yet another mocking lib?
22:16:08 <grapex> I thought the powers that be were wanting us to use mock
22:16:11 <esp1> I will let juice speak to it.
22:16:19 <hub_cap> juice: speak to it
22:16:20 <juice> it's well worth it
22:16:21 <esp1> I have idea
22:16:24 <grapex> Ok. I'm going to +2 it anyway, just wanted to hear the reasoning. :)
22:16:37 <juice> I have struggled with the mocking libraries
22:16:44 <juice> used this extensively in java
22:16:51 <juice> works wonders in both languagues
22:16:52 <esp1> I mean I have no idea.  but it does look cool
22:16:59 <juice> the best part is that it is easy to use
22:17:12 <juice> and you can actually make sense of the test code
22:17:27 <juice> …most of the times anyways :)
22:17:29 <grapex> Another tangent
22:17:39 <grapex> "@test(enabled=RD_CLIENT_OK)"
22:17:42 <grapex> That's kind of cool
22:17:50 <grapex> I was wondering if we could build the version number into the client
22:17:57 <grapex> so those tests would get enabled automatically
22:18:19 <esp1> well at first that was the plan
22:18:35 <esp1> but I think I will just remove it once reddwarf cli merges.
22:18:36 <grapex> Another idea is we could invent a decorator that would check the client version, and run SkipTest if the client wasn't up to date. The reason is, skips end up being far more visible than disabling tests.
22:18:39 <grapex> Ok
22:18:46 <datsun180b> Well just having the client version would be great, I don't want to have to look at pip freezes after tests fail
22:18:54 <grapex> If no one objects, I'll create a blueprint for that.
22:18:55 <esp1> I thought about that too.  I think that would be a good idea.
22:19:14 <esp1> +1
22:19:19 <grapex> Cool
22:19:36 <SlickNik> I'm in favor of creating a blueprint for that, think it would be useful.
22:20:19 <hub_cap> +1 to the BP, action item it grapex
22:20:25 <grapex> Cool, I'm on it
22:21:32 <hub_cap> i mean actually type it in the channel grapex!!
22:22:03 <grapex> Was going to do a client BP, doing a reddwarf one instead
22:22:20 <grapex> We may be able to find a way to do this that doesn't involve changing the client. Let's talk about it after the meeting.
22:23:05 <hub_cap> grapex: !!!
22:23:09 <hub_cap> #action teach grapex to use #action
22:23:28 <grapex> #action make a RD blueprint to enable tests depending on RD client version
22:23:29 <hub_cap> :)
22:23:33 <grapex> lol... sorry hub_cap!
22:23:38 <hub_cap> haha that was hilarious
22:23:40 <SlickNik> :)
22:23:54 <hub_cap> ok we good on quotas/limits? im STOKED they are in/merging
22:24:03 <vipul> good job guys
22:24:36 <hub_cap> WOOOOOOT!! Big +1 to the HP guys
22:24:57 <hub_cap> #topic Percona Image Updates
22:25:15 <kagan> i've posted another version today
22:25:20 <kagan> i think it should be good
22:25:21 <grapex> Yeah, that code is looking really good.
22:25:24 <kagan> need you guys to take a look
22:25:27 <grapex> Thanks guys
22:25:40 <grapex> kagan: I'm sorry I've been unable to look at that code yet, I've been in a lot of meetings this week
22:25:44 <grapex> I'll try to catch up soon.
22:25:46 <kagan> i've added the package name as a config with default to mysql
22:25:54 <kagan> sure
22:25:56 <hub_cap> sweet! we will be looking @ it today/tomorrow kagan for sure
22:26:05 <kagan> so, one thing still missing:
22:26:16 <hub_cap> i like that kagan! (the config / pkg default)
22:26:18 <kagan> if the image is clean, i.e. no mysql installed
22:26:27 <kagan> then percona will not be installed
22:26:34 <kagan> we still don't support that
22:27:00 <kagan> it shouldn't break, since the only time the pkg name is set to percona's is when you actually build a percona image
22:27:22 <kagan> i think we need to discuss whether we even want to support such a use case, and if so, find a decent way to handle it.
22:27:24 <hub_cap> Ahh so yer saying the image _has_ to be seeded w/ percona mysql to test percona mysql
22:27:31 <kagan> installing percona has some more steps to it.
22:27:34 <hub_cap> if its no mysql, itll fail for percona
22:27:39 <hub_cap> that makes sense
22:27:53 <kagan> well, it won't fail, cause it won't think it's percona ...
22:27:57 <hub_cap> ah okey
22:28:06 <hub_cap> itll just install stock mysql
22:28:09 <kagan> it's set to look for percona pkg only at time of building a percona image
22:28:14 <kagan> right
22:28:18 <hub_cap> that makes sense
22:28:22 <kagan> if provided with a clean image.
22:28:40 <vipul> we could support it, but probbly need ot refactor that install code a bit
22:28:42 <hub_cap> ok, well if yall want to add that to the guest it would make sense...
22:28:46 <kagan> so, we ended up dropping a lot of what i initially put it to make the tests work
22:28:49 <hub_cap> but if not, putting in image def works :)
22:28:55 <kagan> i think we have a pretty solid version checked in now.
22:28:59 <hub_cap> w00t
22:29:25 <kagan> any questions?
22:29:27 <SlickNik> I think in the future, we may want to do something like install percona (like mysql), but for now this seems like a good plan…
22:29:28 <hub_cap> kagan: safe to assume uve run it w/ stock mysql recently? ill pull it down tomorrow and run it w/ stock too
22:29:37 <kagan> yes, i did
22:29:41 <hub_cap> sweet
22:29:47 <kagan> just had some issues this morning with tox
22:29:56 <kagan> would pass on my machine, but failed jenkins ...
22:30:05 <kagan> indeed there were errors, funny fox didn't find it ...
22:30:13 <kagan> now all should be good, as far as i can tell ...
22:30:29 <kagan> if you wanna test it, make sure you also pull latest changes to reddwarf-integration
22:30:35 <kagan> or have they merged already ...
22:30:58 <hub_cap> okey thx kagan
22:31:12 <kagan> sure
22:31:19 <hub_cap> now our PM's will be asking when we are going to put maria in
22:31:21 <hub_cap> :P
22:31:36 <kagan> it's easy, 3 days tops …. :)
22:31:39 <imsplitbit> hub_cap, they already are
22:31:40 <vipul> heh
22:31:41 <SlickNik> Why wait for the PM's?
22:31:41 <grapex> Nice.
22:31:46 <hub_cap> hahahahaha
22:31:52 <SlickNik> hub_cap, when are we going to put Maria in? :P
22:32:05 <SlickNik> j/k
22:32:11 <vipul> who's maria
22:32:11 <esp1> uhm, kagan is going on vacation for like 1 month..
22:32:12 <hub_cap> i think vipul told me SlickNik was going to do it
22:32:14 <vipul> :D
22:32:18 <hub_cap> vipul: lol
22:32:18 <SlickNik> lol.
22:32:23 <hub_cap> woah kagan when?
22:32:24 <imsplitbit> vipul, it's hub_cap's gf
22:32:30 <vipul> heh
22:32:33 <kagan> in 2 weeks.
22:32:34 <hub_cap> lets get his code reviewed/merged quick
22:32:41 <hub_cap> ok we should have more than enough time :)
22:32:47 <kagan> i'll try to be working most of the time. going to Israel, so 10 hours ahead ..
22:32:48 <kagan> \
22:32:57 <hub_cap> cool!
22:32:57 <kagan> and little overlap with all the weekend shift ....
22:33:04 <kagan> gonna be tricky
22:33:05 <datsun180b> 10 hours ahead of seattle?
22:33:09 <kagan> yep
22:33:14 <hub_cap> vipul: do we need to cover snapshots? they are still on the agenda
22:33:21 <kagan> it's easier to take two hours back and flip :)
22:33:30 <vipul> No, not really, besides we're started work on it
22:33:41 <grapex> Hey that's only a mere 8 hours ahead of us.
22:33:47 <datsun180b> exactly
22:33:47 <hub_cap> any progress to be chatted about vipul?
22:33:47 <vipul> we're enabling Swift and bringing in swiftclient in reddwarf
22:33:56 <hub_cap> ahh cool
22:34:02 <hub_cap> integration work first
22:34:14 <juice> kevin has the swift client enabled by default.
22:34:15 <SlickNik> juice and kmansel working on that… (swift / swiftclient)
22:34:16 <vipul> well some of that is kinda necessary
22:34:25 <hub_cap> imma change the meeting to say Snapshots Update
22:34:28 <hub_cap> def vipul
22:34:36 <juice> I am writing the wrapper code to get the client and looking into a way of getting away from Fakes
22:34:37 <hub_cap> it was blueprint feedback....
22:34:49 <juice> for use with testing with Swift in a non-integrated env
22:34:55 <kmansel> yeah i'm working on that integration with redstack
22:34:56 <juice> should have something to commit by tmw
22:35:20 <hub_cap> sweet!
22:35:21 <vipul> cool, annashen is also looking at the models piece
22:35:32 <vipul> going to submitting the migration soon i believe
22:35:38 <grapex> juice: Do you mean you're changing the test doubles to some other kind of test double, or that you're going to try to call a real instance of swift?
22:36:20 <juice> i was thinking of not using a test double but instead of using mocks
22:36:46 <juice> I certainly do not think we should have Fake code in the production code a la Client
22:37:15 <grapex> For the integration tests?
22:37:30 <vipul> wasn't there a bug for that issue?
22:37:36 <juice> sure
22:37:38 <vipul> tha we mix fakes with real clients
22:37:42 <hub_cap> for removing fakemode?
22:37:56 <vipul> I think juice is referring to the 'remotes.py'
22:38:06 <juice> grapes - is there a reason not to use mocks in fake mode?
22:38:22 <grapex> No, it would make sense in some cases.
22:38:30 <hub_cap> lol grapes
22:38:37 <juice> :) I just caught that
22:38:37 <grapex> The only exception is if you stand up Reddwarf by itself to run in fake mode with eventlet turned on
22:38:55 <hub_cap> id prefer to see a way to make fakemode configuration driven, just fyi
22:38:56 <grapex> It would just be hard to get the mocks to behave persistently
22:39:32 <juice> Yes, I would not suggest using mocks to keep track of state
22:39:33 <grapex> So the only reason is it would be hard. :) If you can find a way to do it where fake mode can still chug along then that's great
22:39:50 <juice> that's where the fakes would be a better choice
22:39:53 <grapex> Possibly having two configurations could help as well, or just using mocks from the unit tests.
22:40:04 <juice> I am just getting into it so this is somewhat speculative
22:40:31 <grapex> I think the "fakes" are best when you're writing integration tests for the happy path, and any unhappy paths that are liable to be hit frequently
22:40:40 <hub_cap> like looking for a oil well juice?
22:40:52 <grapex> It's easier to hit the edge cases with unit tests and mocks
22:41:13 <grapex> but if you can find a way around it feel free, as long we as we don't lose functionality it could be really cool.
22:41:44 <juice> I will post findings in the regular channel over the next day or two
22:42:41 <hub_cap> cool
22:42:44 <juice> I really just want to provide some light weight tools developers can get in there to change code and test their changes.  So that is the goal.  As a newcomer to the code base I don't feel like it's there yet
22:43:05 <hub_cap> so do we really have a CI update? i konw datsun180b had some issues w/ CI due to the reddwarf->database change.
22:43:10 <hub_cap> #topic Redwarf CI Update
22:43:21 <hub_cap> datsun180b: care to elaborate?
22:43:25 <datsun180b> I think I've resolved everything I can within SF
22:43:40 <vipul> stackforge?
22:43:43 <datsun180b> aye
22:43:50 <datsun180b> so as far as i can tell for now we're okay
22:44:18 <datsun180b> well, there's a couple things that i put in my modify-user fix requests
22:44:41 <datsun180b> at this point i think it's better that i just submit that on its own
22:44:42 <vipul> CI update is that we are working on a solution with our own Jenkins that will listen to Gerrit ... the idea is that we run the VM-gate here .. Rax could do the same fi we need ot have multiple set ups
22:45:09 <grapex> vipul: So ultimately, either HP or Rax will run Jenkins and not StackForge?
22:45:23 <vipul> grapex: For the time being, yes
22:45:40 <vipul> the concernt openstack-ci has is that they can't support all stackforge projects since vm-gate is a pretty heavy thing
22:45:46 <vipul> and htey have no way to set priorities on projects
22:45:55 <datsun180b> did you try to tell them that we're #1?
22:46:00 <vipul> until they get multi-master jenkins setup in openstack CI
22:46:07 <vipul> we're gong to set up our own..
22:46:20 <vipul> when they get it set up, i beleive we'll be 'officially supported' again
22:46:21 <hub_cap> vipul: is yours open?
22:46:22 <grapex> Ok. As long as we just have it running
22:46:26 <SlickNik> yes, Openstack CI is having issues with the load on their Jenkins master, so they don't want to take on  integration testing for stackforge projects...
22:46:33 <hub_cap> as in will we be able to hit it?
22:46:37 <vipul> hub_cap: No, that's what we're trying to figure out
22:46:40 <grapex> Makes sense.
22:46:41 <vipul> how to get you guys access
22:46:44 <hub_cap> kk vipul
22:46:49 <vipul> worst case, ew'll push logs up?
22:46:56 <hub_cap> we could probably spin up a cloud server...
22:47:00 <hub_cap> we have the power
22:47:08 <vipul> we're having trouble with the gerrit hook at this point
22:47:19 <vipul> so this may/may not go anywhere.. and a Plan C may need to be developed
22:47:29 <hub_cap> ya i think gerrit needs to push to the jenkins infra right?
22:47:31 <grapex> Worst case scenario
22:47:40 <grapex> we just run it periodically without listening to hooks
22:47:42 <hub_cap> ok if we need to pop a cloud server
22:47:47 <hub_cap> we can do that
22:47:47 <SlickNik> hub_cap it's a pull model...
22:47:48 <vipul> Yea, honor system?
22:47:49 <grapex> At least then we'd see it and could be aware when it broke
22:47:57 <hub_cap> vipul: BOOOOOOOO
22:48:03 <vipul> yea don't like it either
22:48:03 <hub_cap> SlickNik: k
22:48:07 <SlickNik> in openstack_ci zuul monitors the gerrit stream and triggers jenkins...
22:48:20 <hub_cap> right so gerrit needs to be able to talk to jenkins
22:48:21 <SlickNik> gerrit event stream*
22:48:28 <hub_cap> that what i was gettin at
22:48:34 <hub_cap> if jenkins is private....
22:48:38 <hub_cap> then gerrit no knowie
22:48:38 <vipul> so HP or Rax jenkins can be given voting privileges
22:48:49 <grapex> Yeah, it needs to be on a public Nova server.
22:49:08 <vipul> that's already something they support.. you might be right, not behind VPN
22:49:11 <hub_cap> maybe we should put it in the public and use openid/launchpad integration for ssh/jenkins access
22:49:25 <vipul> #link http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way
22:49:26 <hub_cap> vipul: im pretty sure it wont work unless u punch a hole in yer firewall
22:49:41 <hub_cap> which im _sure_ your netsec guys are totally cool with
22:50:03 <vipul> well don't tell anyone but we have a jenkins in nova today :D
22:50:09 <hub_cap> so why dont we spin up a cloud servers jenkins?
22:50:15 <hub_cap> oh ic so it _is_ public?
22:50:27 <hub_cap> and i wont tell anynoe whos not in the room or has ears vipul
22:50:28 <vipul> sort of.. ports are blocked
22:50:29 <hub_cap> promise
22:50:41 <vipul> securiryt gorup rules
22:50:45 <hub_cap> ah ic
22:50:46 <vipul> ugh
22:51:02 <hub_cap> ok lets table this i think. we can come up w/ a solution
22:51:07 <vipul> anyway, so still some work to be done before we have that.. but look at the link ^^
22:51:08 <hub_cap> and it sounds like yer already workin on it
22:51:13 <vipul> if you guys want to try to set something up on your end
22:51:18 <esp1> hub_cap: who do you know that doesn't have ears?  I know a dude who's missing a thumb.
22:52:18 <hub_cap> whales?
22:52:23 <hub_cap> lets go w/ visible ears esp1
22:52:41 <hub_cap> #topic Open Discussion
22:52:41 <esp1> sorry for the interruption...
22:52:58 <kagan> now time for issues?
22:53:03 <kagan> i have 2 of those ...
22:53:03 <datsun180b> issues you say
22:53:04 <hub_cap> yar
22:53:06 <SlickNik> yes kagan.
22:53:13 <SlickNik> go for it.
22:53:18 <kagan> first one, code style/pep8
22:53:24 <kagan> is there a tool we use for that?
22:53:28 <grapex> tox -epep8
22:53:31 <datsun180b> yes, the tool is called pep8
22:53:35 <kagan> that's to check
22:53:40 <esp1> yeah that's what I run too..
22:53:42 <grapex> You mean from an IDE?
22:53:47 <kagan> i mean to apply it ...
22:53:53 <vipul> automagically fix?
22:53:57 <esp1> IDE is okay.. but seems slow (PyCharm)
22:54:04 <kagan> so, for eclips/pydev there is some thing
22:54:09 <vipul> i think juice had some tricks
22:54:13 <kagan> but it will apply to a full folder and not a single file.
22:54:25 <hub_cap> if thre is that'd rock
22:54:26 <kagan> i tried it, and all the files where modified, so naturally you're not all using that … ;)
22:54:37 <juice> pycharm will warn you and offer to fix it
22:54:40 <hub_cap> but i mod them manually before i chek in
22:54:43 <kagan> also, there is "autopep8 -i my_file.py"
22:54:56 <kagan> eclipse/pydev will also warn.
22:54:56 <hub_cap> im slightly scared of that, personally
22:55:06 <hub_cap> but i say go fer it
22:55:10 <kagan> i just thing it would be good if we could use a tool, and preferably the same one
22:55:15 <juice> the benefit to pycharm is that it finds it sort of real time
22:55:22 <hub_cap> kagan: i agree
22:55:27 <hub_cap> we had nice formatters in java
22:55:27 <kagan> same with pydev, juice
22:55:29 <hub_cap> that woudl do it for us
22:55:42 <kagan> what ide are you guys using?
22:55:45 <datsun180b> vim
22:55:49 <kagan> nice ...
22:55:50 <vipul> lol
22:55:52 <djohnstone> hahaha
22:55:59 <datsun180b> you think i'm kidding
22:56:00 <vipul> wrong crowd
22:56:11 <kagan> "réal monkeys, ehh… programers! use vi!!"
22:56:19 <hub_cap> hahaah ide :P
22:56:20 <SlickNik> emacs here, but let's not get started on that again :)
22:56:22 <hub_cap> i use textmate
22:56:29 <kagan> ok, i see
22:56:31 <hub_cap> lets all agree to disagree
22:56:33 <imsplitbit> yeah that fight has gone on 30 years
22:56:34 <grapex> Sublime. PyCharm is pretty good but Sublime is faster.
22:56:40 <vipul> btw, openstack has a free PyCharm license
22:56:47 <vipul> if you are contributing to Openstack that is
22:56:49 <vipul> just an FYI
22:56:56 <kagan> so it either has to be some stand alone tool, like autopep8 or we find that it actually does the same as an integrated extension
22:56:56 <imsplitbit> pycharm on any modern computer works fine
22:57:25 <datsun180b> so i did want to bring up an issue briefly
22:57:25 <kagan> ok, so do you agree we might want to use some formatting tool?
22:57:35 <grapex> kagan: I think we should let people use the tools they want and trust tox pep8 to check it.
22:57:42 <kagan> and we don't want that every time we use it, it'll modify it differently than the other guy?
22:57:47 <imsplitbit> grapex, agreed
22:57:52 <vipul> kagan: if you find one.. and it works with tox -epep8, please share
22:57:54 <hub_cap> ya will using a tool or not using a tool not provide the same output?
22:58:01 <grapex> I guess I miss the point- pep8 should keep us from having a different format from each other
22:58:16 <datsun180b> oh i can show you ways that even pep8 doesn't enforce the spirit of PEP8
22:58:22 <kagan> the thing is, if i want to use such a tool, it'll introduce too many changes every time i touch a file, unless we all use the same tool ...
22:58:24 <imsplitbit> :-)
22:58:34 <datsun180b> i trust humans over robots in this case
22:58:46 <hub_cap> +1 to humans
22:58:49 <grapex> kagan: If that's the case, maybe that tool needs to be tweaked to match pep8. The other OS projects are using it so we may have trouble changing the format. :(
22:59:05 <kagan> you can split a line in many places to have both halves at the proper length. just an example ...
22:59:08 <datsun180b> there's also the consideration that we'd have to include the tool in our AUTHORS file
22:59:23 <kagan> it complies with pep8 of course !!!
22:59:26 <grapex> datsun180b: lol!
22:59:32 <grapex> kagan: The community might be open to a superset of pep8
22:59:34 <kagan> we just need to agree to use the same formatter
22:59:49 <hub_cap> kagan: i dont think thats gonna happen honestly
22:59:51 <juice> same format of pep8 compliant?
22:59:54 <kagan> again, i just don't want too many changes every time i apply a formatting tool to a file
22:59:55 <hub_cap> we can mandate pep8
23:00:17 <hub_cap> but telling eveyrone who ever codes on the proejct to use tool X instead of just being compliant is not gonna go over well
23:00:21 <kagan> so, how do you guys make it pep8? run tox and fix manually as you see fit?
23:00:26 <hub_cap> yup
23:00:36 <hub_cap> i run tox before i git review
23:00:39 <vipul> yea that's how most people do it
23:00:44 <hub_cap> or a few times during a cycle if its big
23:00:47 <kagan> well, wouldn't you prefer a tool to do that for you?
23:00:56 <juice> have you seen a discrepancy between pydev/charm pep 8 and fox?
23:00:57 <hub_cap> _prefer_ is a strong word
23:01:03 <kagan> if it's a stand alone tool, you can still edit wherever you like ...
23:01:04 <vipul> lol
23:01:07 <hub_cap> i dont prefer a tool to do it at all
23:01:10 <SlickNik> _tool_ is a stronger word. :)
23:01:16 <annashen> you can run pep8 individually
23:01:20 <hub_cap> yes of which i am one most of the time SlickNik
23:01:21 <vipul> hehe
23:01:26 <hub_cap> but yall know that
23:01:26 <grapex> kagan: So I've noticed running different versions of pep8 gives different results
23:01:37 <grapex> for awhile datsun180b was running pep8 locally
23:01:39 <vipul> yea that's probably why it looks different
23:01:44 <datsun180b> that is true, the newer ones are a lower limbo bar
23:01:47 <grapex> then we introduced tox and he found out he'd formatted it differently
23:01:50 <datsun180b> i AM pep8
23:02:00 <grapex> maybe its a simple as making sure your IDE is using the exact same version as tox?
23:02:00 <kagan> i don't understand the objection to use a formatter tool … please explain
23:02:09 <hub_cap> simple
23:02:13 <hub_cap> not everyone will use it
23:02:18 <vipul> it's like a religious war.. not that simple..
23:02:20 <hub_cap> unless we hook it in to a post commit hook
23:02:25 <datsun180b> use the formatter if you want, it'll still have to pass under pep8's scrutiny
23:02:25 <hub_cap> someone will not use it
23:02:29 <vipul> yep
23:02:32 <hub_cap> and then when u format it it will change their code
23:02:38 <hub_cap> and we will have this convesation again
23:02:42 <datsun180b> I'll say it now, I'm not going to outsource my style to a robot
23:02:45 <hub_cap> and it will recycle again and again
23:02:52 <hub_cap> +1 datsun180b
23:03:04 <kagan> you guys are crazy … ;)
23:03:05 <juice> I also don't like getting a bunch of changes that are all whitespace
23:03:06 <vipul> kagan: if you find one that basically keeps the 'good' files the same
23:03:09 <juice> makes merges messy
23:03:16 <hub_cap> kagan: go ask nova to do it
23:03:19 <hub_cap> if u can get them to comply
23:03:22 <hub_cap> we will gladly comply
23:03:23 <grapex> datsun180b was much like you kagan, until he too was forced to drink the kool-aid... join us... join us... :)
23:03:26 <kagan> i hate to format manually, that all ...
23:03:27 <hub_cap> and ill give u 100 bucks
23:03:35 <kagan> :)
23:03:43 <datsun180b> more like you guys didn't understand pep8
23:03:53 <kagan> what do you mean?
23:03:54 <datsun180b> i had to beat the \ off the end of your broken lines
23:03:54 <hub_cap> this coming from a guy who hates pep8
23:04:16 <kagan> is \ not a pep8 ?
23:04:16 <hub_cap> kagan: datsun180b referiing to the rest of the rackers
23:04:18 <datsun180b> i hate pep8, the checking tool. I embrace PEP8, the guideline document
23:04:31 <esp1> lol
23:04:32 <hub_cap> go hug your pep8 datsun180b
23:04:38 <datsun180b> >>> import this
23:04:38 <SlickNik> lolol
23:04:40 <kagan> but we all have to comply with pep8, right?
23:04:44 <hub_cap> def
23:04:48 <datsun180b> kagan: absolutely
23:04:56 <hub_cap> but we dont have to comply w/ some robots version of it :)
23:05:01 <kagan> so why not use something like autopep8 to do it for us?
23:05:07 <kagan> what do you care ??
23:05:11 <hub_cap> cuz we cannot guarantee everyone will do that
23:05:19 <kagan> we just need to try ...
23:05:23 <hub_cap> how can u make everyone from now to the end of this project guarantee to use it?
23:05:23 <datsun180b> because we're better at parsing pep8's message than any fsm-based machine
23:05:24 <vipul> yea the moment one person doesn't...
23:05:27 <hub_cap> BOOM
23:05:30 <kagan> if you all *dont* want to use it, then no one can ...
23:05:41 <vipul> you could.. on individual files
23:05:43 <hub_cap> not true... just annoying for that person ;)
23:05:47 <vipul> that you actually modified
23:05:54 <esp1> fyi no one has beaten dror in a fillibuster...
23:06:02 <kagan> well, if only one occasionally doesn't it's not that bad, but i think i'm a minority here ...
23:06:05 <hub_cap> lol... we can try
23:06:06 <imsplitbit> hub_cap, http://tech.myemma.com/python-pep8-git-hooks/
23:06:06 <datsun180b> full reveal, if you check our commit history i do have commits with the comment "pep8 fixes"
23:06:17 <hub_cap> imsplitbit: im sure it _can_ be done :)
23:06:37 <imsplitbit> I have pre commit hooks to run pep8 on my python
23:06:41 <imsplitbit> code that is
23:06:50 <vipul> lol
23:06:51 <hub_cap> snazzy
23:07:01 <kagan> so, i guess no agreement here … ok, i tired.
23:07:04 <kagan> second issue:
23:07:08 <esp1> kagan: you should give PyCharm a try.  you might find that it does a decent job.
23:07:16 <kagan> debugging unittest code.
23:07:29 <kagan> do you guys debug the nose tests?
23:07:50 <kagan> cause when we tried, they failed just by running in debug mode.
23:07:56 <hub_cap> as in, via pdb?
23:08:22 <kagan> we then found 2 places in the code where if i put sleep (no matter how small the sleep time is) it will fail the test even when not in debug mode
23:08:24 <datsun180b> i did want to bring up an issue about testing
23:08:37 <datsun180b> so you're probably leading to the point i wanted to make
23:08:38 <kagan> was wondering if you ever manage to debug those, as in step by step
23:08:50 <vipul> well it's not related to debugging
23:08:56 <vipul> it's if you put a sleep in a certain spot
23:08:59 <vipul> the tests fail
23:09:03 <vipul> no matter how small the sleep is
23:09:14 <datsun180b> devil's advocate: sleep(0) ?
23:09:28 <kagan> i tried 0.000000000001
23:09:32 <kagan> not sure about 0 though ...
23:09:39 <kagan> would guess it'd fail as well ...
23:09:40 <vipul> wondering there is something in the proboscic framework that causes this?
23:09:41 <grapex> Is it when you call time.sleep?
23:09:51 <kagan> yes
23:09:54 <grapex> Or just when you literally spend some time with the program paused?
23:10:01 <kagan> no
23:10:06 <kagan> we tried spending time with a long loop
23:10:09 <grapex> That's because time.sleep is monkey patched out so the tests will run quickly
23:10:09 <kagan> it worked
23:10:20 <kagan> right!
23:10:23 <kagan> we saw that ...
23:10:23 <vipul> hah..
23:10:30 <grapex> So it runs the event simulator
23:10:38 <datsun180b> oh, flashbacks to poll_until
23:10:39 <grapex> basically running things that would have run as different threads right away
23:10:51 <kagan> we didn't understand how come the whole test suite ran faster than a single sleep, when we know the sleep had to happen 12 times !!!
23:11:07 <vipul> but why does that cuase it to fail?
23:11:11 <kagan> but why would it fail the tests?
23:11:11 <vipul> since it should be ignored?
23:11:37 <grapex> If you'd like to debug the tests, it's possible if we change it not to simulate events
23:12:13 <grapex> In run_tests.py, change line 43
23:12:34 <grapex> Because, calling sleep tells it to run any pending events.
23:12:47 <kagan> change to what?
23:12:53 <grapex> I'm not sure why it fails. We never had luck running PyCharm in debug mode for anything other than simple unit tests.
23:13:05 <grapex> kagan: In the reddwarf code
23:13:06 <kagan> and is that the same reason if fails while in debug mode?
23:13:28 <kagan> change the line to be what?
23:13:42 <grapex> Line 43 - just comment it out
23:13:46 <kagan> ok
23:13:48 <kagan> i'll try
23:13:51 <grapex> Ditto to line 89
23:14:15 <kagan> line 89 is only if i want to use sleep, right?
23:14:31 <kagan> we used sleep just to prove a point. our main concern was running in debug mode
23:14:43 <grapex> Line 89 changes sleep to run functions which would have run in a seperate thread
23:14:45 <hub_cap> id prefer to comment all lines %7 ==0 out
23:15:24 <vipul> and just see what happens :)
23:15:30 <kagan> hub_cap, what do you mean ??
23:15:32 <datsun180b> hub_cap: oh there's a sed oneliner for that
23:15:33 <juice> there was an option in intellij that would pause all threads in debug mode when stepping through to prevent timer threads from timing out while you did you're mental investigation
23:15:36 <kagan> joke, right ??!
23:15:39 <hub_cap> LOL kagan grapex
23:15:46 <hub_cap> of course :P
23:16:05 <datsun180b> i can't remember how to select just lines %7==0 as a movement in vim
23:16:21 <kagan> de vencci code running in front of me …
23:16:38 <vipul> datsun180b you had an 'issue'?
23:16:54 <SlickNik> you were mentioning something about test timing?
23:17:04 <hub_cap> ha kagan
23:17:13 <datsun180b> yeah, i lost some time trying to get my work done until i got https://review.openstack.org/#/c/23018/ done
23:17:55 <datsun180b> spinning up a vm with clean pulls from stackforge before that change, i simply couldn't build and spin up an instance
23:18:08 <grapex> datsun180b: Were the public real mode tests working before that commit?
23:18:15 <vipul> oh yea that was my bad.. i should have fixed the issue
23:18:27 <vipul> so we have two paths to deploying now
23:18:33 <vipul> i've been using the local.sh approach
23:18:36 <vipul> which doesn't suffer from this
23:18:37 <datsun180b> vipul: it's not an issue of blame, but one of being able to prevent that that i care about
23:18:47 <grapex> vipul: Is that in devstack?
23:18:52 <vipul> no, that's in redstack..
23:19:02 <vipul> so if build your environment the 'old' way
23:19:14 <vipul> redstack install, redstack build, redstack kick-start.. etc
23:19:22 <vipul> that change is required for things to work
23:19:28 <vipul> if you copy 'local.sh' into devstack/
23:19:32 <vipul> and just run stack.sh
23:19:36 <vipul> then you don't see the issue
23:19:48 <vipul> what it boils down to is... we need to not have two paths
23:19:50 <datsun180b> would probably help not to just be keeping that in your head
23:20:06 <SlickNik> I've been meaning to unify the two approaches so that redstack uses the hooks in devstack to run, but I haven't had much time to work on it. :(
23:20:10 <vipul> yea.. i noticed after some others saw it
23:20:29 <SlickNik> I should really do that since it would help not have some of these issues creep up.
23:20:38 <vipul> sorry, should have put something in the reddwarf channel
23:20:54 <hub_cap> hai grapex
23:20:56 <grapex> Good ole OSX key bindings...
23:21:00 <esp1> yeah I lost 5hrs one day.  SlickNik saved me.
23:21:04 <hub_cap> LOL
23:21:10 <grapex> That broke us at Rax for awhile
23:21:35 <vipul> So do we want to trim down redstack? so we don't have to maintain 2 ways of set up?
23:21:36 <datsun180b> even now there's one more change to make to our internal fork that i haven't nailed down yet, something about keystone
23:21:43 <grapex> We need to be careful when we make changes like this to make sure we keep track of changes that will they may mandate in Reddwarf Integration
23:21:56 <vipul> right.. this is where the vm-gate would have caught this
23:22:01 <hub_cap> i would love to trip redstack if we can
23:22:04 <hub_cap> *trim
23:22:05 <vipul> changes to multiple projects are hard to coordinate
23:22:08 <grapex> vipul: Agreed. What if we just changed redstack to call local.sh?
23:22:26 <vipul> yea, or rather copy local.sh to devstack and invoke stack.sh
23:22:27 <SlickNik> grapex: that was what my comment above was about.
23:22:39 <grapex> SlickNik:Ok, I probably missed it when I ducked out. :)
23:22:57 <grapex> vipul: I think copying it to devstack makes the most sense
23:23:06 <grapex> trying to think if doing it that way precludes us from anything
23:23:09 <vipul> #link https://wiki.openstack.org/wiki/Reddwarf-installation
23:23:19 <vipul> FYI ^^ is the 'preferred' way of set up
23:23:30 <vipul> until we trim Redstack
23:23:37 <kagan> so i took line 43 out, (and all the mod7 ones as well) but now the tests takes much more time to run and still fail ...
23:23:54 <kagan> why would this line break the tests if ran in debug mode?
23:24:06 <grapex> kagan: Those are integration tests, it's going to be very tricky to debug them.
23:24:15 <hub_cap> lol kagan to mod7
23:24:19 <kagan> no, i'm not talking about those ...
23:24:23 <SlickNik> #action SlickNik look into trimming down redstack to install devstack using the local.sh way.
23:24:28 <grapex> If you need to run a debugger, run reddwarf server in fake mode and set break points, then run the tests from another process
23:24:28 <kagan> just the unit test ones
23:24:30 <datsun180b> :g/^/if !(line('.')%7)|s/^/#/|endif
23:24:32 <datsun180b> by the way
23:24:35 <kagan> i have no live environment ...
23:24:49 <grapex> kagan: there's got to be some way to run the testr tests by themselves without the run_test.py script
23:24:51 <SlickNik> hahah, nicely done datsun180b...
23:25:07 <grapex> kagan: You don't need a live environment thankfully. You can run reddwarf in fake mode locally
23:25:08 <kagan> tester tests run nicely under debug mode
23:25:14 * hub_cap shakes head at datsun180b
23:25:26 <kagan> testr
23:25:38 <vipul> thanks SlickNik for the actino
23:25:41 <grapex> kagan: Look at reddwarf/bin/reddwarf-server
23:25:47 * datsun180b wonders how to run pycharm in debug mode from vim
23:25:53 <hub_cap> so should we call this meeting?
23:25:54 <kagan> but if i run run_test.py it only runs well in run mode, not debug mode ...
23:25:55 <grapex> testr is running unit tests which are simplier.
23:25:58 <hub_cap> and move this to #reddwarf?
23:26:13 <datsun180b> in think we've overstayed our reservation, or nearly so
23:26:16 <kagan> i'm ok with this
23:26:30 <hub_cap> <3
23:26:31 <hub_cap> #endmeeting