[00:04] morning huwshimi [00:05] rick_h_: Hey! [00:06] have a good weekend huwshimi ? [00:07] rick_h_: Yeah it was good, the weather is picking up now [00:07] rick_h_: How was your single dad weekend? :) [00:07] nice, we've got fall in full swing here [00:15] rick_h_: Is it getting cold yet? [00:18] yea, down into the 50s (10C) and heading down. Will be interesting. Normally this chilly around Halloween but a little bit to go still [00:20] ouch === uru_ is now known as urulama [06:37] morning === fabrice is now known as fabrice|lunch [11:11] morning wheeee [11:11] gah the email, the email! === fabrice|lunch is now known as fabrice [12:06] frankban: partying in the new place? [12:06] rick_h_: no, not yet, still no internet connection there :-/ [12:07] rick_h_: hope they will be able to fix stuff this week [12:08] frankban: ouch /me crosses fingers for you [12:08] rick_h_: thanks [12:52] morning, jujugui--can i get some reviews on https://github.com/juju/juju-gui/pull/570 ? [12:53] jcsackett: sure [12:53] thanks, kadams54. [12:57] kadams54: note, there are two lint errors, i've got a fix in place but won't push while you're reviewing. [12:57] rick_h_: am i still part of "all hands on" for MV release, or should i move back to the other thing? losing track of where my focus should be. :p [12:58] jcsackett: looking [12:58] jcsackett: if you want to start removing the FF while kadams54 picks up the card on the boolean fields in the inspector that'd be great [12:59] rick_h_: i would be delighted to start killing the feature flag. the other cards on the board don't block that? [13:00] jcsackett: no, basically we're going into it being available with the couple of bugs [13:00] rick_h_: dig. [13:00] jcsackett: there might be some small conflicts to resolve, but hopefully small [13:00] jcsackett: and we know we're releasing so worst case trunk has issues for 2 days [13:00] * jcsackett nods [13:01] awesome. [13:02] jcsackett: QA and review is finished. You're all clear to ship! [13:02] kadams54: awesome, thanks. :) [13:55] guihelp: I have a comparison. The type on one side can be a string, boolean, or int. The type on the other is always a string. What's the safest way to coerce the first side into a string? Concat an empty string? Call 'toString()'? If statement based on value returned by typeof? [13:56] kadams54: I am not sure about the meaning of comparing a bool to a string [13:56] false == 'false' [13:56] Which is false [13:56] What I want is: 'false' == 'false' [13:56] Which will yield true [13:57] kadams54: for int vs string, one way is to zero fill the int while converting it to a string (and in this case "+ ''" does the job) [13:57] there is also String() [13:58] Yeah, there are a slew of ways I *could* do it, I'm just wondering which is the safest :-) [14:01] what r u trying to do? [14:06] kadams54: +'' is safe if it's number boolean or string [14:07] I prefer String() it's more explicit [14:07] when glacing through [14:07] I agree [14:07] buut I don't know what it's being used for yet :) [14:16] hatch: take a look at https://github.com/juju/juju-gui/pull/571 [14:18] kadams54: uhh why don't you do if (typeof config[key] === 'boolean') { ... } [14:19] hatch: you came in just after my initial question: "I have a comparison. The type on one side can be a string, boolean, or int. The type on the other is always a string. What's the safest way to coerce the first side into a string? Concat an empty string? Call 'toString()'? If statement based on value returned by typeof?" [14:21] ok well yes then using String() is my preferred method [14:21] but I think in this case you should be checking the type and doing a proper comparison [14:22] And comparing one string to another isn't a proper comparison? [14:23] kadams54: all methods would be safe for number Boolean or String , the issue comes with functions or other objects. String() is kind of explicit [14:26] kadams54: it is, but why not test for a boolean then do the proper comparison for the data type [14:27] Because it achieves the same result with more lines of code? [14:27] well technically it's different [14:28] but yes the end result is the same [14:28] I'd still prefer sticking with the proper type [14:28] maybe that's my typed lang experience coming back [14:28] hah [14:28] Here's what sways me… [14:29] type cooersion is slow, string comparisons are slow [14:29] The reference spec we're comparing against is a string and is always a string. [14:29] So that makes me want to convert everything to the same data type being used in the ref. [14:30] That is, the proper "type" here is actually String. [14:30] really? juju sends us boolean values as strings? [14:31] We're comparing two Objects of config values to determine which config settings have changed. One, the new values, stores booleans as booleans. The other, the old values, stores them as strings. [14:32] I'm not sure where the old values are coming from… someplace else in the GUI? Juju? But they're stored as strings and that's what we're comparing against. [14:32] hmm something seems broken there [14:32] So I'm inclined to convert the new values to String as well. [14:32] I'm pretty sure when we parse the data from juju true === true [14:34] kadams54: I'd look into why there is a type discrepency [14:34] *caugh* this wouldn't happen with Dart *caugh* [14:34] ;) [14:51] jujugui call in 10 please kanban [14:54] oh I love it when old tests fail but it works in the real app === fabrice is now known as fabrice|kanban [14:59] jujugui otp atm might be a minute or two late [15:13] boom, 12min call with 14 people [15:13] we rule! :P [15:14] and the internet claims standups are broken [15:14] clearly they aren't doing it properly === fabrice|kanban is now known as fabrice [15:15] lol [15:15] jcsackett: first step to removing the flag is to set it as the default and then start removing the conditionals [15:15] hatch: you still on for the blog post for MV? I've got a marketing meeting with sally tomorrow and want to make sure we'll still have 3 posts [15:16] hatch: what do you meant "set it as the default"? is that separate from just ensuring we always go down the MV path on a conditional (e.g. sanely remove it) [15:17] rick_h_: yup I haven't started on it yet but I'll have it ready to go for thurs [15:17] hatch: ok cool [15:17] jcsackett: in the index.html set the window.flags.mv as true [15:17] then visit the gui without the mv flag in the url [15:17] hatch: ah. [15:17] this way you can take steps towards removing the flag without having to do it whole hog [15:17] huuuuge time/sanity saver === fabrice is now known as fabrice|family [15:21] hatch: ah. does that make it safe to land pieces at a time, then? [15:22] jcsackett: you bet [15:22] hatch: awesome. [15:22] because according to the user it's already the default [15:22] we can (and have) shipped like that too [15:22] hatch: cool. well then, i think my one enormous card just became several smaller ones. [15:22] :) [15:33] * rick_h_ heads to the doc, biab everyone [16:02] * rick_h_ heads to the doc for real this time [16:05] hatch: hope you're ready for more eyes on the ghost charm ;) You were featured sir! [16:05] oh crap [16:05] :) [16:05] <3 [16:06] I guess I should probably push the new version then [16:06] the 12 people that watch the video will be alllllll about ghost. [16:06] I wish you could upload extra files into charms - think templates [16:06] * lazyPower snickers [16:06] lol [16:06] you can [16:06] however, thats a prime candidate for a subordinate relationship eh? [16:07] juju deploy ghost-templates [16:07] juju add-relation ghost ghost-templates [16:07] juju set ghost-template theme="rocco" [16:07] well I don't really want to force people to make a charm just to deploy their template [16:07] ok, then make templates git deployable [16:07] but then they have to upload it to a public repo [16:07] heh [16:07] and the problem with that is? [16:08] say you are a real brand using Ghost as your blog [16:08] you don't want any joe running your template [16:08] then add deploy key support [16:08] juju set ghost deploy_key=(base 64 encoded ssh key) [16:09] is that encrypted? [16:09] from the cli [16:09] it would be 100x easier if you could upload a binary as a config option [16:13] kadams54: looks like my test failures after I fix a databinding bug will be fixed by your fix [16:13] hatch: :-b [16:14] somehow a config option is " false" [16:14] like wth [16:14] lol [16:14] something is seriously broken [16:14] odly enough though it works outside of tests [16:14] Maybe I should throw a trim() in there? [16:14] well no we need to figure out why it's that [16:15] I did some digging around and it looks like the values are stored as strings far more often then not [16:15] I don't just want to bandaid over the problem [16:15] That is, the *only* place where they weren't being stored as strings, that I found, was in the chunk of code I was working in. Strings everywhere else. [16:15] I want to find what's setting it to these invalid values [16:16] Fine. Don't review my PR ;-) [16:16] a checkbox toggle is boolean [16:16] plain and simple [16:16] somehow it's being set to " false" [16:16] so there is a real problem here somewhere [16:16] It's not plain and simple though, right? [16:17] Can't those config values also come from a yaml file? [16:17] Ditto for JSON [16:17] typeof checkbox.get('checked') === 'boolean' [16:17] always [16:17] false [16:17] ?? [16:18] Well, OK, true enough for checkboxes [16:18] when is a checkbox not either true or false [16:18] exactly [16:18] But checkboxes !== a boolean config setting [16:18] The boolean config setting can also be set by a "true" string in a yaml file [16:19] if there is a boolean config setting which is not being represented as a checkbox then it's a broken charm [16:19] or it's not a boolean config [16:22] kadams54: for example [16:22] http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/config.yaml#L50 [16:24] Sure, but when the yaml is parsed, is config['juju-gui-console-enabled']['default'] 'false' or false? [16:27] kadams54: in handlers.js there is a method called serviceInfo put a debugger in there in a real env with the gui deployed and see what it has [16:27] It has a string. [16:28] well there ya go [16:28] :) [16:31] kadams54: so we should convert all boolean values to their true boolean values for use in the gui [16:31] Checking something else… [16:31] then when we send it back we stringify it out anyways [16:33] Whoops, gotta run for dr appt, back in an hour [16:41] hatch: another option would be to encapsulate this as a juju action [16:41] (i know, an hour later i come up with another thought) [16:41] lazyPower: haha, how would a juju action work? You 'd have to run it every time you scaled [16:41] no? [16:42] correct [16:42] yeah I just think this is a bug [16:42] or a missing feature [16:42] but you're basically asking the end user to break auto-upgrade notifications [16:42] "fork the charm locally, plug in your theme, deploy" [16:43] heh right [16:43] which is why a subordinate would be prime for this. If the subordinate is responsible for understanding where ghost is installed, and auto-deploy the theme you've defeated the scale issue. [16:43] and you dont have to push it into a subordinate. You've just moved a large chunk of logic out of the parent charm into a supporting role. [16:44] and fwiw, if you make the sub support binary package delivery, such a placing a tarball in files/ - who cares if the theme deployer gets an update. unless its breaking ghost, you're g2g after you've deployed it. Set it and forget it (tm) [16:45] right but that's a horrible story considering that the user who is used to ghost just logs into their control panel and uploads the zip [16:46] rick_h_: ping me when you get back - I think that my issue will be resolved if we don't care about conflicts on boolean values [16:48] lazyPower: I'm probably going to file a feature request with juju to add binary config value support [16:49] tbh this could benefit a lot of different charms - expecially ones with complex values.....like the apache charm with a large virtual env config [16:50] hatch: that exists today as base64 encoding. [16:51] not great, but fair enough that it would be easier to say "attach thing" [16:51] validation of those "things" is going to be hairy. [16:51] base64 encode a zip of a template....lol [16:51] you can do it [16:51] why does it need to be validated? [16:51] couldn't we add another config type 'binary'? [16:52] well you just said a "large vhost file" [16:52] which is text to begin with, do you want someone to upload a picture of their cat and have the apache charm barf because they uploaded the wrong MIME type of file? [16:52] well I just picked an example [16:52] they could upload a .txt file [16:52] * lazyPower pulls out the paint brush and gets ready to paint the bikeshed [16:52] if they uploaded a cat picture instead...well then too bad for them [16:53] that would be the same as copy\pasting an invalid virtual env config [16:54] lazyPower: I'm creating a bug atm - so we can move the discussion there [16:55] better to have any questions/comments documented [16:55] hatch: unless it includes a screenshot with the caption "Schenanigans" - i reject your bug [16:55] <3 [16:55] i had no idea the gui did that btw. that blew my mind [16:55] i pinned a card on our canban to talk about that in today's standup [16:55] *kanban [16:56] as nobody else knew why it was doing that either. I'm gonna blow some minds today [16:56] lol what? [16:56] https://bugs.launchpad.net/juju-gui/+bug/1371821 [16:56] Bug #1371821: Juju GUI isn't displaying namespaced recommended charms as featured

[16:56] ohh heh yeah [16:56] I wrote the sort for it so it's my fault [16:57] s/fault/feature [16:57] tbh I'm not entirely convinced for cases when there isn't a valid 'trusty' charm but there is a precise one [16:57] but I didn't want to get too complicated as it should probably be sorted in charmworld [17:04] lazyPower: https://bugs.launchpad.net/juju-core/+bug/1372566 [17:04] Bug #1372566: Add a config field type 'binary' [17:35] it looks like work on sublime text 3 has started again http://www.sublimetext.com/3 [17:43] and in another year I bet another update will come out lol === uru_ is now known as urulama [17:55] hatch: pong [17:56] rick_h_: hey I want to propose dropping conflict resolution/notifications for boolean values. call in standup? [17:56] hatch: k [18:06] kadams54: I was able to get this to work regardless of the outcome of your branch - so yay === fabrice|family is now known as fabrice [18:37] lunching === abentley_ is now known as abentley [18:48] lazyPower: the hive-mysql one didn't seem to ingest? The other two I see (from your email) [18:48] rick_h_: they were pushed really recently, it might still be in the ingest-o-tron [18:48] lazyPower: it passed proof and such? [18:48] si [18:48] lazyPower: ok [18:49] charles@desktop:~/tmp/charms/bundles/hdp-hadoop-hive-mysql⟫ charm proof [18:49] charles@desktop:~/tmp/charms/bundles/hdp-hadoop-hive-mysql⟫ [18:49] i called that out at the top that they are recent and might be waiting for ingestion. We should see the hive-msyql one show up in ~ another 10 minutes or so. [18:49] k [18:49] lazyPower: yea, was checking and saw the other two are there [18:49] want to make sure it gets in ok [19:28] boo [19:28] hoo [19:28] lazyPower: my bug was marked as low ;'( [19:28] hatch: mine was markes as invalid :'( [19:28] lol well yours WAS invalid :P [19:29] I suppose mine IS low haha [19:29] ouch [19:46] hah, love dual'ing PRs [19:51] jujugui I need a review and qa on https://github.com/juju/juju-gui/pull/573 [19:51] rick_h_: haha you mean because mine and Makyo's landed at the same time? [19:51] hatch: yea, got two new emails right next to each other [19:51] Yep :D [19:51] great minds think alike.....eh Makyo? eh??? [19:52] On that note, jujugui need reviews/QA on https://github.com/juju/juju-gui/pull/572 (real env) [19:52] trade ya! [19:52] Sure thing [19:53] Makyo: u gona give me some qa notes? [19:54] Hadn't hit enter yet, sorry [19:55] noooo prob [20:20] hatch, I think your branch is okay, but it's not matching your QA instructions, so I'd like to verify. [20:20] Like, I think it's good, I just think your QA instructions might be mixed up. [20:20] Makyo: oh ok [20:21] whats up? [20:21] hatch, I changed debug to baz in the inspector. After changing it to foo on the cli, the inspector should still show 'baz', right? Because it's showing the changes that exist in the ECS? [20:21] I just think foo and baz got mixed up in your instructions. [20:21] ohh yes you are correct it should still show baz [20:22] I'll fix that in the docs [20:22] Good. YEah, I think this branch is good. [20:22] thanks [20:22] awesome good catch :) [20:22] just about to spin up to qa yours [20:29] jujugui anyone know why the first lxc instance takes quite a while to boot but then subsequent ones are really fast? Is this something with lxc or my setup being busted? [20:29] hatch: first on a new system? [20:29] hatch: how long is "very long"? i've given up on juju w/ lxc on my machine thinking it was busted. [20:30] like 15mins for the first instance [20:30] then 1m for the second [20:30] hatch: first as in 'download the OS for use by lxc' or first after reboot? [20:30] hatch: it downloads the cloudimg from simplestreams, extracts it and builds the base lxc from which everything else is cloned. [20:30] I've created/torn down an env a few times today [20:30] so it's not caching the images? [20:30] hatch: it should be [20:31] hatch: oh, no. that should happen once per host system. So that isn't it. [20:31] /var/lib/lxc/juju-{precise,trusty}-template [20:31] yeah those are there [20:31] lxc-clone: true ? lxc-clone-aufs: true ? [20:32] there is a lxc-clone but no lxc-clone-aufs [20:33] hatch: I like the aufs option, which is false by default. [20:33] is that only on btrfs? [20:33] hatch: also, depending upon which version of juju you run, apt-get update/upgrade may or may not run on system image deploy [20:33] yeah it took 10mins to spin up this time....second machine will be about a minute [20:33] rick_h_: aufs is an alternative to btrfs [20:34] oic [20:34] hatch: no, that first machine taking 10 and second machien taking 1 doesn't add up to using these options. [20:34] jrwren_: ok thanks...I think [20:34] haha [20:34] I was hoping this was normal [20:34] lol [20:35] I didn't think juju had a "normal" [20:35] haha [20:37] hatch: do you notice it is slow if you add machine instead of deploy a charm? [20:41] jrwren_: I'll have to check in a bit [20:43] that machine was 1.5min [20:43] so weird [20:44] I wonder if there is some funkyness because I'm in a parallels vm [20:45] Makyo: what's this containers flag you speak of? [20:45] oh look at that [20:45] hmph [20:45] lol [20:46] i'm afk. have a good evening ya'll. Happy Equinox. [20:46] cyaaaa [20:56] ok something is totally borked with my env [21:01] Makyo: review and qa done [21:02] jujugui anyone else available for a review? https://github.com/juju/juju-gui/pull/573 [21:02] hatch: will do at some point, otp right now [21:02] ok sounds good - I'm going to move on with it assuming it's ok :( [21:02] :) [21:02] er [21:02] :) [21:02] kadams bah not here [21:03] maybe doc appt didn't go well [21:03] "sorry, you have semicolon pinky - you will need to change programming languages" [21:03] NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO [21:13] going to grab a coffee, back in ~15 [21:28] hatch: off phone, but leaving for son/dinner so will try to get to code review later tonight [21:28] * rick_h_ runs away [21:32] back [21:33] rick_h_: cool np enjoy === urulama is now known as urulama-afk [23:00] Morning [23:05] huwshimi: morning, can you make sure to check for any reviews of the storeferont stuff from ant/robin as part of the daily workflow? [23:06] rick_h_: Hey, sure np