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