[02:24] <rick_h_> morning huwshimi 
[02:24] <huwshimi> rick_h_: Hey :)
[15:18] <hatch> uiteam what's the proper way to test for null config value within a python charm hook? 
[15:19] <frankban> self.assertIsNull(value)?
[15:19] <frankban> hatch: ^^^
[15:19] <hatch> frankban: I mean as a conditional
[15:19] <hatch> I need to know if the user has defined a config value or not
[15:19] <hatch> so I need to test for null and ""
[15:19] <rick_h_> hatch: I'd just check if it's a digit and if it is, then try to use it as a port
[15:20] <frankban> value = config.get('my-option'); if value...
[15:20] <hatch> rick_h_: int(config.get('...')) ?
[15:21] <hatch> basically the default config value is null (it's actually empty default which juju considers null)
[15:21] <frankban> hatch: if the value is declared as an int on the config.yaml, I am fairly sure that you cannot get another type
[15:21] <rick_h_> ah gotcha
[15:21] <hatch> ok the docs are very confusing then
[15:21] <rick_h_> hatch: yea, frankban has it 
[15:22] <hatch>   port:
[15:22] <hatch>     description: |
[15:22] <hatch>       Supply a different port to host the GUI on besides the default 80 and 443.
[15:22] <hatch>     type: int
[15:22] <hatch>     default:
[15:22] <hatch> according to the docs that should be null
[15:23] <rick_h_> hatch: it depends on juju version and such. There was some work on their end to split up null vs "" and the GUI doesn't respect it currently :/
[15:23] <hatch> so I'm trying to make the parser as resilient as possible in the event the user sets it to "" as well
[15:23] <rick_h_> hatch: so frankban's idea will work because "" is falsey in python
[15:23] <rick_h_> if "": 
[15:23] <rick_h_>     print 'false'
[15:23] <rick_h_> err true I mean
[15:23] <hatch> right, but what is null if it's an int field
[15:23] <kadams54> lol
[15:23] <hatch> does it send "null" ?
[15:23] <hatch> or...
[15:24] <hatch> I could test it, but testing these hooks is painful :)
[15:24] <rick_h_> hatch: try it out :)
[15:24] <rick_h_> lxc deploy away!
[15:24] <hatch> it's in the install hook 
[15:24] <hatch> so I can't really do the hooks debugging
[15:24] <rick_h_> log it out what you get and any checks you want
[15:25] <frankban> hatch: I think that value can be either None (the Python spelling for null/nil) or an empty string, and even if it's just 0 (the zero value for integers in Go) that check would still be ok
[15:26] <hatch> YAML > Go > JSON > Python 
[15:26] <hatch> yay 
[15:26] <hatch> lol
[15:26] <rick_h_> hatch: never bored :)
[15:26] <frankban> bool(None) == bool('') == bool(0) == False
[15:27] <hatch> frankban: yeah I'm just concerned that it'll send something like "null" which will be truthy
[15:27] <rick_h_> frankban: right but he's worried about getitng bool('null')
[15:27] <hatch> yeah
[15:27] <rick_h_> hatch: just try it 
[15:27] <rick_h_> hatch: we're all just guessing for you
[15:27] <hatch> yup trying now
[15:27] <hatch> :)
[15:27] <frankban> hatch: if you get the string "null" the problem is elsewhere
[15:38] <hatch> the local charm deploy api needs some work :/
[15:44] <hatch> interesting, it fails
[15:45] <hatch>         log('default null is')
[15:45] <hatch>         log(config['port'])
[15:45] <hatch> unit-juju-gui-0: 2014-11-12 15:38:55 INFO start KeyError: 'port'
[15:45] <hatch> maybe charmtools doesn't support null config values
[15:47] <hatch> er charmhelpers
[15:52] <hatch> error: invalid value "json" for flag --format: unknown format "json"
[15:52] <hatch> uhhh
[15:52] <rick_h_> hatch: there was a bug around that a while back. Maybe time to update charmhelpers?
[15:53] <hatch> ohh - there just may be :)
[15:53] <hatch> any idea why that format flag on get doesn't work?
[15:53] <hatch> juju get --format=json juju-gui
[15:53] <hatch> throws that error
[15:54] <hatch> _config_get = command('config-get', '--format=json')
[15:54] <hatch> that's in the helpers
[15:54] <hatch> so I'm just trying to determine what's failing
[15:54] <hatch> or maybe format only works in hooks?
[15:54] <hatch> (which would be odd)
[15:54] <rick_h_> hatch: right, I'm saying there was a bug I'm trying to find around that
[15:55] <hatch> 1.20.11-trusty-amd64
[15:55] <rick_h_> hatch: that's your juju version? and the charmhelpers version?
[15:56] <rick_h_> bah I swear I saw this thing and google is failing me
[15:56] <hatch> no version information in the charmhelpers.py file
[15:56] <rick_h_> uiteam call in 5
[15:56] <rick_h_> kanban please
[15:56] <hatch> but --format doesn't work on the CLI either
[15:56] <rick_h_> right
[15:57] <rogpeppe> hatch: what output do you get from the CLI ?
[15:57] <hatch> rogpeppe: <hatch> error: invalid value "json" for flag --format: unknown format "json"
[15:58] <rogpeppe> hatch: ha, so i see
[15:58] <rogpeppe> hatch: there's a TODO in the code
[15:58] <rick_h_> damn I love having good docs search now
[15:58] <rogpeppe> hatch: i'm surprised it isn't implemented
[15:58] <hatch> rogpeppe: but it works in the hooks?
[15:58] <rick_h_> http://qa.storefront.theblues.io:6543/docs/authors-hook-environment#hook-tools
[15:58] <rick_h_> hatch: yea, it's a hook tool
[15:59] <rogpeppe> hatch: it should work in the hook tool
[16:00] <rick_h_> kadams54: call?
[16:00] <mhilton> bac, rick_h: It looks like mojo is creating blues-browser tarballs with all the bzr history in them so they are 170odd MB is that enough to explain the timing?
[16:00] <kadams54> rick_h_: joining.
[16:00] <rick_h_> mhilton: call?
[16:01] <rick_h_> mhilton: wrong channel please
[16:01] <hatch> rick_h_: rogpeppe ahh ok
[16:03] <hatch> ok I can probably test this via the hooks I guess
[16:03] <hatch> rogpeppe: is there a bug about that --format? Or just a note in the code? :)
[16:06] <rogpeppe> hatch: there's no bug referenced in the code comment
[16:07] <hatch> ok do I just file a bug on the Juju project?
[16:07] <hatch> juju-core that is
[16:24] <hatch> uiteam is there a way I can deploy a local charm without it being in the specific undocumented folder structure? Or should I just create a symlink to the real folder?
[16:24] <frankban> hatch: if you are talking about the gui charm, just run make deploy
[16:25] <mhilton> hatch I do the symlink thing
[16:26] <hatch> frankban: yeah I was just hoping I didn't have to do workarounds for such a basic functionality heh
[16:26] <hatch> mhilton: ok thanks
[16:34] <hatch> symlink appears to work well
[16:35] <rick_h_> hatch: so I have a /src/charms directory with trusty/precise directories and do all my charm dev in those for just that reason. Once I set it up it's been cool but yea annoying
[16:35] <hatch> rick_h_: yeah I tried that workflow but it doesn't really work when you have the same charm for both versions of ubuntu
[16:35] <hatch> ghost, juju-gui etc
[16:35] <rick_h_> hatch: right, just have two checkouts really
[16:35] <hatch> then you also have to have very odd names for repositories
[16:35] <hatch> ohh
[16:36] <hatch> I think I'm going to file a bug around this
[16:36] <rick_h_> hatch: and have to sync between them, and since you forked and can work between your branches it's ok
[16:36] <hatch> it's really a poor UX imho
[16:36] <hatch> it's not intuitive
[16:45] <hatch> rogpeppe: could you point me to the line of code in GH where the note is about --format=json?
[16:52] <hatch> uiteam does the config-changed hook get any indication of the  old/new values? Or which fields have been changed?
[16:52] <jcsackett> hatch: don't think so.
[16:53] <hatch> I didn't think so
[16:53] <hatch> any ideas on how I may close a previously opened port?
[16:53] <mhilton> hatch: Are you using charmhelpers?
[16:53] <frankban> hatch: the gui charm stores previous values
[16:53] <hatch> mhilton: yes
[16:53] <hatch> frankban: oh?
[16:53] <mhilton> hatch: in that case the Config option can do that for you.
[16:53] <mhilton> s/option/object/
[16:55] <frankban> mhilton: the gui charm does not use charmhelpers
[16:55] <rick_h_> hatch: there was an email about the latest juju alpha that adds support for finding what ports are open though
[16:55] <frankban> hatch: look at backend.py
[16:55] <mhilton> hatch: http://pythonhosted.org/charmhelpers/api/charmhelpers.core.html#charmhelpers.core.hookenv.Config
[16:55] <hatch> frankban: right so I have backend.config
[16:56] <hatch> which is utils.get_config()
[16:56] <frankban> hatch: I think that the backend.different method is used there
[16:56] <hatch> ahh I see how it does it
[16:57] <hatch> mhilton: yeah the version of charmhelpers we have here doesn't have that
[16:57] <hatch> frankban: thanks
[16:57] <jcsackett> rogpeppe: archivedownloadcount in stats is supposed to show deploys for a charm, right?
[16:57] <frankban> np
[16:58] <mhilton> hatch: sorry, you might be able to crib what it does though.
[16:58] <hatch> mhilton: yeah looks like the guicharm already has the functionality baked in
[16:58] <rogpeppe> jcsackett: it shows downloads, which might not be the same thing
[16:58] <rogpeppe> jcsackett: if you deploy a charm twice in an environment, it will only download once
[16:59] <jcsackett> rogpeppe: ok--so is that why the discrepancy between downloads here http://manage.jujucharms.com/charms/trusty/wordpress and here https://api.jujucharms.com/v4/trusty/wordpress/meta/any?include=stats
[16:59] <hatch> man I miss chrome devtools :P
[16:59] <jcsackett> b/c i'm noticing basically everything has *very* low counts.
[16:59] <rogpeppe> jcsackett: we didn't grandfather in the old counts
[16:59] <jcsackett> hm, ok.
[16:59] <rogpeppe> jcsackett: so everything has started from scratch
[17:00] <rogpeppe> jcsackett: perhaps raise an issue about that
[17:00] <jcsackett> that's reasonable, but some of the feedback we've gotten is about the low counts we're showing.
[17:00] <jcsackett> rogpeppe: yeah... rick_h_, thoughts ^
[17:01] <hatch> rogpeppe: could you point me to the line of code in GH where the note is about --format=json? (whenever you have a moment, I'd like to add it to the bug report)
[17:02] <rogpeppe> hatch: line 31 here https://github.com/juju/juju/blob/master/cmd/juju/get.go
[17:03] <hatch> thanks :)
[17:04] <rick_h_> jcsackett: rogpeppe yea, I wasn't sure if we wanted to try to split things up a bit and reset since there's so much legacy numbers but I think having 0 is bugging people more than my hope for a fresh start :)
[17:04] <hatch> golang syntax highlighting in github is pretty nice
[17:08] <jcsackett> rick_h_, rogpeppe ok, i've filed an issue.
[17:19] <hatch> kadams54: will review your branch
[17:19] <kadams54> uiteam: looking for reviews on https://github.com/juju/juju-gui/pull/654 < hatch, rick_h_ 
[17:19] <kadams54> Damn you hatch, you're fast.
[17:19] <hatch> github pinged me
[17:19] <hatch> said 'check this ish out yo'
[17:20] <kadams54> FYI, build failed fast, so I'm guessing a lint issue. Fixing now.
[17:21] <kadams54> hatch, rick_h_: checkout this code diff: https://github.com/juju/juju-gui/pull/654/files#diff-f49ed99ac4fd4002b0649222733b6feaL50
[17:21] <kadams54> Great example of how much the code was simplified by this change.
[17:22] <hatch> bahahaha
[17:22] <hatch> +1M
[17:22]  * rick_h_ gets a cigar out "I love it when a plan comes together"
[17:22] <hatch> brb
[17:22] <hatch> rick_h_: hahahahaahaha
[17:22] <hatch> we need a MR T
[17:22]  * hatch will be Face
[17:23]  * kadams54 nominates Wayne Witzel for Mr. T.
[17:23] <rick_h_> I nominate urulama for Mr T, I want to see him with mad chains :)
[17:23] <kadams54> lol
[17:23] <kadams54> bling galore
[17:23] <rick_h_> the best would be getting wayne for Mr T
[17:23] <rick_h_> but not ready to adopt him over here yet :P
[17:24] <kadams54> Maybe next year I'll add some gold chains to the gamehawk: http://imgur.com/a/OVbqs
[17:25] <rick_h_> lol
[17:25]  * rick_h_ donates to that kickstarter
[17:25] <hatch> "and the winner goes to.....The A Team with the real black guy" 
[17:25] <hatch> - family guy
[17:25] <hatch> ahh funny episode 
[17:26] <rick_h_> hatch: looking at the review, can you do QA please?
[17:26] <hatch> lol urulama with bling
[17:26] <hatch> he's going to look at these dings later and be like 'uhhhh?' :D
[17:26] <hatch> rick_h_: yep on it
[17:26] <rick_h_> ty
[17:31] <hatch> kadams54: are these handlers just copy/pasted or were there internal changes?
[17:32] <kadams54> hatch: the actual handler code worked mostly without change.
[17:32] <hatch> alright
[17:32] <kadams54> I did make one internal change, which was to shift from serviceName to using ID everywehre
[17:32] <kadams54> That also simplified code
[17:32] <hatch> doesn't that cause issues with ghost services?
[17:33] <kadams54> Nope.
[17:33] <rick_h_> hatch: can you make sure to QA with subordinates please? It's been on my mind that I've not tried that yet
[17:33] <kadams54> Works better for ghosts
[17:34] <kadams54> The issue we had with ghosts was that we were using service names everywhere and on ghosts the ID is different from the name.
[17:34] <hatch> right - but if you change the visibility status of the ghost then deploy
[17:34] <hatch> does it break then?
[17:34] <hatch> ( I haven't got to qa yet)
[17:36] <kadams54> Shouldn't. The code handles ID changes.
[17:36] <hatch> cool
[17:36] <kadams54> The token will re-render with the new ID.
[17:36] <kadams54> But definitely worth testing the snot out of it :-)
[17:40] <hatch> ok qa'ing now
[17:45] <hatch> kadams54: +1 QA OK - there is a qa issue but it's minor
[17:45] <kadams54> I'll check it out
[17:46] <hatch> oh crap I just found another bug
[17:46] <hatch> blarg
[17:46] <hatch> ok one sec I'll try and reproduce it and then add to the PR
[17:46] <hatch> (might be pre-existing though_
[17:49] <kadams54> Let's get them all out of the system now :-)
[17:49] <hatch> kadams54: ok added this new bug to the PR
[17:50] <hatch> I'm pretty confident it's how it calculates what's related or not
[17:50] <hatch> so likely pre-existing
[18:00] <hatch> kadams54: I replied to the multi handler reply
[18:04] <kadams54> hatch: And I replied back :-)
[18:04] <hatch> we really need to figure out a better system for discussions on PR's
[18:04] <hatch> lol
[18:05] <hatch> maybe a rasp-pi with an led which turns green when review comments are done
[18:05] <hatch> and red again when new ones need discussing
[18:05] <hatch> lol
[18:05] <hatch> rasp-pi might beoverkill :)
[18:07] <hatch> lunching
[18:42] <kadams54> hatch: when you get back, I commented on the QA issues.
[18:43] <hatch> looks good thx
[18:43]  * hatch isn't back
[18:44] <kadams54> OK, if this build passes, I'll ship PR#654.
[19:01] <hatch__> kadams54: did you need me to create cards/bugs for those qa issues?
[19:16] <kadams54> hatch__: I can create them.
[19:23] <hatch__> kadams54: so we should probably focus on those bugs next
[19:23] <kadams54> True. I'll pick them up before optimizing the events.
[19:24] <hatch__> great - if there is anything I can help with lemme know
[19:35] <rick_h_> hatch__: woot it works!
[19:35] <hatch__> rick_h_: lol YEAHHHHHHHH
[19:35] <rick_h_> hatch__: and I didn't see the dns name because hover paginates your dns entries after 10 :/
[19:35] <hatch__> lol
[19:35] <rick_h_> it was name #11 for my dns 
[19:49] <hatch__> took it up to 11!
[21:15] <hatch__> rick_h_: so here is what i have https://gist.github.com/hatched/9b0a1723be672a1ee3fe
[21:15] <hatch__> but it's never using the custom ports
[21:16] <rick_h_> hatch__: looking
[21:16] <hatch__> so I need to debug this script somehow
[21:16] <hatch__> so I can use debug  hooks, but then I need to install pdb?
[21:16] <rick_h_> hatch__: so I'd log out what backend.config and backend.prev_config are
[21:17] <rick_h_> hatch__: are your log items in the modify_open_ports function getting called?
[21:17] <rick_h_> hatch__: e.g. you have log items there?
[21:17] <hatch__> yes it's saying it's using the default values
[21:17] <hatch__> if hasattr(config, 'port')
[21:17] <hatch__> so this is never resolving to true
[21:18] <rick_h_> hatch__: ok, so yea I'd look at what the config has in it by logging the config/prev_config
[21:18] <rick_h_> hatch__: I'd also log in the closing command above close_port
[21:18] <hatch__> ok cool, and best way to dump a complex object in python?
[21:18] <rick_h_> I bet backend.config, backend.prev_config is wrong
[21:18] <rick_h_> hatch__: just str() it 
[21:18] <hatch__> ahh ok sounds good - will try
[21:18] <rick_h_> log(str(config))
[21:18] <hatch__> thx
[21:19] <rick_h_> np
[21:22] <hatch__> deploying the same local charm increments the counter but still deploys the old code
[21:22] <hatch__> how awesome 
[21:22] <hatch__> lol
[21:22] <rick_h_> heh
[21:22] <hatch__> good thing I got my lxc going fast again somehow
[21:27] <hatch__> rick_h_: https://gist.github.com/hatched/a455aae7cae3c5b35bc5 so as you'll see port is available in the first dump which is `config`
[21:28] <hatch__> oh wth
[21:28] <rick_h_> hatch__: oh, but you're checking hasattr
[21:28] <rick_h_> that's for a class
[21:28] <rick_h_> you just want to do 
[21:28] <rick_h_> if 'port' in config
[21:28] <hatch__> odly enough it resolves to true for the first confitional though lol
[21:28] <rick_h_> it's a key in dict check
[21:28] <rick_h_> hatch__: and the same with the prev config
[21:29] <hatch__> damn, I had that but thought hasattr was more appropriate because it's a method :)
[21:29] <hatch__> https://docs.python.org/2/library/functions.html#hasattr
[21:29] <hatch__> makes no mention of it requiring a class
[21:29] <rick_h_> no, it's for a class if you do obj.port
[21:29] <hatch__> just says object
[21:29] <rick_h_> you would check obj.hasattr('port')
[21:30] <hatch__> wow docs fail heh
[21:30] <hatch__> so which approach do you prefer?
[21:31] <rick_h_> if 'port' in config
[21:31] <hatch__> alright will give that a go
[21:31] <hatch__> so am I nuts or are the docs incorrect?
[21:31] <rick_h_> you're confusing a key with an attribute
[21:32] <rick_h_> JS has magic 'hash is an object' stuff
[21:32] <hatch__> OHHH now I see 
[21:32] <hatch__> yes my terminology name clashing
[21:32] <hatch__> oops
[21:33] <rick_h_> hatch__: http://paste.ubuntu.com/8972163/ for some clarity
[21:34] <hatch__> gotcha - I'm going to have to bust out the python book again this week
[21:34] <rick_h_> all good
[21:35] <hatch__> "use it or lose it" :P
[21:35] <rick_h_> woot, guimaas update complete and email sent out. 
[21:37] <kadams54> uiteam: Question: what happens to the units attached to a ghost service once that ghost service is committed?
[21:37] <rick_h_> kadams54: so the service is first put into juju, then units are added to it after it's real
[21:37] <rick_h_> kadams54: I believe we first have a 0 unit service and then add to it
[21:37] <kadams54> So the old units, the ones associated with the ghost service, are blown away rather than being updated.
[21:38] <rick_h_> kadams54: no, they're updated I believe. They turn from ghost units to real units? 
[21:39] <kadams54> rick_h_: it looks like the highlight/fade/hide flags are not being carried over when that transition happens… any pointers on where to look in code?
[21:39] <rick_h_> looking
[21:41] <rick_h_> kadams54: https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/utils/environment-change-set.js#L1160
[21:42] <kadams54> thanks
[21:42] <rick_h_> kadams54: I think that's where the new live units come in and we turn the ghosts into real models
[21:43] <rick_h_> kadams54: at least a point to put a debugger and see what happens
[21:45] <hatch__> is there a way to unset a juju config value? Set it back to null?
[21:45] <rick_h_> hatch__: juju unset
[21:46] <hatch__> that's for all config values though
[21:46] <rick_h_> oh
[21:46] <rick_h_> well no idea then
[21:46] <hatch__> rick_h_: atm if you set a port there is no way to get 80 and 443 back open without setting it to 443 manually
[21:46] <hatch__> because 80 just redirects to 443 :)
[21:46] <rick_h_> hatch__: gotcha, oh well gui is stateless-ish just blow it away and redeploy :P
[21:47] <hatch__> haha it's an int, the only way to even flag off of that is to set it to 0 or something
[21:47] <hatch__> because it errors if you try to pass empty string
[21:47] <hatch__> I could of course make it a string field
[21:47] <hatch__> but....that doesn't feel right
[21:47] <hatch__> heh
[21:47] <rick_h_> Makyo: do you have time to peek at https://codereview.appspot.com/172410043 today please?
[21:48] <rick_h_> Makyo: oh, you had an appt, if not all good we'll get it looked at
[21:50] <hatch__> rick_h_: nm I read the cli docs incorrectly :/
[21:50] <rick_h_> you and docs don't get along :P
[21:50] <hatch__> no kidding! today just isn't my day it seems 
[22:03] <kadams54> rick_h_: The code you pointed me to updates the unit's service… but there seems to be code elsewhere that's changing unit.id from '8163515$/0' to 'mysql/0'.
[22:04] <kadams54> Either that or it's creating a new unit. Either way, somewhere along the line the unit ID changes. Within that same space of code, the fade flag is also dropped from the object we store in the DB.
[22:04] <huwshimi> Morning
[22:04] <kadams54> huwshimi: Morning
[22:05] <huwshimi> kadams54: Hey!
[22:08] <hatch__> rick_h_: citizen M is advertising to me again...you know what THAT means!!!!
[22:08] <rick_h_> hatch__: :P
[22:08] <hatch__> lol
[22:09] <rick_h_> kadams54: yea, have to chase it down. Can you set a watch or stop on the db or something?
[22:09] <kadams54> Yeah, I can setup a temporary event handler that inspects unit changes/adds
[22:09] <rick_h_> kadams54: might be able to get hatch__ or Makyo to help chase it as they did more of it. 
[22:10] <rick_h_> kadams54: cool yea that should hopefully work out. 
[22:10] <hatch__> sorry what? I'm just reading Tornado docs
[22:10] <rick_h_> hatch__: lol
[22:10] <hatch__> right? more docs
[22:10] <hatch__> lol
[22:10] <rick_h_> hatch__: kadams54 is trying to figure out how ghost units turn into real units and why the hide/show flags are getting dropped
[22:10] <hatch__> gotcha
[22:10] <hatch__> ok lemme open that code and refresh my mmeory
[22:11] <hatch__> ^ kadams54
[22:11] <rick_h_> hatch__: I started pointing him at https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/utils/environment-change-set.js#L1160
[22:11] <rick_h_> but that's not quite the right spot
[22:13] <hatch__> kadams54: models.js:857
[22:14] <hatch__> thats the first handler from the delta updates
[22:15] <hatch__> kadams54: also line 40 of the same file is the generic process_delta handler
[22:15] <hatch__> which is called from the method on 857
[22:16] <hatch__> hmm wait sorry turns out my version is different than trunk heh
[22:16] <hatch__> oops one sec
[22:17] <hatch__> https://github.com/juju/juju-gui/blob/486c9b93632b5582a8c4b2c65c85efbf0c9c5614/app/models/models.js#L796
[22:18] <kadams54> thanks… I just hit EOD for now so I'm going to have to dig in more later tonight
[22:18] <hatch__> yeah sure np hope that puts you on the right track