[01:13] <hatch> gary_poster: saw your email, and freshly pulling trunk has 5 broken tests for me .....
[01:13] <gary_poster> hatch did you try a make clean?
[01:14] <hatch> I'll try again
[01:14] <gary_poster> lint was definitely broken, but trivial to fix
[01:14] <hatch> yeah the odd thing was how did it get landed...
[01:15] <gary_poster> yeah, that's a good q
[01:15] <hatch> I wonder if it's the issue bcsaller ran into where it picks up a running test suite on another branch
[01:15] <hatch> so it 'passes' by thinking the other branch is its own
[01:16] <gary_poster> maybe, but the one failing test for me is the one I broke
[01:16] <gary_poster> I'll try switching to trunk in just a sec
[01:16] <hatch> very odd, fresh trunk pull and 6 errors
[01:16] <hatch> the failures are in app-cookies-extension.js
[01:17] <gary_poster> ok
[01:17] <gary_poster> I'll try to verify in a sec
[01:17] <rick_h_> cleaning here to look
[01:17] <gary_poster> thanks
[01:17] <bcsaller> hatch: we can change the test target to use random ports so we always fire servers in the proper mode
[01:18] <gary_poster> simpler solution might be to fall over harder if the port is already running
[01:18] <gary_poster> we simply complain now
[01:18] <gary_poster> which is actually kind of convenient :-P
[01:18] <rick_h_> +1
[01:19] <rick_h_> I know I landed a branch on accident due to that fact before
[01:20] <rick_h_> I get the cookie error, "cannot call setStyle of null" in the check() function
[01:20] <hatch> *phew* glad I wasn't the only one
[01:20] <gary_poster> rick_h_, my branch plus your check conflict branch were not friends.  They duked it out and your branch won. ;-) I'm redoing the core of my branch
[01:21] <rick_h_> gary_poster: :( sorry
[01:21] <gary_poster> rick_h_, heh, np
[01:21] <rick_h_> gary_poster: let me know if I can do anything to help
[01:21] <gary_poster> rick_h_, naah, Jeff and I just decided that your assumptions were better than the ones I had made
[01:21]  * hatch would like to note on the record that he does sometimes agree with rick_h_ :P
[01:22] <rick_h_> hatch: sssh, don't spread the word
[01:22] <hatch> lol
[01:22] <rick_h_> otherwise people will look twice when we do agree :P
[01:22] <gary_poster> lol
[01:22] <hatch> haha
[01:22] <hatch> ok now to figure out how to revert my branch to pre-trunk-merge
[01:23] <rick_h_> I can look at the test thing first thing in the morning. I reviewed bac's branch that hatch thinks is the issue and should be a simple thing. 
[01:23] <hatch> oh it forsure is - it's the one that made CI fail
[01:23] <hatch> but it's probably a trivial fix
[01:23] <rick_h_> hatch: right
[01:24] <hatch> I just am really busy tonight
[01:24] <rick_h_> hatch: he did touch index.html which probably threw off something
[01:24] <gary_poster> hatch you can just back out bac's branch.  bzr merge -r bad_revno..bad_revno-1
[01:24] <rick_h_> hatch: yea, I'm about to head to bed myself after doing the birthday cake bake off with the 3yr old
[01:24] <gary_poster> :-)
[01:24] <rick_h_> but can completely pick it up in the am. I did qa the branch, but didn't run tests locally with it. 
[01:24] <gary_poster> hatch uh I think I got that wrong
[01:24] <gary_poster> off by one :-)
[01:25] <hatch> I `bzr revert -r 1038`
[01:25] <gary_poster>  bzr merge -r bad_revno+1..bad_revno
[01:25] <rick_h_> hatch: so that reverts the whole tree to that state
[01:25] <gary_poster> if it works, go for it. :-)
[01:25] <gary_poster> yeah that's what I thought
[01:25] <gary_poster> while what I did
[01:25] <gary_poster> is a cherrypick
[01:25] <hatch> ohh ok ok
[01:25] <rick_h_> huh? I only see 1037
[01:25] <hatch> my local branch has more commits
[01:26] <rick_h_> gotcha, ok so you want -r 1036
[01:26] <rick_h_> since 1037 is the last one on trunk you want to back out
[01:28] <hatch> hmm it's giving me errors
[01:29] <hatch> so in order to revert the trunk commit which is 1039 in my branch
[01:31] <hatch> so I need to undo a commit and a merge
[01:31] <hatch> so revert -r1038
[01:32] <gary_poster> hatch if it is the most recent commit
[01:32] <gary_poster> then you can bzr uncommit
[01:32] <gary_poster> which just uncommits, then you can bzr revert (and maybe bzr revert --forget-merges)
[01:33] <gary_poster> maybe that's all the same thing--sorry
[01:33] <hatch> perfecto
[01:33] <hatch> thanks I was doing things in the wrong oder
[01:33] <hatch> order even
[01:33] <gary_poster> cool
[01:33] <hatch> there are a lot more blog posts about how to do these things in git
[01:33] <hatch> haha
[01:34] <hatch> ok gota run again have a good night all
[01:35] <gary_poster> :-) night
[08:59] <frankban> hazmat: ping, when you have a minute, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ? 
[12:07] <gary_poster> hey rick_h_ you around?
[12:12] <rick_h_> gary_poster: yep
[12:12] <rick_h_> gary_poster: finishing up going through the diff. Have time to walk me through a couple of bits?
[12:13] <gary_poster> thank you rick_h_! yeah sure
[12:13] <gary_poster> rick_h_, https://plus.google.com/hangouts/_/f3cad7e0300cc572c223e13157a2d685a8adcb2c?
[12:31] <rick_h_> gary_poster: you know, if we didn't think of it as conflict but more change indication the behavior makes more sense. I think I got hung up on 'there's no conflict technically' but there's definitely change to indicate to the usre
[12:32] <gary_poster> rick_h_, good point.  Can you think of a name for the viewlet function that would introduce less cognitive dissonance in that regard?
[12:33] <gary_poster> "doubleChange" ..."modelChangeAfterEdit"
[12:33] <gary_poster> "possibleConflict"
[12:33] <rick_h_> I was thinking of some way to indicate backgroud 
[12:33] <rick_h_> backgroundChange
[12:33] <benji> verbs are nice
[12:34] <gary_poster> but the databinding handles background changes if the field has not been edited rick_h_ 
[12:35] <gary_poster> benji, ack.  "handleBackgroundChangeAfterEdit"..."handleConflict"..."handlePossibleConflict"
[12:35] <rick_h_> gary_poster: definitely. I only mean in the single case
[12:35] <gary_poster> ah, a separate "handleConflict" and "handleBackgroundChange"?
[12:35] <gary_poster> both?
[12:36] <rick_h_> well, what are we naming? I was originall just speaking that in general I was thinking that the goal was to modify conflictux to handle conflicts correctly. 
[12:36] <gary_poster> f we were to introduce "handle" we'd have to go through the whole API...handleChange at the very least
[12:36] <gary_poster> rick_h_, I was thinking of naming the viewlet method that databinding calls in this case
[12:37] <gary_poster> (it is currently called "conflict")
[12:38] <rick_h_> yea, looking
[12:41] <rick_h_> binding.viewlet.indicateChange ?
[12:41] <rick_h_> if the value is changed and you've not changed it we don't idicate it at all
[12:41] <gary_poster> rick_h_, but we do: see the viewlet.changed method :-)
[12:42] <gary_poster> this case is all about the interaction from both sides
[12:42] <rick_h_> but I'm fine with it as is. I was just pondering why this seemed like we can't get a behavior that 'felt' nice and I think it was around sticking to the idea that it's for conflicts specifically
[12:42] <frankban> guihelp: I need two reviews and one QA for https://codereview.appspot.com/13549046/ . Anyone available? Thanks!
[12:42] <gary_poster> rick_h_, I think you are exactly right and just wanted to make our names match our thoughts
[12:43] <bac> frankban: i'll do a review right now
[12:43] <rick_h_> frankban: will peek at it in a sec. 
[12:43] <frankban> bac, rick_h_: thank you both!
[12:44] <rick_h_> gary_poster: doh, you're right of course. We do indicate modified lol. 
[12:44] <gary_poster> :-)
[12:44] <rick_h_> gary_poster: what about checkForConflict or something that seems more fuzzy "we're not sure wtf is here...but you should know about it"
[12:44] <gary_poster> heh
[12:45] <gary_poster> rick_h_, would be fine with that, yeah.  similar to my "handlePossibleConflict".  Both convey the idea better than what we have.  Maybe I'll sneak it into my next branch (last in the series!)
[12:46] <rick_h_> gary_poster: wooo! 
[12:46] <gary_poster> :-)
[12:52] <rick_h_> frankban: hah, nice for providing not just qa instructions but a qa script
[12:53] <frankban> rick_h_: yeah, that's the easiest thing to do with this kind of branches. I have a card for converting these QA scripts in actual functional tests
[12:55]  * gary_poster is going for hour walk soon, to slightly compensate for many hours spent over this week. :-)
[13:00] <rick_h_> frankban: you've made my day. I didn't realize there was a backport of futures
[13:01] <rick_h_> frankban: caught me off gaurd, thought it was only avail for 3.2+
[13:02] <frankban> rick_h_: :-) that's really cool indeed.
[13:30] <bac> hi frankban i'm getting this failure http://paste.ubuntu.com/6101649/
[13:31] <frankban> bac: interesting, is it intermittent? 
[13:31] <bac> frankban: no
[13:32] <bac> frankban: wait, yes it is intermittent.  5 runs, 4 errors
[13:33] <bac> frankban: 10 runs, 9 errors.  so it is mildly intermittent tending towards mostly failing.  :)
[13:34] <bac> frankban: i'm running on a saucy vm fwiw
[13:34] <frankban> bac: taking a look
[13:39] <frankban> bac: could you please try bzr pull and then run the tests again?
[13:41] <bac> frankban: no difference
[13:41] <rick_h_> timing issue? 5 runs here no problem
[13:42] <bac> rick_h_: perhaps.  my vm may be a little sluggish
[13:43] <rick_h_> 198 tests in 3.1s here
[13:45] <rick_h_> is juju-test still not in a ppa?
[13:49] <frankban> bac: could you try pull and tests again?
[13:52] <bac> frankban: different failure, about 20% of the time: http://paste.ubuntu.com/6101721/
[13:53] <benji> juju-gui: anyone know anything about this error I got while doing a make in a clean checkout? Error: No compatible version found: cryptojs@'cryptojs@>= 2.5.3'
[13:53] <bac> rick_h_: and my tests run in 2.95s, so my vm isn't slow at all
[13:53] <rick_h_> bac: cool yea. strange I can't dupe :/
[13:55] <rick_h_> I'm not on saucy though
[13:55] <frankban> bac: do you have that error if you disable test_cancel_started_deployment?
[13:55]  * bac tries
[13:56] <bac> yes, frankban
[13:58] <frankban> bac: ok, so, some of the tests in that module are racy in your configuration. and not well isolated. good to know. just to check if this problem is generated by this branch, could you please try to run the same tests in trunk?
[13:59] <bac> frankban: ok
[13:59] <frankban> bac: thanks
[14:01] <hatch> hey has anyone started fixing trunk yet?
[14:01] <rick_h_> hatch: gary submitted something last night
[14:01] <hatch> oh woops missed that
[14:01] <rick_h_> hatch: there was a follow up email 
[14:02] <gary_poster> benji, have not seen.  try make clean?
[14:02] <rick_h_> benji: hmm, do you have an offline cache it's not hitting? 2.5.3 is the latest in npm 
[14:03] <rick_h_> heh, updated 2 yrs ago...nvm
[14:03] <benji> gary_poster: tried; I'm trying a couple of other things, I think it is that checkout in particular (which is strange because it is just a branch from an updated trunk, with some changes from a WIP branch merged in)
[14:05] <bac> frankban: i do see that same failure on trunk about 10% of test runs
[14:05] <hatch> benji: the syntax is wrong in that error you posted - is that what it looks like in the shrinkwrap file?
[14:07] <benji> hatch/gary_poster: I figured it out!  I was re-using a shell session that happened to be running in an LXC container that isn't set up to do GUI dev.
[14:08] <hatch> haha nice
[14:10] <frankban> bac: hum... ok, so perhaps, if you agree, I can tackle this in another card. just one last request of pull from my branch and test again if you can? I changed one last thing in an old test
[14:10] <gary_poster> cool
[14:11] <bac> frankban: will re-test.  certainly cool with you making a new card and moving along
[14:11] <frankban> bac: cool, thanks
[14:12] <bac> frankban: on the 4th run the failure occurred
[14:12] <frankban> bac: and perhaps we can pair on that card once I am back ;-) I am not sure where to start to reproduce your configuration
[14:12] <bac> sure
[14:12] <frankban> bac: cool, creating the card.
[14:15] <frankban> card created in bundles
[14:24] <frankban> hazmat: thanks for reviewing and merging my branch!
[14:26] <hazmat> frankban, sorry about the delay
[14:27] <frankban> hazmat: np
[14:45] <benji> the bane of my existence: "Illegal comma at end of object literal"
[14:45] <rick_h_> benji: I was doing python wed night and realized "I can leave a trailing comma! It's so beautiful!"
[14:45] <benji> pfft
[14:45] <hatch> oh noes you have to write clean code "oh the horror" :P
[14:46] <rick_h_> comma first came all from the issue of not leaving a trailing comma
[14:46] <rick_h_> plus it's an IE issue...who cares about IE :P
[14:46] <rick_h_> err, except us that is
[14:46] <hatch> no it came from a bunch of geeks who didn't get enough drama in highschool so they need to stir some up now
[14:47] <hatch> lol
[14:47] <benji> its the non-trailing-comma crazies that lead people to do this: 
[14:47] <benji> x = foo(bar
[14:47] <benji>   , baz
[14:47] <benji>   , biz);
[14:47] <hatch> lol that's so ugly
[14:47] <rick_h_> yep, what I did in php 
[14:48] <hatch> haha sad
[14:48] <benji> I have seen this in production Python code too, insanity on top of insanity.
[14:48] <hatch> I can honestly say that a trailing comma hasn't ever caused me to lose sleep
[14:48] <benji> I'm special like that.
[14:48] <hatch> yeah in python it makes no sense
[14:48]  * rick_h_ mumbles about special :P
[14:48] <hatch> lol
[14:49] <hatch> Friday!
[14:52] <hatch> last night I educated 4 other devs on Juju
[14:52] <hatch> they thought it was really cool
[14:52] <hatch> they already knew about alternatives like docker.io so maybe we need to find some geek cred somewhere to make it viral
[14:53] <gary_poster> jujugui call in 7
[14:55] <hatch> jcastro: when discussing it with these guys the hardest thing they had to understand was how relations work - it was hard to wrap their head around what happens when a relation happens - as in how does the app know about it's mongo connection for example
[14:57] <hatch> gary_poster: we are now using the link in the event on the calendar?
[14:57] <gary_poster> hatch yes.  jujugui call in 2.
[15:00] <gary_poster> almost there
[15:01] <gary_poster> benji bac frankban https://plus.google.com/hangouts/_/0ae499f5c2e2e483949d5f96802c30fdf603af84
[15:01] <gary_poster> (from calendar)
[15:01] <gary_poster> sorry frankban :-P
[15:01] <frankban> :-)
[15:53] <hatch> bcsaller: on the review
[15:53] <hatch> bcsaller: should this not require a QA?
[16:16]  * gary_poster to optician biab
[16:30] <hatch> bcsaller: review done - qa failed :(
[16:33] <hatch> rick_h_: so looking at these unit buttons - you are working on the 'remove' button?
[16:33] <rick_h_> hatch: yes, I've got the buttom working and looking at how to test it
[16:33] <rick_h_> I don't see a simliar test in the python env either. 
[16:34] <rick_h_> hatch: if you want I can push up what I've got and I can go test the go backend stuff for retry/resolve
[16:34] <hatch> I was pretty confident those worked in python.....because I wrote them :P
[16:34] <hatch> so I'm really curious what happened
[16:34] <rick_h_> hatch: yea, I bet they work, it's the go side that doesn't work and the python version that doesn't have an env test in the test_env_python
[16:35] <bcsaller> hatch: I'll look into that, odd that that same file passes the test.
[16:35] <rick_h_> hatch: did you want to chat then?
[16:35] <hatch> bcsaller: yeah that's what I was thinking....might be a side effect of you calling the methods directly in the test instead of relying on the whole app stack
[16:36] <hatch> rick_h_:  gimme a few to get a new env setup
[16:36] <rick_h_> hatch: rgr
[16:40] <hatch> rick_h_: ok calling
[16:45] <benji> hatch: you and I both wrote exactly the same commend on exactly the same line ("s/this//")
[16:45] <hatch> rofl
[16:45] <hatch> ^5
[16:46] <benji> ^5
[17:11] <hatch> what does the fox say? http://www.youtube.com/watch?v=jofNR_WkoCE
[18:09]  * rick_h_ does a happy dance avert your eyes
[18:10] <bcsaller> hatch: fixed issue with branch I think if you'd take another look when you have a minute
[18:14] <rick_h_> jujugui need a review please https://codereview.appspot.com/13706043
[18:15] <rick_h_> I did a QA in my local lxc, if anyone wants to dupe instructions are in the proposal, but missing the steps to set the branch over
[18:15] <rick_h_> hatch: is the other branch going ok then? Or did you need a hand on that once this goes through?
[18:16] <hatch> rick_h_: I took an early lunch so haven't put a ton of time on it yet
[18:16] <benji> rick_h_: looking
[18:16] <rick_h_> hatch: k
[18:16] <hatch> just reviewing bcsaller new branch
[18:16] <rick_h_> benji: ty
[18:16] <rick_h_> hatch: ok, going to hit EOD in an hour so just wanted to see what I can do to help unblock the release. If you've got it then I'll move along for the rest of the day
[18:16] <benji> I have a cousin named "Ty" ("Tyson").
[18:16] <rick_h_> benji: :P ty ty
[18:17] <benji> heh
[18:17] <hatch> you COULD do it :P
[18:17] <hatch> jk
[18:17] <rick_h_> what's nice is you can read that either thank you ty, or ty thank you
[18:17] <hatch> bcsaller: your diff is all messed up now from the trunk merge :(
[18:19] <hatch> I wonder why that happens
[18:19] <hatch> it should pickup the diff properly
[18:19] <hatch> hehe implements!
[18:20] <hatch> bcsaller: so I see the fix for the qa failure - wondering if we should add a test for the full stack?
[18:21] <rick_h_> benji: replied, let me know if you disagree or have a better idea for a test to catch this type of issue going forward
[18:22]  * benji looks
[18:22] <benji> rick_h_: +1
[18:22] <rick_h_> benji: cool thanks for the review
[18:22] <benji> my pleasure
[18:23] <BradCrittenden> gary_poster: ping
[18:23] <gary_poster> bac on call will ping
[18:23] <bac> ok
[18:23] <hatch> bcsaller: qa failed again :)
[18:23] <hatch> did it not fail for you?
[18:24] <bcsaller> it worked here
[18:24] <bcsaller> let me try it again
[18:24] <hatch> I get two errors "Relation added without matching service"
[18:25] <bcsaller> I get that now too, that from the trunk merge, it does work though which is odd
[18:25] <bcsaller> the proper objects exist in both the fakebackend db and the client one
[18:26] <bcsaller> ahh, the interaction with the delta stream is different
[18:26] <bcsaller> the services are not in the delta data for this change maybe, but they come through anyway
[18:29] <hatch> ahh - also bcsaller there is that delay from when I drop the file until the delta comes back...so on a real env those services could take...hours to come up?
[18:30] <hatch> *potentially*
[18:30] <bcsaller> hatch: absolutely 
[18:30] <hatch> so won't the user think that it's broken then?
[18:30] <bcsaller> there is no UX around the status call
[18:30] <bcsaller> at this time, sure, that UX is a 'later' task
[18:31] <bcsaller> integrated with notifications we can status running imports
[18:31] <bcsaller> they queue as well so two dnd actions will result in pending imports
[18:31] <hatch> ohh ok - could we just create a Panel which says 'deployment imported successfully, please wait for the services to become active'
[18:31] <bcsaller> and the delta does the real work at that point
[18:31] <hatch> just 'something' to tell the people that it's working
[18:31] <bcsaller> which is no different than today
[18:32] <bcsaller> could change the message, sure
[18:33] <hatch> the new notifications can't come soon enough :)
[19:00] <rick_h_> boooo stupid ci, why for you cranky today?
[19:01] <gary_poster> bac ping?
[19:05] <hatch> rick_h_: yeah I have no idea what's going on there
[19:05] <rick_h_> hatch: yea, looks like it didn't come up?
[19:05] <rick_h_> but there's another one wiithin a minute that passes
[19:05] <hatch> for some reason it can't restart it
[19:06] <rick_h_> do we run multiple IE runs for each submission? /me didn't expect to see ie runs at 14:(47, 48, 50)
[19:08] <hatch> I don't understand the question
[19:09] <rick_h_> hatch: hangout real quick?
[19:09] <hatch> sure
[19:45] <hatch> my 'server room' ran out of plugins
[20:10] <benji> juju-gui: I have a branch up for review https://codereview.appspot.com/13592047/
[20:11] <bac> benji: i'll look
[20:11] <benji> thanks
[20:11] <bac> benji: i see you just missed the 400 line limit
[20:12] <benji> so close
[20:21] <bac> benji: your branch may be very long but it makes up for it through brute force boringness
[20:22] <benji> it's much like my original operas
[20:22] <gary_poster> heh
[20:23] <hatch> lol
[20:23] <gary_poster> jujugui I have a pretty short branch long on tests and short on other code (but it hooks up the cancel buttons!).  May I have a reviewer? https://codereview.appspot.com/13677044/
[20:23] <bcsaller> gary_poster: checking now
[20:23] <gary_poster> thank you bcsaller 
[20:49] <hatch> bcsaller: did you happen to push up a fix for that last failure?
[20:49] <hatch> just want to make sure I didn't miss it and am holding you up
[20:50] <bcsaller> hatch: Still working on it, there is some disparity in how the relation import works wrt endpoint normalization, it does the import but sends only partial information in the delta
[20:50] <hatch> hmnm, anything I can help with?
[20:50] <hatch> or is it a one man project?
[20:52] <bcsaller> hatch: thanks for the offer, I'll poke at it a little more, if I don't have something soon I might ping you
[20:52] <hatch> sure thing
[20:57] <gary_poster> jujugui I just made a team Google calendar.  everyone should have privs to edit it.  I scheduled everyone on the calendar, biwweekly, as we discussed.
[20:57] <gary_poster> for the exploratory QA day I mean
[20:57] <bac> gary_poster: got it
[20:57] <hatch> coolio
[20:57] <gary_poster> :-)
[20:58] <hatch> the 27th is the apps day off of being qa'd
[20:59] <hatch> every second friday is it's EDO
[20:59] <gary_poster> :-)
[21:04] <gary_poster> bye y'all!  have a great weekend!
[21:04] <hatch> you too
[21:04] <hatch> cya!
[21:57] <hatch> uploading 600pics to g+ sure takes a long time
[21:57] <hatch> :)
[21:59] <rick_h_> heh
[21:59] <hatch> it would be faster from my phone but I couldn't figure out how to upload them via the G+ app
[22:00] <hatch> I could only 'share' them which would share the low res version
[22:00] <rick_h_> set it to auto upload photos and sync
[22:01] <rick_h_> but yea, I use flickr because I hate the G+ photo integration these days
[22:01] <hatch> I hate flickr more actually haha
[22:01] <hatch> best I've found is smugmug
[22:04] <hatch> I actually have a lot of pictures of the back of your head
[22:04] <hatch> you gota quit walking infront of me
[22:04] <hatch> lol
[22:07] <rick_h_> lol, what?
[22:07] <hatch> on the team suppers and stuff
[22:07] <hatch> you apparently walk in front of me a lot
[22:07] <hatch> haha
[22:08] <rick_h_> sorry, don't realize it I guess
[22:08] <hatch> lol it's no big deal
[22:08] <hatch> this htc one takes some darn good pictures
[22:10] <hatch> rick_h_: so on your machine are you always running in the lxc's ? Or do you use some other trickery to also test it spinng up new machines?
[22:10] <rick_h_> hatch: well I have a gui and charmworld lxcs always running. 
[22:11] <rick_h_> hatch: the juju stuff I bootstrap/destroy as I need
[22:11] <hatch> oh ok but always on the lxc...you aren't running openstack or anything
[22:11] <rick_h_> no
[22:11] <rick_h_> just lxc so far. If I need more than that I'd go to ec2/prodstack
[22:12] <hatch> ok cool, my extra machine is an i5 with 8gb of ram so that should be more than enough to test out a pretty solid lxc juju deployment
[22:12] <rick_h_> yea
[22:12] <rick_h_> though my daily run on my desktop tends to run around 10gb of ram
[22:12] <rick_h_> but that's with vbox/windows always running, the two work lxcs, etc
[22:12] <rick_h_> chrome/ff both 
[22:15] <hatch> ahh yeah ok
[22:15] <hatch> this thing won't even be running a gui
[22:16] <hatch> so it should be good for juju testing
[22:16] <hatch> at 8gb
[22:16] <rick_h_> cool
[22:19] <hatch> the trick will be figuring out how to expose it to the outside world so that I can use it on sprints
[22:19] <rick_h_> ssh tunnels ftw
[22:22] <hatch> the issue seems to be my switch and router
[22:22] <hatch> they never could agree on anything