[00:01] <hatch> huwshimi: hey I'm bacl
[00:02] <hatch> huwshimi: well we can provide version numbers with 0-3 periods so it needs to be able to parse it appropriately 
[00:02] <hatch> and any number of digits inbetween
[00:02] <hatch> and an 'extension' at the end
[00:05] <hatch> huwshimi: so I'd parseFloat(version.split('.').slice(0,1).join('.')) > 1.21 
[00:05] <hatch> I think (going from memory) :)
[00:07] <huwshimi> Yep, that makes sense
[00:07] <huwshimi> I wasn't thinking that the major version can be double digits
[00:08] <huwshimi> I think my version would still work as it checks for < but this is probably a more correct way :)
[00:16] <hatch> huwshimi: yeah it probably would work :) 
[00:27] <huwshimi> hatch: New version up
[00:30] <huwshimi> erm, let me just fix the merge conflict
[00:30] <huwshimi> I knew it was coming
[00:32] <huwshimi> OK pushed
[01:44] <hatch> huwshimi: thanks I'll try and get to the review tonight
[01:44] <huwshimi> hatch: Thanks a lot
[01:45] <hatch> huwshimi: ok took a real quick look - could you add some tests for the _shouldLockAdmin method
[01:45] <hatch> basically throw in a ton of different valid semver versions
[01:46] <hatch> and make sure it returns the correct value
[01:46] <hatch> you can probably just do one test with a map of version: boolean records that it loops through
[01:48] <huwshimi> hatch: Sure
[01:49] <hatch> ok stepping away again :)
[01:49] <huwshimi> hatch: What do you want test really?
[01:49] <huwshimi> (Other than what I've tested already?)
[01:52] <huwshimi> Just full semver numbers?
[02:17] <hatch> huwshimi: well right now you're only testing the format that we currently have
[02:17] <hatch> nothing there is testing 3 sections, or with an extension
[02:17] <hatch> or double digit starting characters etc
[02:18] <huwshimi> hatch: Sure, any other variations?
[02:19] <hatch> just looking for semver examples
[02:19] <hatch> 1.0.0-beta.2
[02:19] <hatch> that's a funky one
[02:20] <hatch> lol wut 1.0.0-beta.2
[02:20] <hatch> er
[02:20] <hatch> damn 
[02:20] <hatch> 1.0.0-x.7.z.92
[02:20] <hatch> that would irritate me if someone actually made a GUI version like that
[02:20] <hatch> lol
[02:22] <huwshimi> :)
[02:23] <hatch> anyways the idea is that we don't want something like the login button to fail because someone put in a 3 section semver 
[02:48] <huwshimi> hatch: Does that look roughly like what you were thinking?
[02:49]  * hatch does his best Italian
[02:49] <hatch> magnifico
[02:49] <hatch> *moah*
[02:49] <hatch> that's a spicy meata balla
[02:51] <hatch> probably wouldn't hurt to put the jujuCoreVersion in a var in the function to help with minification....buuut now I'm just getting picky :P
[02:52] <hatch> feel free to shippit when it passes
[02:52]  * hatch steps away again
[02:56] <huwshimi> hatch: jujuCoreVersion in which function sorry?
[03:23] <hatch> huwshimi: this is a really long name and repeated twice
[03:23] <hatch> window.juju_config.jujuCoreVersion
[03:24] <hatch> but whatever
[03:24] <huwshimi> hatch: Sure, but if it is stored before this line 'window.juju_config && window.juju_config.jujuCoreVersion' and it doesn't exist it will give an error
[03:25] <huwshimi> (that's what that line is for
[03:25] <huwshimi> )
[03:25] <hatch> right, duh
[03:25] <hatch> sorry I got no sleep last night :) 
[03:25] <hatch> about to hit the hay soon
[03:25] <hatch> 9:30pm man I'm old
[03:25] <hatch> lol
[03:25] <huwshimi> haha
[03:25] <huwshimi> So it's OK to leave as it is?
[03:25] <hatch> yup
[03:28] <huwshimi> hatch: Thanks a lot, have a nice evening!
[03:28] <hatch> anytime, you too! 
[14:12] <hatch> hows everyones morning?
[14:38] <hatch> destiny expansion is released today
[14:38]  * hatch feels a cold coming on
[14:39] <hatch> ...
[14:39] <hatch> :P
[14:39] <hatch> jk
[15:00] <hatch> uhh wut "Ubuntu Developer Tools Center Renamed To Ubuntu Make"
[15:03] <hatch> cuz that's not going to be confusing at all
[15:11] <hatch> *sigh* 
[15:15] <teslanick> ~ $ ubuntu make
[15:18] <hatch> make install android-editor
[15:18] <hatch> wait
[15:18] <hatch> that's not right
[15:18] <hatch> :P
[16:39] <whit> jujucharms is returning 503s
[16:40]  * whit assumes this is known, but if not...
[16:40] <rick_h_> whit: yes, in webops working on it as we speak
[16:40] <rick_h_> ES bit the farm on us
[16:41] <whit> deleted all if it's own data?
[16:41]  * whit has heard of a couple big ES crashes lately
[16:41] <rick_h_> elasticsearch just went red and the logs are confusing java tracebacks that are truncated
[16:41] <whit> ugh
[16:42] <rick_h_> so working on a fix and restoration atm
[17:28] <hatch> rick_h_: did we have an eta on when the deployer will be able to support the new id syntax? I'm trying to decide what I should use as the instructions for the deployer url in the 'Deploy' tab
[17:28] <hatch> since we can only generate valid ones part of the time :)
[17:29] <hatch> I'd prefer to put the new id and we just 'hurry' to get the deployer to support the new syntax 
[17:29] <hazmat> hatch, doc on new 'id' syntax.. i assume you mean bundle store url by that
[17:29] <hazmat> ?
[17:30] <hatch> hazmat: https://demo.jujucharms.com/bundle/mongodb/5/cluster/#deploy step 2 on this page
[17:30] <rick_h_> hatch: not atm, working on production failure still
[17:30] <rick_h_> hazmat: bundle ids without the basket since that's gone in the new charmstore api
[17:30] <hatch> I'll leave it blank for now - want to keep moving forward on this
[17:30] <hatch> this stuff is one step forward, 2 back :/
[17:31] <hatch> fiddly data bits ;?
[17:31] <hazmat> huh.. is that even valid
[17:31] <hatch> no
[17:31] <hatch> well, yes, but not anymore
[17:31] <hazmat> deployer doesn't need a basket name anyways..
[17:32] <hatch> the one in the GUI charm can handle the new bundle id format? Are you sure?
[17:32] <hazmat> hatch, you just hand deployer a url to json or yaml.. 
[17:33] <hatch> and it no longer needs the basket?
[17:33] <hatch> or the name, or whatever we were calling that outer wrapper
[17:33] <hazmat> hatch, it never did.. that's a hack done speculative reasons re baskets
[17:33] <rick_h_> hatch: just pass it the url to the new api's bundles.yaml.orig I think
[17:33] <hazmat> rick_h_, what is the new api.jujucharms.com url for a bundle?
[17:33] <rick_h_> hatch: it'll look worse since it's not hte shorter url/name but should work
[17:33] <hatch> ok now you 2 are saying two different things
[17:34] <hatch> one says you need the orig yaml, the other not
[17:34] <rick_h_> hazmat: https://api.staging.jujucharms.com/v4/mongodb-cluster/meta/any is the new id
[17:34] <rick_h_> https://api.staging.jujucharms.com/v4/mongodb-cluster/archive/bundles.yaml.orig is the original bundle yaml
[17:34] <rick_h_> https://api.staging.jujucharms.com/v4/mongodb-cluster/archive/bundle.yaml is the new bundle format
[17:35] <hazmat> rick_h_, at least for that charm the new format is valid directly to pass in
[17:35] <hazmat> er. bundle
[17:35] <rick_h_> hazmat: ok, if that works even better and we don't have to do the original .orig file
[17:35] <hatch> I know quickstart doesn't support the new id syntax
[17:35] <rick_h_> hatch: so you can use that url for that
[17:35] <rick_h_> hatch: if you give it a url it won't matter
[17:35] <hatch> ok so the deployer DOES support the new yaml format?
[17:36] <rick_h_> hatch: it only matters that quickstart is updated to know cs:mongodb-cluster
[17:36] <hazmat> hmm
[17:36] <hazmat> hatch, hmm
[17:36] <rick_h_> hatch: not all of it, like the container syntax
[17:36] <hazmat> rick_h_, hatch actually it should probably be .orig
[17:36] <hatch> lol
[17:36] <rick_h_> hazmat: yes, that should be 100% safe atm
[17:36] <hazmat> rick_h_, hatch i think i'd need a patch for the flat namespace
[17:36] <hatch> ok that's what I thought
[17:37] <hazmat> i think deployer does expect at one top level name key in there
[17:37] <hatch> ok using the .orig for quickstart and deployer docs
[17:37] <rick_h_> hazmat: right, we've got on the plate patches for that and the container format
[17:37] <hazmat> rick_h_, which new container syntax?
[17:37] <rick_h_> hazmat: from that bundle format spec from a while ago. /me looks for file
[17:37] <hazmat> rick_h_, the only i remember from that was machines: and a few other incompatible changes i argued against
[17:37] <hazmat> like dropping vcs support
[17:38] <hazmat> which don't matter to the store i suppose
[17:39] <rick_h_> hazmat: https://docs.google.com/a/canonical.com/document/d/1SF8hTBi6oVbki8V__beNij6wnQU-5cm6PZsy5gf0j_Y/edit is the doc MachineSpec I think was the change? allowing them in allowing lxc:0 and such
[17:39] <hatch> ok so I'm going to put the .orig url for quickstart and the deployer and then we can go back and update it later on whenever we get around to updating them
[17:40] <hazmat> rick_h_, lxc:0 is already extant.. kvm:new is something new.
[17:40] <rick_h_> https://github.com/juju/charm/blob/v4/bundledata.go
[17:40] <rick_h_> I think is the real struct
[17:40] <hazmat> rick_h_, that seems a little suspect given its also deviating from core syntax re new
[17:41] <hazmat> seems reasonable though
[17:41] <hazmat> hmm.. its a little strange though.. cause its almost like its being treated as a constraint
[17:42] <hazmat> our placement language is in need of some better model definition language.. or rules
[17:42] <hazmat> rick_h_, of concern is that syntax doesn't seem to support the extant syntaxes for co-location which is heavily used
[17:42] <rick_h_> hazmat: ok, we should update then to do that while we're doing this then. 
[18:19] <Makyo> uiteam small review/QA for fakebackend multiple users: https://github.com/juju/juju-gui/pull/675
[18:21] <rick_h_> kadams54-away: around? missed you on standup
[18:21] <rick_h_> or did you make it?
[18:35] <hatch> lunching
[19:19] <kadams54_> rick_h_: I made standup, but was hampered (delayed, then booted out after initially joining) by kanban board freezing my lappy twice.
[19:20] <kadams54_> In the end, I was still able to give updates on the switchboard cards.
[19:21] <kadams54_> Though that reminds me that I need to move those cards… after two crashes I decided to wait a bit ;-)
[19:22] <rick_h_> kadams54_: rgr ok cool
[19:22] <rick_h_> kadams54_: is there a review for the memcache'd card? no external link listed atm
[19:22] <kadams54_> The upshot is that switchboard 1.2 is released, which removes memcached dependency, so I'm now working on getting it integrated.
[19:23] <rick_h_> oh awesome 
[19:23] <kadams54_> Link added.
[19:29] <hatch> this is the weirdest error
[19:29] <hatch> trying to create a charm model
[19:29] <hatch> Uncaught TypeError: Cannot use 'in' operator to search for 'bubbleTargets' in cs:precise/mongodb-28
[19:29] <hatch> like-uh-who-what-now?
[19:30] <rick_h_> lol
[19:30] <hatch> it's been resolved...but still a very odd error
[19:34] <kadams54_> Nice. A++ for user friendly error messages.
[19:36] <jrwren> looks like a python error.
[19:39] <hatch> ok bundle vis and getting files to go on the bundle details page
[19:39] <hatch> holy moly this is slow going
[19:40] <rick_h_> hatch: huh?
[19:41] <hatch> the bundle details page I have to get it to load files and the bundle vis then it'll be done
[19:42] <rick_h_> hatch: ok, well let me know if any of it gives you grief
[19:42] <hatch> oh it most certainly will :P
[19:43] <rick_h_> :P
[19:59] <hatch> hmm getting it to pull files was a lot easier than I thought it was going to be :)
[19:59] <hatch> maybe the pain is over
[19:59] <hatch> hah!
[20:05] <hatch> errors in promises
[20:05]  * hatch throws chair through wall and goes home
[20:05]  * hatch looks around
[20:05] <hatch> damnit
[20:05] <hatch> :P
[20:09] <rick_h_> hah
[21:30]  * hatch wonders if he can get Ben back to do this importDeployer stuff again
[21:32] <hatch> oh github changed the colouring of the diffs
[21:48] <hatch> woo hooo victory!
[21:49] <rick_h_> hatch: woot
[21:50] <hatch> now a few small bits of incorrectly alligned data then it's ready for test
[21:50] <hatch> holy smoke is it fast lol
[21:50] <hatch> it actually loads the data before the animation slides out
[21:50] <hatch> :)
[21:51] <rick_h_> :)
[21:53] <hatch> bundle vis takes a bit though so it feels slower
[21:54] <hatch> but the actual data is loaded and rendered before it's done animating
[21:54] <rick_h_> wfm
[21:54] <hatch> yep that can go in slack
[21:54] <hatch> where tasks go to die
[21:55] <rick_h_> well we'll see
[21:59] <hatch> haha, whenever
[22:00] <hatch> Showing  11 changed files  with 179 additions and 176 deletions.
[22:00] <hatch> I need to find 3 more lines to delelte
[22:00] <hatch> delete event
[22:00] <hatch> DELETE EVEN
[22:00] <rick_h_> lol, good enough
[22:00] <hatch> haha I have tests to fix/write now so who knows where it'll end up after that
[22:01] <hatch> honestly the new colouring on github diffs for js makes it pretty difficult to read
[22:01] <hatch> orange, purple, light purple, on a pink background
[22:03] <hatch> it's....so.....beautiful
[22:03] <huwshimi> Morning
[22:03] <hatch> I wasn't talking about you
[22:03] <hatch> don't worry
[22:03] <hatch> :P
[22:03] <hatch> morning huwshimi 
[23:16] <huwshimi> Hey is anyone around that could help with a bit of hacking on the juju charm?
[23:16] <huwshimi> juju-gui charm that is
[23:18] <Makyo> huwshimi, I can try, what's up?
[23:19] <huwshimi> Makyo: I'm just trying to figure out how the 'write_gui_config' method can actually interact with juju
[23:20] <huwshimi> Makyo: I need to get the output of the equivalent of $juju --version
[23:20] <huwshimi> Makyo: I just don't know how to do that from inside the charm :)
[23:20] <huwshimi> Makyo: From in here http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L347
[23:21] <Makyo> huwshimi, ah, yeah.  Let me spin up an env real quick. Wondering if it's available in an env var like JUJU_ENV_NAME.  Will have to check by running debug-hooks
[23:22] <huwshimi> Makyo: Ah yeah, possibly
[23:22] <Makyo> There might also be juju agent information somewhere...
[23:22] <Makyo> Hunting now
[23:23] <huwshimi> Makyo: Where would you look for that kind of info?
[23:23] <huwshimi> Makyo: Sorry I have no idea about this kind of stuff :)
[23:30] <Makyo> huwshimi, I'm hunting through the docs now (without much luck).  Also, did `juju bootstrap; juju deploy cs:trusty/juju-gui` then `juju debug-log juju-gui/0 config-changed` when that unit was up.  Triggering a config-changed event with `juju set juju-gui juju-gui-debug=true`.  Waiting for that to go through.  When it does, it'll drop me in exactly the same environment the config-changed hook is run in, and I can check `env` and see what juju commands are avai
[23:30] <Makyo> lable
[23:34] <Makyo> huwshimi, it doesn't look like there's an env var for version, unfortunately.  However, units have `jujud` installed, and running `jujud --version` gives me "1.21-beta3-trusty-amd64"
[23:35] <Makyo> huwshimi, so running jujud --version from the write_gui_config function should get us the version string for the unit
[23:42] <huwshimi> Makyo: With run()?
[23:42] <Makyo> huwshimi, I thiiink so?  I don't remember if we have a wrapper in the charm like we do in Quickstart
[23:43] <Makyo> I'll keep digging.
[23:44] <Makyo> huwshimi, oh, that is the wrapper. 
[23:45] <Makyo> huwshimi, so yeah, juju_version = run('jujud', '--version') or something like that.
[23:48] <huwshimi> Makyo: How do I test this?
[23:52] <Makyo> huwshimi, Good question :P  
[23:53] <rick_h_> huwshimi: frankban is back tomorrow and he's the charm testing master. 
[23:54] <rick_h_> huwshimi: but one way is to just do it, spin up the charm, then check the file (config.js or whatever) has the right thing in it. 
[23:54] <rick_h_> probably as a funtional test
[23:55] <Makyo> huwshimi, rick_h_ there's also config-writing examples around here: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/tests/test_utils.py#L954
[23:56] <Makyo> Er, tests for those, I mean
[23:57] <Makyo> But yeah, if nothing else, get a WIP branch up for frankban to look at
[23:58] <huwshimi> Makyo: Yeah, so in those they do: with mock.patch('os.environ', {'JUJU_ENV_NAME': 'my-env'}):
[23:58] <huwshimi> Makyo: could we do patch('jujud...'?
[23:59] <Makyo> huwshimi, it would be patch('run') and then checking the arguments, but that's about the limits of my off-the-top-of-my-head knowledge of mock
[23:59] <Makyo> Mock is impressive, but I don't really understand it yet
[23:59] <huwshimi> Makyo: Ah ok