| hatch | huwshimi: hey I'm bacl | 00:01 |
|---|---|---|
| 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:02 |
| hatch | huwshimi: so I'd parseFloat(version.split('.').slice(0,1).join('.')) > 1.21 | 00:05 |
| hatch | I think (going from memory) :) | 00:05 |
| huwshimi | Yep, that makes sense | 00:07 |
| huwshimi | I wasn't thinking that the major version can be double digits | 00:07 |
| huwshimi | I think my version would still work as it checks for < but this is probably a more correct way :) | 00:08 |
| hatch | huwshimi: yeah it probably would work :) | 00:16 |
| huwshimi | hatch: New version up | 00:27 |
| huwshimi | erm, let me just fix the merge conflict | 00:30 |
| huwshimi | I knew it was coming | 00:30 |
| huwshimi | OK pushed | 00:32 |
| hatch | huwshimi: thanks I'll try and get to the review tonight | 01:44 |
| huwshimi | hatch: Thanks a lot | 01:44 |
| 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:45 |
| 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:46 |
| huwshimi | hatch: Sure | 01:48 |
| 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:49 |
| huwshimi | Just full semver numbers? | 01:52 |
| 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:17 |
| huwshimi | hatch: Sure, any other variations? | 02:18 |
| hatch | just looking for semver examples | 02:19 |
| hatch | 1.0.0-beta.2 | 02:19 |
| hatch | that's a funky one | 02:19 |
| 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:20 |
| huwshimi | :) | 02:22 |
| 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:23 |
| huwshimi | hatch: Does that look roughly like what you were thinking? | 02:48 |
| * hatch does his best Italian | 02:49 | |
| hatch | magnifico | 02:49 |
| hatch | *moah* | 02:49 |
| hatch | that's a spicy meata balla | 02:49 |
| 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:51 |
| hatch | feel free to shippit when it passes | 02:52 |
| * hatch steps away again | 02:52 | |
| huwshimi | hatch: jujuCoreVersion in which function sorry? | 02:56 |
| === kadams54-away is now known as kadams54 | ||
| hatch | huwshimi: this is a really long name and repeated twice | 03:23 |
| hatch | window.juju_config.jujuCoreVersion | 03:23 |
| 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:24 |
| 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:25 |
| huwshimi | hatch: Thanks a lot, have a nice evening! | 03:28 |
| hatch | anytime, you too! | 03:28 |
| === urulama_ is now known as urulama | ||
| hatch | hows everyones morning? | 14:12 |
| hatch | destiny expansion is released today | 14:38 |
| * hatch feels a cold coming on | 14:38 | |
| hatch | ... | 14:39 |
| hatch | :P | 14:39 |
| hatch | jk | 14:39 |
| === alexpilotti_ is now known as alexpilotti | ||
| hatch | uhh wut "Ubuntu Developer Tools Center Renamed To Ubuntu Make" | 15:00 |
| hatch | cuz that's not going to be confusing at all | 15:03 |
| hatch | *sigh* | 15:11 |
| teslanick | ~ $ ubuntu make | 15:15 |
| hatch | make install android-editor | 15:18 |
| hatch | wait | 15:18 |
| hatch | that's not right | 15:18 |
| hatch | :P | 15:18 |
| === teslanick1 is now known as teslanick | ||
| whit | jujucharms is returning 503s | 16:39 |
| * 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:40 |
| 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:41 |
| rick_h_ | so working on a fix and restoration atm | 16:42 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| hazmat | which don't matter to the store i suppose | 17:38 |
| 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:39 |
| 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:40 |
| hazmat | seems reasonable though | 17:41 |
| hazmat | hmm.. its a little strange though.. cause its almost like its being treated as a constraint | 17:41 |
| 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. | 17:42 |
| === kadams54_ is now known as kadams54-away | ||
| Makyo | uiteam small review/QA for fakebackend multiple users: https://github.com/juju/juju-gui/pull/675 | 18:19 |
| rick_h_ | kadams54-away: around? missed you on standup | 18:21 |
| rick_h_ | or did you make it? | 18:21 |
| hatch | lunching | 18:35 |
| === kadams54-away is now known as kadams54_ | ||
| kadams54_ | rick_h_: I made standup, but was hampered (delayed, then booted out after initially joining) by kanban board freezing my lappy twice. | 19:19 |
| kadams54_ | In the end, I was still able to give updates on the switchboard cards. | 19:20 |
| kadams54_ | Though that reminds me that I need to move those cards… after two crashes I decided to wait a bit ;-) | 19:21 |
| 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:22 |
| rick_h_ | oh awesome | 19:23 |
| kadams54_ | Link added. | 19:23 |
| 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:29 |
| rick_h_ | lol | 19:30 |
| hatch | it's been resolved...but still a very odd error | 19:30 |
| kadams54_ | Nice. A++ for user friendly error messages. | 19:34 |
| jrwren | looks like a python error. | 19:36 |
| hatch | ok bundle vis and getting files to go on the bundle details page | 19:39 |
| hatch | holy moly this is slow going | 19:39 |
| rick_h_ | hatch: huh? | 19:40 |
| hatch | the bundle details page I have to get it to load files and the bundle vis then it'll be done | 19:41 |
| 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:42 |
| rick_h_ | :P | 19:43 |
| 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! | 19:59 |
| hatch | errors in promises | 20:05 |
| === kadams54_ is now known as kadams54-away | ||
| * hatch throws chair through wall and goes home | 20:05 | |
| * hatch looks around | 20:05 | |
| hatch | damnit | 20:05 |
| hatch | :P | 20:05 |
| === kadams54-away is now known as kadams54_ | ||
| rick_h_ | hah | 20:09 |
| === 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 | ||
| * hatch wonders if he can get Ben back to do this importDeployer stuff again | 21:30 | |
| hatch | oh github changed the colouring of the diffs | 21:32 |
| hatch | woo hooo victory! | 21:48 |
| rick_h_ | hatch: woot | 21:49 |
| 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:50 |
| rick_h_ | :) | 21:51 |
| hatch | bundle vis takes a bit though so it feels slower | 21:53 |
| 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:54 |
| rick_h_ | well we'll see | 21:55 |
| hatch | haha, whenever | 21:59 |
| 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:00 |
| 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:01 |
| 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 | 22:03 |
| 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:16 |
| Makyo | huwshimi, I can try, what's up? | 23:18 |
| huwshimi | Makyo: I'm just trying to figure out how the 'write_gui_config' method can actually interact with juju | 23:19 |
| 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:20 |
| 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:21 |
| huwshimi | Makyo: Ah yeah, possibly | 23:22 |
| Makyo | There might also be juju agent information somewhere... | 23:22 |
| Makyo | Hunting now | 23:22 |
| 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:23 |
| 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:30 |
| 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:34 |
| Makyo | huwshimi, so running jujud --version from the write_gui_config function should get us the version string for the unit | 23:35 |
| 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:42 |
| Makyo | I'll keep digging. | 23:43 |
| Makyo | huwshimi, oh, that is the wrapper. | 23:44 |
| Makyo | huwshimi, so yeah, juju_version = run('jujud', '--version') or something like that. | 23:45 |
| huwshimi | Makyo: How do I test this? | 23:48 |
| Makyo | huwshimi, Good question :P | 23:52 |
| rick_h_ | huwshimi: frankban is back tomorrow and he's the charm testing master. | 23:53 |
| 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:54 |
| 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:55 |
| Makyo | Er, tests for those, I mean | 23:56 |
| Makyo | But yeah, if nothing else, get a WIP branch up for frankban to look at | 23:57 |
| 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:58 |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!