[00:07] <hatch> rick_h_ curious, did you ever create that upstream bug for the kernel?
[00:08] <rick_h_> hatch: no, honestly it's like 10th on my list of stuff atm
[00:08] <hatch> :-) no problem just didn't see a link so was going to track it if it was
[00:08] <rick_h_> though did make my appt to get my snow tires off and get some new tires on the summre wheels :)
[00:08] <hatch> ooooo nice :) I gota do the same
[00:08] <hatch> maybe this weekend
[00:09] <hatch> I swap them myself....unfortunately 
[00:09] <rick_h_> hatch: heh, I'm sitting here trying to get a local env to bootstrap to test out working with local charms
[00:09] <rick_h_> hatch: yea, I don't have storage space and such so I use their valet service
[00:09] <hatch> you've seen the emails from hazmat and I/
[00:09] <rick_h_> they store them and just swap them off since their diff wheel sizes
[00:09] <rick_h_> hatch: yea, I want to verify what you CAN do 
[00:09] <rick_h_> hatch: I want to deploy a local charm, see if we can deploy another instance with a new name via cli
[00:09] <rick_h_> if we can, the code is there, it's wiring it
[00:10] <rick_h_> kapil's email seemed to focus on deploying a local charm that's not yet uploaded
[00:10] <rick_h_> but there's note on the auto incrementing revision
[00:10] <hatch> I couldn't figure out a syntax to deploy a local charm via the CLI but I'm hoping I was wrong
[00:10] <hatch> that's the biggest limitation atm
[00:10] <rick_h_> hatch: yea, maybe it's not there. 
[00:10] <rick_h_> I'll bug someone on -core maybe
[00:11] <hatch> I learnt something about python today which I felt was a little dumb....you can call functions without () so it looks like a property but it's actually a function
[00:11] <rick_h_>  right
[00:12] <rick_h_> call help on it that way
[00:12] <hatch> it's a little cool....but not good for discoverability imho
[00:12] <rick_h_> help(str.something)
[00:12] <rick_h_> well you'll notice the type 
[00:12] <rick_h_> I mean it's the same in JS
[00:12] <hatch> right but when you're reading the code of some passed in value you just assume it's a property
[00:12] <rick_h_> functions are objects
[00:12] <rick_h_> ah, heh that's functional for you :)
[00:13] <rick_h_> but again, same as JS. pass in a callback/etc
[00:13] <hatch> charm.charm_url <---- this is actually a function....but charm._charm_url is a property
[00:13] <hatch> so unless you're familiar with the code base, you don't know that
[00:14] <rick_h_> yea, that's a bit of bad form as methods should be named something methody, get_charm_url
[00:14] <hatch> I came across it in a log `log.debug("xxx %s", charm.charm_url)
[00:14] <hatch> and it was throwing an error
[00:15] <hatch> so it caught me off guard that a fn was being called
[00:15] <rick_h_> heh
[00:15] <rick_h_> yea
[00:16] <rick_h_> bah, lxc env is broken again it seems
[00:16] <hatch> but I suppose you're right, callbacks and the like in js are similar
[00:16] <hatch> they just release 17.7
[00:16] <rick_h_> yea, but not in trusty atm
[00:16] <hatch> maybe it's fixed in there?
[00:16] <hatch> ohh
[00:16] <rick_h_> it'll take time, but yea, we'll see. 
[00:16] <rick_h_> my envs are a mess
[00:16] <hatch> haha
[00:17] <rick_h_> I've had so many broken envs that I think my configs/existing envs are in trouble
[00:17] <rick_h_> working on my desktop, yay for more than one machine lol
[00:17] <hatch> haha 
[00:18] <hatch> well even though my task was not completed/possible I learnt a lot of pythony bits so I'm considering this a success :)
[00:18] <rick_h_> heh cool
[00:23] <rick_h_> hatch: so I can do this
[00:24] <rick_h_> ah bah nvm
[00:25] <hatch> :-)
[00:25] <rick_h_> yea, make sure to cd before you think it did work lol
[00:25] <rick_h_> well, add it to the GUI feature work list we want to do
[00:26]  * rick_h_ grumbled he could have sworn being told it was possible
[00:28] <hatch> it IS possible if the charms are on the users file system
[00:28] <hatch> then the deployer can deploy from the local file system
[00:30] <rick_h_> ok, good to know. I'll have to work on some wording and emails tomorrow
[00:33] <hatch> yeah - it's unfortunately a ton of work to do what we want to do
[00:35] <rick_h_> I don't know it's more than stuff like local charm support to begin with :) 
[00:35] <rick_h_> but it's another feature
[00:37] <hatch> yeah - I'm wondering if we 'need' this feature
[00:37] <hatch> it's a pretty rare usecase which will be handled by ___
[00:38] <hatch> so....maybe the best reply would be how to do it via the CLI
[00:38] <hatch> it's not ideal but 'should' work
[00:38] <hatch> (we should probably test it first)
[00:39] <rick_h_> hatch: yea, pretty much. 
[00:40] <hatch> would you like me to look into that in the AM or are you trying that now?
[00:40] <hatch> the CLI only approach
[00:40] <rick_h_> no, I think we'll put this away and write up a nice "here's the temp path" email
[00:42] <hatch> ok I'll slide the card into daily
[00:50]  * hatch flicks the no-more-work-today switch
[02:24] <hatch> evening kadams54 
[02:24] <kadams54> evening
[02:24] <rick_h_> it's EOD, go to bed you guys :P
[02:25] <hatch> rick_h_ lol I've been debuggin a python script!
[02:25] <hatch> https://github.com/SublimeText/Origami/issues/59
[02:25] <hatch> I want vim style PANE management
[02:25] <hatch> :P
[02:30] <hatch> also did this https://plus.google.com/118445028821328031751/posts/PLZrunniCC4
[02:33] <kadams54> Heh
[02:34] <kadams54> rick_h_: your evil plans for state refactoring have run afoul of YUI. We'll have to talk more tomorrow :-)
[02:36] <hatch> lol
[02:37] <hatch> kadams54 are you going to push the state into a state array so that state[state.length-1] is the current state and state[state.lenth-2] was the previous state?
[02:37] <hatch> that's one approach I was thinking of
[02:37] <hatch> kind of a persistent data store style
[02:37] <kadams54> Haven't gotten that far yet
[02:37] <kadams54> Right now I'm just trying to hide current and previous state objects behind the API
[02:38] <kadams54> So that clients of state don't know or care about how they're implemented
[02:39] <kadams54> http://pastie.org/private/mbzgddvoyee0svattwa
[02:39] <kadams54> Calling set() would set the field in the current state, and setPrevious() would set the field in the previous state.
[02:40] <kadams54> But YUI tries to call set('destroyed') as part of destroy()
[02:40] <hatch> I think usually the states are set as complex objects
[02:40] <hatch> ohh yeah you're overloading set
[02:40] <kadams54> Yeah
[02:40] <hatch> can't do that
[02:40] <kadams54> Not really overloading
[02:40] <kadams54> So much as colliding :-)
[02:40] <kadams54> Or smashing
[02:40] <hatch> not on a Y.Base derived class (which is, like, all of them :) )
[02:41] <kadams54> So we'll need to figure out new names
[02:41] <hatch> haha yeah
[02:41] <hatch> state.save({...})
[02:42] <kadams54> It's not really a save
[02:42] <kadams54> You're updating one field within the state object
[02:42] <kadams54> update() already exists
[02:42] <hatch> well...
[02:42] <kadams54> State objects are really simple right now - they're basically just (to use the python term) dictionaries…
[02:43] <hatch> save could push the current state into previous, then merge this object over the old one to create the new state
[02:43] <kadams54>       this._previous = {
[02:43] <kadams54>         charmID: null,
[02:43] <kadams54>         querystring: null,
[02:43] <kadams54>         hash: null,
[02:43] <kadams54>         search: null,
[02:43] <kadams54>         viewmode: null
[02:43] <kadams54>       };
[02:43] <kadams54> So if you want to update 'charmID' in the this._current state object, you'd call state.set('charmID', 'foo')
[02:43] <hatch> so instead of needing to 'set' you would state.save({charmID: 1234})
[02:44] <kadams54> Yeah…
[02:44] <hatch> and it would merge the two, giving you the value you need
[02:44] <kadams54> save has conntations for me
[02:44] <kadams54> It implies a wholesale change of the object
[02:44] <hatch> save or me means "update and dispatch"
[02:44] <kadams54> Thinking about the way the mongo API uses it
[02:44] <kadams54> I'd rather do something like "patch" or "update"
[02:44] <hatch> so update would also dispatch?
[02:45] <kadams54> and then figure out a better name for the update method
[02:45] <kadams54> Not sure what you mean by dispatch
[02:45] <hatch> after updating the state 'something' needs to dispatch the changes to update the DOM
[02:45] <hatch> else you're just changing a object
[02:46] <kadams54> Or you're "just" changing a object
[02:46] <kadams54> So that it's in the proper state for when a 'navigateView' event fires
[02:46] <kadams54> And then it can generate the right URL
[02:46] <kadams54> Which results in the proper parts of the DOM being updated
[02:46] <kadams54> So nothing is necessarily being dispatched when the various state bits are being updated
[02:47] <hatch> ohh ok I was thinking of ditching the navigate view business and having state fire a 'dispatch' event which could the trigger the changes on all the listeners
[02:47] <hatch> because some changes aren't going to be routable
[02:47] <hatch> like showing the ghost inspector for example
[02:48]  * kadams54 sticks fingers in ears and says "la la la"
[02:48] <kadams54> That's not my concern at the moment :-)
[02:49] <hatch> haha - I have a problem with thinking too far ahead 
[02:50] <hatch> anyways in YUI there is a convention for providing a single and multiple setter methods
[02:50] <kadams54> I'm pretty sure rick_h_ explained how non-routable changes were handled, but I forget what he told me
[02:50] <kadams54> I remember "non-navigable" or something similar being written on the whiteboard
[02:50] <hatch> setStyle('foo', 'bar') vs setStyles({...}) you may want to do something similar
[02:51] <hatch> setState() setStates()
[02:51] <kadams54> Yeah
[02:51] <kadams54> That would be nice
[02:51] <kadams54> Although state.setStates() is a bit awkward
[02:52] <kadams54> We really need a better name for the bits that make up a state
[02:52] <hatch> how do you mean?
[02:52] <hatch> if you think of each view as having a 'state' it makes sense
[02:52] <kadams54> It reads as redundant to me
[02:52] <hatch> so State is a state manager
[02:52] <hatch> in a sense
[02:52] <kadams54> Yeah, it really is
[02:52] <kadams54> And was called that at one point
[02:53] <kadams54> But browser.state is shorter that browser.stateManager
[02:53] <hatch> meh
[02:53] <hatch> :)
[02:53] <kadams54> The python developer in me wanted to make it browser.sm
[02:53] <hatch> you should write go
[02:53] <hatch> then it could be b.am
[02:53] <hatch> lol
[02:53] <kadams54> lol
[02:54] <hatch> we're gona be stuck with this api for a while so might as well do it 'right' :)
[02:54] <kadams54> There's a convention in SQLAlchemy to have your model's manager object accessible from an m attribute, so Foobar.m.find(...)
[02:54] <hatch> whatever that means in this sense haha
[02:54] <kadams54> Yeah
[02:54] <kadams54> I think we'll get there…
[02:55] <kadams54> rick_h_ and I were talking about how you have to balance small, bite-sized tasks with big picture thinking
[02:56] <hatch> yup
[02:56] <kadams54> There needs to be a sense of where things are going (thinking ahead) so that your code is well-ordered
[02:56] <kadams54> But at some point you have to zoom in again in order to start getting stuff done
[02:56] <hatch> setState and setStates could fire a 'stateUpdated' method on the stateManager which view/viewManagers could listen for and react to
[02:57] <hatch> that's probably the cleanest approach and provides a ton of flexibility 
[02:57] <hatch> I'm not sure how to distinguish between routable and non-routable state changes
[02:58] <kadams54> Yeah, there's one "clean up these views" method in browser.js that needs to be called after the update()
[02:58] <hatch> but that's probably for another day )
[02:58] <hatch> yeah I don't like that
[02:58] <hatch> well....not that I don't like it
[02:58] <hatch> I'd prefer a more detached approach
[02:58] <kadams54> Right now we just explicitly call it, e.g:
[02:58] <kadams54> this.state.update()
[02:58] <kadams54> this._cleanOldViews()
[02:58] <kadams54> But we've talked about that needing to switch to an event-based approach on down the road
[02:59] <hatch> yeah it would be nice if the state module was a self contained ball which you pushed things into and it told it's listeners when something interesting happened
[02:59] <kadams54> We've also talked about events in the other direction
[02:59] <kadams54> That State would subscribe to other events
[02:59] <kadams54> And then know when it needs to update or save based on those events
[02:59] <kadams54> Then you wouldn't need to call update() or save() explicitly anywhere
[03:00] <hatch> hmm that feels like an inversion of responsibility on the face of it...
[03:02] <hatch> YUI's event system would allow it
[03:02] <hatch> but my head is stuck on a stateManager being a database of sorts
[03:03] <hatch> stateManager.listenFor('inspector:showUnit'); // pseudo code
[03:03] <hatch> nah that's from outside
[03:03] <hatch> it would have to be
[03:04] <hatch> this.listenFor('inspector:showUnit')
[03:04] <hatch> which means the stateManager would have to be updated whenever we added a new interaction to the app.....
[03:04] <hatch> sorry I'm just thinking about this outloud
[03:04] <hatch> :)
[03:35] <kadams54> np
[03:36] <kadams54> Sometimes you just need a sounding board
[03:36] <kadams54> Though I'm heading to bed now :-)
[13:14]  * frankban lunches
[13:53] <frankban> rick_h_: morning, can we have a call when you have a minute?
[13:54] <rick_h_> frankban: sure thing
[13:55] <rick_h_> frankban: https://plus.google.com/hangouts/_/7ecpjl135481h8o5058gu7643s
[14:06] <hatch> rick_h_ when you're done with frankban I need some guidance on the card I should be working on - I think all the Ready To Code's are blocked
[14:06] <rick_h_> hatch: k, shoot me a url please
[14:07] <hatch> just reuse ^ one
[14:07] <hatch> :) they stay active for a bit...not sure how long without anyone in them 
[14:10] <frankban> rick_h_: cards created
[14:14] <rick_h_> frankban: thank you much
[14:16] <hatch> lol
[14:16]  * hatch waves 
[14:16] <rick_h_> oops
[14:16] <rick_h_> sorry about that, on the mac and bad tap on the trackpad
[14:16] <hatch> yeah it happens
[14:16] <hatch> apparently the new air's will not have a clicky trackpad
[14:16] <rick_h_> anyway, does that help then?
[14:16] <hatch> I think that's a horrible idea
[14:16] <hatch> yup
[14:17] <hatch> thx
[14:17] <hatch> I'll create a card
[14:17] <rick_h_> lol cool
[14:23] <Makyo> Whew, plumber has plans that don't involve digging up the foundation.
[14:23] <rick_h_> Makyo: always a good thing :)
[14:23] <hatch> yay
[14:24] <hatch> I had an issue like that - the pipe between the floor (our water comes in in the basement floor) and the shut off was leaking but the pipe was so short I thought they may need to smash up the floor
[14:40] <Makyo> Yeah.  Ours is this polybutylene piping that's not been used in years for good reason.  No clue where the fracture is, but at least there's a fix.
[14:40] <hatch> yeah smashing concrete is not cheap - or fun if you're doing it yourself :)
[14:42] <rick_h_> yea, had to do that when our sump died
[14:43] <rick_h_> we had some funky non hole in the ground sump setup with a pump/piping through the floor
[14:43] <hatch> uh oh....jumpy d3's
[14:43] <rick_h_> they had to bang out the floor to put in a more usualy sump
[14:44] <hatch> when I did my basement bathroom I had to smash in a shower drain....and carry out all the broken concrete
[14:45] <Makyo> hatch, QA on my branch, or trunk?
[14:45] <Makyo> hatch, also, what do you think about my assets vs utils comment
[14:45] <Makyo> ?
[14:46] <hatch> I don't feel very strongly about it
[14:46] <Makyo> oh, there are the replies, nevermind
[14:46] <hatch> :)
[14:47] <hatch> :-)
[14:50] <Makyo> jujugui call in 10
[14:50] <rick_h_> jujugui call in 10, kanban please
[14:50] <rick_h_> curses
[14:51] <Makyo> Hah!
[15:00] <Makyo> jujugui call now ish
[15:10] <frankban> Makyo: branch?
[15:10] <Makyo> frankban, https://github.com/juju/juju-gui/pull/208
[15:45] <hatch> so that hangout used up 66% of my battery lol
[15:46] <hatch> wow
[15:46] <rick_h_> hatch: yea, killed me here about 50%
[15:46] <rick_h_> multi HD video is hard, let's go shopping
[15:46] <hatch> yeah there is a bandwidth scaler but there should really be a quality one too
[15:47] <hatch> unless the CPU load doesn't change much
[15:47] <rick_h_> video card load
[15:49] <hatch> yeah and I have the discrete card too so that can't be easy on the battery
[15:49] <hatch> this 'moom' looks like it has a nice featureset
[15:50] <hatch> was kind of hoping for keyboard available scaling though
[15:50] <hatch> like window resizing in vim
[15:50] <hatch> pane resizing
[16:01] <kadams54> If only Mac had vim
[16:01] <kadams54> ;-)
[16:04] <hatch> haha - I was looking for one for Sublime, I found it but there is a pretty big bug in it
[16:06] <hatch> https://github.com/SublimeText/Origami/issues/59
[16:07] <kadams54> Which reminds me… time to give Atom a whirl
[16:08] <hatch> I've seen reviews that it's slower than sublime, it kind of lags, but it is still alpha.....after 6 years
[16:08] <hatch> lol
[16:25] <hatch> rick_h_ posted a good link about vim to G+ which makes an excellent case for 'modes' - too bad vim is so non-user friendly to set up and get started with
[16:26] <hatch> it has the core - someone just needs to write a good UI for it
[16:26] <rick_h_> yea, learning curve required
[16:26] <hatch> well even after the learning curve it's not very user friendly
[16:26] <hatch> package management, trying to find keybindings, etc etc etc
[16:27] <hatch> I think gvim was maybe trying to do that but didn't go far enough
[16:27] <rick_h_> part of the learning curve :)
[16:27] <hatch> lol
[16:34] <rick_h_> and the board fills back up wheee
[16:35] <rick_h_> here comes round 3!
[16:35] <hatch> any idea how we are doing on estimation vs completion?
[16:35] <rick_h_> hatch: we're doing really well
[16:35] <hatch> noice
[16:36] <rick_h_> hatch: so first cycle the math says 2 points per day per dev we did 79/86 points. This time we did 102/100
[16:36] <rick_h_> so the team is rocking it
[16:36] <hatch> those both include cards w/o counts too right?
[16:37] <kadams54> guihelp PR for State API cleanup has landed: https://github.com/juju/juju-gui/pull/209
[16:37] <hatch> kadams54 on it
[16:37] <rick_h_> hatch: no, that's just cards with counts. That includes the unsched tag which I get points to
[16:37] <kadams54> hatch: thanks!
[16:37] <rick_h_> so it's scheduled and unscheduled work, but not counting cards like "do release"
[16:37] <hatch> rick_h_ ahh cool
[16:37] <hatch> awesome
[16:37] <rick_h_> so first cycle we did 20 points of unsched work, 12 this cycle
[16:37] <hatch> sounds like we are right where we need to be
[16:37] <rick_h_> but those go into the 79/102 completion numbers
[16:38] <rick_h_> hatch: yea, definitely all good and great work from the team
[16:38] <kadams54> hatch: on vim, use janus: https://github.com/carlhuda/janus
[16:38] <rick_h_> I'm completely happy to put all this down for mramm
[16:38] <kadams54> Janus is the Ubuntu of vim - lets you get up and running with a good set of plugins and config
[16:38] <rick_h_> except don't, I'll argue with kadams54 about it over lunch now
[16:39] <rick_h_> speaking of which, afk for lunch biab
[16:39] <kadams54> rick_h_is crazy, but I guess we have a lunch conversation topic :-)
[16:39] <hatch> lol!
[16:39] <hatch> kadams54 I'll look at this janus at lunch later thx
[17:12] <hatch> oo this Amethyst pane manager looks really nice rick_h_  
[17:16] <hatch> hmm saving the db is not going to work
[17:16] <hatch> deltas or commands might be the best way
[17:17] <hatch> well it would work
[17:17] <hatch> but it's a lot of work
[17:19] <hatch> ehhhh maybe
[17:29] <hatch> https://twitter.com/FromAnEgg/status/449598755239497728 anyone?
[17:37] <rick_h_> hatch: can you not just json.dumps(complex) ?
[17:37] <rick_h_> hatch: JSON.stringify(window.location)
[17:38] <rick_h_> then copy/pate?
[17:38] <rick_h_> paste?
[17:38] <hatch> yeah I was hoping for a plugin or a script or something
[17:38] <hatch> so that we could generate these outputs easily for demo purposes and the like
[17:38] <rick_h_> stick some dev utils on app? 
[17:39] <rick_h_> app.dev.dumpDB()
[17:39] <rick_h_> ?
[17:39] <hatch> yeah I just don't want to write it myself
[17:39] <hatch> it feels like something that should exist
[17:39] <rick_h_> JSON.stringify exists? You just need a few lines in a function to walk the data you want to output
[17:40] <rick_h_> I feel like I'm missing something that makes this larger/harder than it seems
[17:40] <hatch> I want to pass a complex object the output from a db parse method to a json stringify which will then save that output to a text file on disk
[17:41] <hatch> I'd like it to not have to rely on the user to have to open the console and do manual work
[17:42] <hatch> it's probably easy to do via the File API but I'm asking the hivemind before i put any time on it :)'
[17:42] <rick_h_> hatch: but this is for 5 devs, and we'll cache the 'suggested base' 
[17:42] <hatch> they always ask for more demo materials lol
[17:42] <hatch> but I suppose
[17:42]  * hatch scales back
[17:45] <rick_h_> hatch: yea this is a helper for us to get through the next few weeks of dev
[17:45] <rick_h_> not a published feature for 'users'
[17:45] <rick_h_> so scale back to 'I can debug easier than now'
[17:45] <rick_h_> type levels
[17:45] <rick_h_> please :)
[17:45] <hatch> Oh Kay
[17:45] <hatch> btw you should take a look at Amethyst it looked like it was more along the lines of the requirements
[17:46] <hatch> for the pane manager
[17:47] <rick_h_> hatch: very cool then will try that one as well
[17:47] <rick_h_> back on linux now with a proper tiling WM :)
[17:49] <hatch> hah yeah - I think I'll install Amethyst tonight and give it a go - window management has been a big gripe of mine for osx
[17:51] <hatch> interestingly enough there is a max length for a console output heh
[17:51] <hatch> darn
[18:21] <hatch> hmm interesting, apparently we rely on more than just the db
[18:21] <hatch> :)
[18:25] <hatch> ok pushing into the db is not going to work
[18:25] <hatch> going to have to rely on deltas like we do with real envs
[18:26] <hatch> but first....lunch
[19:08] <rick_h_> jujugui I'm running out a bit early today. Thanks for the great cycle and have a good weekend! It'll be a fun next cycle. 
[19:08] <Makyo> Cheers, hav ea good weekend
[19:12] <hatch> kadams54 I'm not sure YUIDoc has a crosslink syntax like you had used there
[19:13] <hatch> kinda too bad really
[19:13] <hatch> http://yui.github.io/yuidoc/syntax/index.html
[19:13] <hatch> oh it does
[19:13] <hatch> look at that
[19:13] <hatch> craaaazy
[19:13] <hatch> learn something new every day
[19:15] <kadams54> Hah, yeah. Was just going to paste this: http://yui.github.io/yuidoc/syntax/index.html#cross-referencing-modules-and-classes
[19:15] <kadams54> But then you spoiled my big "booyah" moment
[19:18] <hatch> lol
[19:18] <hatch> that must be newish
[19:18] <hatch> I haven't seen any of this hbs stuff before
[19:24] <kadams54> hatch: FYI, just finished incorporating all of your feedback into PR209
[19:25] <hatch> cool - I see I was outvoted with the api calls
[19:25] <kadams54> current is now getCurrent, parseRequest is loadRequest
[19:25]  * hatch crys
[19:25] <hatch> :P
[19:25] <hatch> I'll live with getCurrent
[19:25] <kadams54> It's a compromise, and you know what that means…
[19:25] <kadams54> Nobody is happy :-)
[19:26] <hatch> rofl!
[19:32] <kadams54> hatch: wondering if this is the Safari Selenium bug? http://ci.jujugui.org:8080/job/juju-gui/640/console
[19:32] <hatch> F(*@&#_)@)($)(*@$)&%*(#(#
[19:32] <hatch> yes
[19:32] <kadams54> Wait… it seems to be in Firefox
[19:33] <kadams54> JUJU_GUI_TEST_BROWSER="firefox" make test-browser-mocha
[19:33] <hatch> oh interesting
[19:33] <hatch> hmmmm
[19:33] <hatch> did rick_h_  get you a login for jenkins yet?
[19:34] <kadams54> no
[19:34] <hatch> looks like it's running again
[19:34] <hatch> odd...
[19:34] <hatch> guess we'll see
[19:34] <kadams54> Yeah, the second build started right up after the first… was also puzzled by that.
[19:34] <hatch> must have been queued up from a change
[19:34] <kadams54> Fingers crossed.
[19:35] <hatch> I wonder if we are using an old version of anything 
[19:35] <hatch> where an upgrade may fix this
[19:36] <hatch> yeah looks like we are running an older version of selenium
[19:36] <hatch> one version back mind you
[19:36] <hatch> but might be worth an upgrade
[19:40] <kadams54> Same error second time around. Grrr…
[19:41] <kadams54> hatch: you OK with me doing a :shipit: on the PR?
[19:41] <hatch> yup let'r rip
[19:43] <hatch> kadams54 looks like it's not passing
[19:44] <hatch> in firefox now
[19:44] <hatch> lemme take a look at the failure
[19:44] <hatch> lol
[19:45] <hatch> https://github.com/juju/juju-gui/blob/develop/test/browser.py#L205-L209
[19:45] <kadams54> *sigh*
[19:46] <kadams54> It doesn't look like the CI is picking up my :shipit: comment…
[19:47] <hatch> it did
[19:47] <hatch> "Status: merge request accepted...."
[19:47] <kadams54> Oh, yeah, n/m
[19:47] <kadams54> Just saw that show up
[19:48] <hatch> to debug ci we might need to run it from an ec2 instance or the like
[19:50] <hatch> I think this might be a selenium bug
[19:50] <hatch> er sauce labs & selenium
[19:52] <hatch> it might be caused by the api not returning properly
[19:57] <hatch> kadams54 `url = '%s%s' % (self._url, path)` is this just a string replace?
[19:57] <kadams54> Yeah
[19:57] <hatch> ok I see the problem....now why is it being caused...
[19:57] <kadams54> Equivalent of `url = self._url + path`
[19:58] <hatch> somehow that's returning None
[19:58] <hatch> so self._url and path would both need to be None?
[20:01] <hatch> RemoteConnection
[20:03] <hatch> ok I 'think' that the issue is that the api is not connecting
[20:03] <kadams54> Even if both of those were None, you'd still end up with a string…
[20:03] <kadams54> >>> foo = '%s%s' % (None, None)
[20:03] <kadams54> >>> foo
[20:03] <kadams54> 'NoneNone'
[20:03] <hatch> that's very odd then, no?
[20:03] <kadams54> Yes, very odd.
[20:04] <hatch> somehow the merge run is going off properly
[20:05] <hatch> this has to be a connection issue with the saucelabs api
[20:05] <hatch> stepping through the code that's what it looks like is going on...
[20:07] <hatch> I'm wondering if somehow it makes a connection then gets cut off
[20:07] <hatch> then when it tries to do the url bits there isn't anything there any longer
[20:11] <hatch> because the only difference between the merge project and the PR one is the port 
[20:13] <kadams54> I'm heading out for the weekend - if it's still an issue on Monday, I'll help dig into it
[20:13] <hatch> have a good weekend
[20:13] <hatch> cya
[20:14] <kadams54> You too
[21:05] <hatch> lazyPower creating an environment and then logging into it from multiple computers seems to be a real question people are asking....do you simply need to copy the environments.yaml from machine to machine?
[21:06] <lazyPower> You should copy the entire .juju directory from machine to machine, or use a jump host
[21:06] <hatch> if someone deletes this .juju/ would they be sol?
[21:07] <marcoceppi> hatch: pretty much
[21:08] <marcoceppi> unless you've backed up the environment
[21:08] <marcoceppi> hatch: there's a .jenv which has the keys required to do the SSL auth to the api server, etc
[21:08] <hatch> is this being addressed? Maybe by caching it in the bootstrap node?
[21:08] <marcoceppi> i mean, your environment will continue running
[21:08] <hatch> this is just me spitballing, I'll write up a blog post about it too just so there is something to point ppl to
[21:09] <hatch> right, but you can't juju with it :)
[21:09] <marcoceppi> you just won't be able to connect to it anymore
[21:10] <rick_h_> marcoceppi: "just won't be able to connect" to your production environment seems scary
[21:10] <rick_h_> I know I hit this in our azure env for CI. 
[21:10] <marcoceppi> same problem if you delete your .ssh directory
[21:10] <rick_h_> as I was blowing things away because of using the dev juju releases in trusty
[21:11] <marcoceppi> I mean, we can only safe guard people so far
[21:11] <rick_h_> except I write to that, not a magic service
[21:11] <rick_h_> right
[21:11] <marcoceppi> rick_h_: there's a backup command to backup your environment connect data
[21:11] <rick_h_> marcoceppi: oh ok, so maybe I need to cron up some form of backup using that as I sync my .ssh dir around my machines
[21:11] <hatch> marcoceppi oh really?
[21:11] <hatch> I didn't know about this command
[21:11] <rick_h_> it's a bit easier to sync ssh because you dno't have a local on each machine that's different/etc
[21:11] <marcoceppi> juju backup I believe
[21:12] <marcoceppi> it has no help stuff though
[21:12] <rick_h_> hatch: yea, good thing to look into and write up. I know it's something others have hit 
[21:12] <marcoceppi> there's a juju backup and juju restore
[21:12] <hatch> ahh yeah it's missing from the juju help commands list
[21:12] <rick_h_> hatch: how did the 'load the data' go today?
[21:12] <marcoceppi> hatch: it's a plugin
[21:12] <marcoceppi> juju help plugins
[21:13] <marcoceppi> but it doesn't have an -h flag, at least not on the version juju I'm running
[21:13] <hatch> rick_h_ I know what won't work :) we are going to have to simulate a 'delta' 
[21:13] <hatch> so a little more work but should work just like you're interacting with a real env....I hope
[21:14] <rick_h_> hatch: ok interesting
[21:14] <rick_h_> hatch: also see CI got angry but looks like it's satisfied now
[21:15] <hatch> rick_h_ open a develop instance and then paste this in the console https://gist.github.com/0cea96d605a2b8cbb2c7 and run preload()
[21:15] <hatch> you can open the inspector but nothing works....
[21:15] <hatch> even moving the service blocks doesn't keep the relation lines tracking
[21:15] <rick_h_> lol
[21:15] <rick_h_> yea, not enough metadata bound material
[21:15] <rick_h_> databound/etc
[21:16] <rick_h_> ok, well an initial delta seems quite sane, even what happens when we load from a real env
[21:16] <hatch> rick_h_ yeah I spent some time tracking down the CI issue - I'm pretty confident it's a connection issue between sauce and our ci
[21:16] <rick_h_> so look forward to seeing a way to trick that into the websocket client stuff
[21:16] <rick_h_> hatch: yea, it's what I think as well. Just something in the tubes and depending on where the tests are at the time you get different issues
[21:17] <hatch> yeah I'm a little concerned about the sandbox env having to parse deltas.....we'll see
[21:17] <rick_h_> hatch: but it's not in canonistack/proxied and such so not sure how to make it better for sauce
[21:17] <hatch> rick_h_ yeah - there are very odd python issues.....somehow url is a NoneType when it should be a String
[21:17] <hatch> I THINK the azure networking isn't so good
[21:17] <hatch> or maybe it's just the machines we are on
[21:17] <rick_h_> hatch: hmm, I guess we could try to bring it up on ec2 for a few weeks and compare. 
[21:17] <hatch> it might be another symptom of the http request issue....just so slow it hangs up....maybe?
[21:18] <rick_h_> takes a little bit to get it resetup and to get this size of machine on ec2 would be more $$
[21:18] <hatch> marcoceppi thanks for the information 
[21:18] <rick_h_> hatch: k, well I think a test is worthwhile so will try to see if we can find time to tinker with that. At least narrow it to our tests or the platform
[21:18] <hatch> yeah - what about DigiOcean? 
[21:19] <hatch> should be pretty cheap
[21:19] <rick_h_> well, this thing needs several GB of ram to run <3 java
[21:19] <hatch> ohh
[21:19] <rick_h_> and we're using two machines
[21:19] <hatch> damn java
[21:19] <rick_h_> but I can run a 4 or 8gb ec2 box for a couple of weeks
[21:19] <rick_h_> and compare
[21:20] <hatch> would be cool if we could use a single box and run all these services with juju :)
[21:20] <rick_h_> and my setup scripts will be about the same since they're both juju providers
[21:20] <rick_h_> right, it would be cool to make the lander a subordinate and get a 'juju action' for a jenkins backup/restore
[21:20] <hatch> how could of a story would this be? Azure wasn't working so we pointed our env to ec2 and it 'just-worked' :)
[21:21] <rick_h_> it's the story we're working towards for sure
[21:21] <hatch> s/could/good
[21:23] <hatch> jcsackett let me know if you want to work on the ghost charm - a partner might be what I need to get me moving on it :) I also want to start using it so.... :)
[21:24] <rick_h_> hatch: take a peek at https://github.com/jdorn/juju-gui/compare/develop...json-editor-service-config if you get some time
[21:24] <rick_h_> hatch: it might be something I'll ask you to peek at and talk with jeremy about some in the coming weeks
[21:24] <jcsackett> hatch: i'm totally game to work on it again. i can't believe it's been since like october since i last touched it.
[21:26] <hatch> rick_h_ ok no problem - I have a problem with generating forms outside of a templating system but maybe I can be convinced :)
[21:26] <rick_h_> hatch: well, it can be tweaked :)
[21:26] <rick_h_> hatch: and besides, what do we do now? 
[21:26] <hatch> jcsackett hah yeah I did some work fairly recently on it to start getting it closer to being ready but that darn http interface has just been glaring at me
[21:27] <hatch> rick_h_ PE - we render the markup with the template then use delegation on the fields
[21:27] <rick_h_> hatch: gotcha
[21:27] <jcsackett> hatch: setting up http-relation isn't terrible hard, iirc.
[21:27] <rick_h_> hatch: yea, the implementation needs some tweaking to fit our code but I love the general idea of sticking to a better schema. 
[21:27] <jcsackett> hatch: if i get some time this weekend, might be able to put something together.
[21:27] <rick_h_> hatch: so we might have to hold a couple of talks on databinding needs, rendering needs, etc
[21:28] <hatch> jcsackett no but I end up in analysis paralyses because I'm trying to build it so it can do load balancing and everything lol
[21:28] <hatch> jcsackett that would be very cool
[21:28] <rick_h_> hatch: baby steps man :)
[21:28] <jcsackett> hatch: oh, yeah. don't do that. just make it work first. :p
[21:28] <rick_h_> hatch: linux wasn't built in a day
[21:28] <hatch> rick_h_ tbh I see value in a react like system for this stuff
[21:28] <rick_h_> hatch: what's react got to do with it?
[21:28] <rick_h_> hatch: as far as a schema/validation/etc?
[21:28] <hatch> the databinding
[21:29] <hatch> validation could be done using a similar technique to what we are doing now 
[21:29] <hatch> I don't see why the validation rules can't be put in the YAML as well
[21:29] <rick_h_> I guess I still need to look at the *how* for that. I mean nothing prevents us from shadow dom'ing things etc. 
[21:29] <rick_h_> hatch: they will in a sense
[21:29] <rick_h_> the Schema will support field that define valid
[21:30] <rick_h_> so by working to the schema we'll have things in the yaml to provide validation rules
[21:30] <rick_h_> that will have to be tied to the databinding
[21:30] <rick_h_> hatch: anywa, just a general fyi. 
[21:30] <hatch> yeah there is lots to chat about
[21:30]  * rick_h_ has melted brain and is going to run back away
[21:30] <hatch> haha
[21:31] <hatch> jcsackett I've been hoping someone would write a nginx charm which we could use for http
[21:32] <hatch> that has not happened yet unfortunately
[21:34] <hatch> jcsackett there is also things like 'how do we theme a juju deployed ghost blog', 'how do we backup', etc etc
[21:40] <jcsackett> hatch: yeah, charming up nginx is beyond me. but that would be nice.
[21:40] <jcsackett> and the themeing and stuff is definitely an open question, esp now that they have actual themes.
[21:41] <hatch> yeah....
[21:41] <hatch> so my plan is to create a bundle which deploys apache, mysql, ghost all to a boostrap node
[21:41] <hatch> and a bundle which makes them all separate
[21:42] <hatch> should be a good first step for a 'public' release
[21:44] <hatch> I also have to migrate my blog posts and urls from tumblr to ghost so that's another thing I have to keep in mind
[21:44] <hatch> so I think I 'need' apache for that
[21:44] <hatch> or nginx of course
[21:44] <hatch> but yeah....no nginx charm
[21:51] <hatch__> rick_h_ oops, thanks for finding that other bug
[23:18] <hatch> moom is working pretty cool
[23:18] <hatch> have some layouts defined