[00:04] <hatch> man actually using the gui allows you to find so many bugs
[00:04] <hatch> haha
[00:14] <hatch> huwshimi:  if you're confused at all about what to include in the sort just leave it out, you can always add it in later
[00:14] <hatch> would just love to get this landed
[00:50] <hatch> ermahgerd this is frustrating
[00:50] <hatch> rick_h_:  charmworld MUST have an 'original source' and 'bug url' field so that we can display them in the charm details page
[00:51] <rick_h_> hatch: sure it does
[00:51] <rick_h_> there's a bug and source link in the gui
[00:51] <hatch> and the 'commit to this charm' link needs to be removed asap
[00:51] <hatch> because it takes you to a 'how to commit to a charm' link but not to the real page in question
[00:52] <rick_h_> commit to this charm?
[00:52] <rick_h_> the contribute link that goes to the author docs?
[00:52] <hatch> yeah
[00:52] <hatch> sorry contribute 
[00:52] <hatch> I can't contribute to the charm via that link
[00:52] <rick_h_> ok, maybe https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-fix-to-an-existing-charm
[00:53] <rick_h_> is the better link, but not sure 'needs to be removed asap'
[00:53] <hatch> yeah except that doesn't work - using the information provided in the gui we can't even get to the charm source
[00:53] <hatch> all we get is "cs:precise/mysql" (for example)
[00:53] <rick_h_> there's a link on the header called "source" that takes you straight to bzr
[00:53] <hatch> that's all the user is left to work with
[00:54] <hatch> right, but that's only if you haven't deployed yet
[00:54] <hatch> if you're viewing it from the inspector you have no information like that
[00:54] <rick_h_> ok, well we'll be doing better with full data in the new charmstore but nothing we can do for that. 
[00:55] <rick_h_> the info isn't in the charm, when you deploy the charm is copied with no sense of where it came from
[00:55] <rick_h_> we're making that better with the other stuff
[00:55]  * hatch is frustrated that none of the promoted mysql charms work
[00:56] <rick_h_> hatch: did you try out with more memory like sinzui mentioned?
[00:56] <hatch> 8GB's of them :)
[00:56] <hatch> same error
[00:56] <rick_h_> hatch: go walk away man
[00:56] <rick_h_> hatch: all good for today
[00:59] <hatch> bug filed https://bugs.launchpad.net/charms/+source/mysql/+bug/1365205 NOW it's time to get off
[00:59] <mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1365205>
[00:59] <hatch> hah
[00:59] <hatch> :)
[03:43] <hatch> lazyPower: hey yes I have filed a bug ^
[04:21] <hatch> huwshimi:  hey need anything before I take off?
[04:26] <huwshimi> hatch: I think I'm all good. Thanks Jeff
[04:34] <hatch> huwshimi:  sounds good, np
[11:30] <rick_h_> morning party people
[13:12] <hazmat> rick_h_, g'morning
[13:12] <rick_h_> hazmat: party
[13:12] <hazmat> rick_h_, time
[13:18] <rick_h_> frankban: once your branch is up for review, can you take a look at updating the quickstart beta ppa with the latest releases of deployers/juju client? 
[13:19] <rick_h_> frankban: and then have those copied over to the juju stable ppa once we're cool with the updates?
[13:19] <rick_h_> frankban: jujuclient 0.18.4 juju-deployer 0.4.0  python-websocket-client 0.18.0
[13:22] <frankban> rick_h_: sure, are those versions included in the trusty and utopic repos?
[13:22] <rick_h_> frankban: so hazmat is working on getting them into utopic
[13:22] <rick_h_> frankban: so we'll track that work and try to make sure we get QS updated with those deps if they get in ok
[13:22] <rick_h_> frankban: no trusty afaik
[13:25] <frankban> rick_h_: ok I'll take a look. In theory we want quickstart to be installed without the PPA in both trusy and utopic, and so, if they have different versions of the dependencies, we need to support both in some way. anyway, when the packages are in utopic is really easy to backport those and put them in the PPA
[13:25] <rick_h_> frankban: right, I figure if we update our ppa, and then get them into the juju stable ppa, then we can request an update to utopic across the board pretty easily
[13:25] <rick_h_> trusty won't get updated on either end. We're not going to be able to update trusty anymore without a major bug/etc I think.
[13:31] <frankban> rick_h_: ok
[13:46] <jcastro> hey luca___
[13:46] <jcastro> wrt the website
[13:46] <jcastro> https://bugs.launchpad.net/juju-website
[13:46] <luca___> jcastro: heya
[13:46] <jcsackett> rick_h_: charmworld landings are all done through lbox still, right?
[13:46] <jcastro> I forgot we had bugs filed on it in one place
[13:46] <jcastro> might help with cleanup
[13:46] <luca___> jcastro: brilliant, I will take a look
[13:47] <luca___> jcastro: are there any other pages that can be killed?
[13:47] <jcastro> I made you maintainer so you can actively close bugs
[13:47]  * frankban lunches
[13:48] <jcastro> https://juju.ubuntu.com/resources/easy-tasks-for-new-developers/ this will need an update, but not yet, you can put that page on your hitlist though
[13:50] <rick_h_> jcsackett: double checking, I htink so
[13:50] <rick_h_> jcsackett: yea, still has the lbox stuff in tree
[13:50] <jcsackett> rick_h_: i found .lbox in the tree
[13:50] <jcsackett> yeah.
[13:50] <jcsackett> should've checked that first, i suppose. :p
[13:51]  * jcsackett digs back into getting lbox working...
[13:52] <hatch> lazyPower: hey did you see the bug I created for the mysql charm?
[13:52] <lazyPower> hatch: i did. looks like a gpg key changed
[13:52] <lazyPower> i haven't attempted deployment myself however. I'm a bit tied up for at least another hour. 
[13:53] <lazyPower> marcocepp, mbruzeki: have you seen this behavior out of the MySQL charm before? https://bugs.launchpad.net/charms/+source/mysql/+bug/1365205
[13:53] <mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1365205>
[13:53] <hatch> ok np - I don't need it again until I start working on the ghost charm again
[13:53] <hatch> but I figure it's pretty critical if a promoted charm won't deploy
[13:53] <hatch> heh
[13:54] <hatch> lazyPower: I also have to create my own ghost-haproxy charm :'(
[13:54] <lazyPower> why do you need to create your own charm?
[13:55] <hatch> the haproxy charm is pretty out dated - it doesn't support ssl (according to the readme) and I can't provide my own config values for url redirects based on a regex
[13:55] <hatch> I need to redirect the old tumblr urls to the new ghost ones
[13:57] <hatch> I used a lot of juju last night and found a lot of annoyances around the charm/contribution system
[14:00] <lazyPower> hatch: are you documenting these pain points? All feedback is welcome.
[14:00] <hatch> lazyPower:  yeah I'm going to fire an email to the canonical juju list
[14:01] <hatch> tbh most of the issues revolve around the ~charmers stuff
[14:01] <hatch> who's the author, where do I file bugs, how do I get in touch with the author, where is the real repo
[14:01] <hatch> I'm pretty sure these fields are being added to the new charmworld stuff 
[14:02] <hatch> but wow is it.....challenging :) 
[14:04] <rick_h_> hatch: we've been talkig about those issues. I had a call with eco yesterday around that
[14:04] <rick_h_> hatch: I'm starting a couple of UX docs around it and we can see if those help/hurt your experience
[14:06] <hatch> sounds like a plan
[14:06] <hatch> if it frustrates me I can't imagine some external user
[14:06] <rick_h_> hatch: +1
[14:08] <hatch> the haproxy charm issue is really unfortunate (not having the features I need) This is a story we need to investigate more. ATM it looks like I can 1) file a bug on lp and hope, or 2) learn haproxy enough to write my own charm
[14:09] <hatch> neither are what we want thb
[14:09] <hatch> we almost need a 'this charm is out of date, and missing features' button for promoted charms :) 
[14:10] <hatch> but....maybe the simplest is a direct line to the charm author... "if your charm is to be promoted you must be available to be contacted by the community" <--- that's a rule I could get behind
[14:36] <hatch> rick_h_:  sorry for finding more bugs last night :) 
[14:36] <rick_h_> hatch: all good
[14:38] <urulama> jujugui: see you all later, school time :)
[14:39] <rick_h_> jujugui quick review please https://github.com/juju/juju-gui/pull/530
[14:39] <hatch> on it
[14:39] <rick_h_> ty much
[14:40] <hatch> rick_h_:  so we don't want to remove the functionality that passes the provider data into the templates?
[14:40] <rick_h_> hatch: no, it's still in the api and still in charmworld
[14:41] <hatch> ahh ok 
[14:41] <rick_h_> hatch: that might get updated, but for now just remove the UX, the model/data is still in the api stuff 
[14:41] <rick_h_> just to clean up the UX
[14:41] <hatch> sounds good, just going to qa
[14:41] <rick_h_> rgr
[14:43] <rick_h_> Makyo: hatch can either of you do a second review of kadams54's branch to help move that forward please?
[14:43] <Makyo> Sure, on it
[14:44] <rick_h_> ty Makyo 
[14:45] <hatch> rick_h_:  has there been any discussion about pulling the possible instance options from the provider and then us listing them instead of just showing constraints? 
[14:45] <rick_h_> hatch: huh?
[14:45] <rick_h_> what are 'instance options'
[14:45] <hatch> sorry totally out of context
[14:45] <rick_h_> ?
[14:45] <hatch> heh
[14:45] <hatch> when I create machines
[14:45] <hatch> it gives me three fields then picks the most appropriate
[14:45] <hatch> instance type
[14:45] <hatch> on ec2 for example
[14:46] <rick_h_> so there are the start of 'provider constraints' and the first ones are ec2 ones that show mx3.large and such
[14:46] <rick_h_> hatch: so they're getting added slowly and are provider specific and yes we want to support that and the work frankban is doing will help us with some of that I think
[14:46] <rick_h_> the idea of 'features' or maybe we'll just have to match up constraints better vs a provider list
[14:47] <hatch> oh cool - last night I ended up with a monster of a machine because the break point that it picked was on the 'conservative' side, instead of picking the closest 
[14:47] <rick_h_> lol
[14:47] <rick_h_> yea
[14:48] <hatch> well as long as someone else has already thought of this :)
[14:48] <rick_h_> yep, and some of the work exists, we're not caught up with it atm
[14:51] <hatch> rick_h_:  there is one oddity in the inspector i noticed yesterday - exposing a service does not go through the ecs, it's a straight call to the env, is this expected? 
[14:52] <rick_h_> hatch: hmm, good catch. I'm thinking. What happens if you expose an uncomitted service
[14:52] <rick_h_> I'm tempted to think it's ok, but it has to work properly with an undeployed service
[14:52] <hatch> yeah I never tried that...
[14:53] <hatch> I'll spin up an env and give it a go
[14:53] <rick_h_> hatch: ty
[14:57] <hatch> jujugui call in 3
[14:57] <hatch> rick_h_:  gettin' your hands dirty today I see :)
[14:57] <frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/531 (GUI, big branch, sorry). anyone? thanks a lot!
[14:57] <hatch> frankban: on it
[14:57] <rick_h_> hatch: trying to see if I can code while on calls :)
[14:58] <frankban> hatch: thanks
[14:58] <hatch> frankban:  ermahgerd you wern't kidding....maybe I change my mind? :P
[14:58] <frankban> hatch: heh, hopefully is readable, lots of tests btw, apologies
[14:59] <hatch> rick_h_:  haha should we expect some ' if( foo == well no leankit has much better lane support than trello)  { ugh } 
[14:59] <hatch> :P
[14:59] <rick_h_> hatch: huh?
[14:59] <hatch> typing what you're saying
[14:59] <hatch> sorry that was a horrible exmaple haha
[14:59] <rick_h_> lol
[15:00] <rick_h_> jujuju hung up on a call, feel free to start without me once we get folks in
[15:00] <rick_h_> jujugui
[15:00]  * jrwren_ is singing Call Me!
[15:06] <jcsackett> kadams54: there appear to be legitimate test failures on your branch. :/
[15:10] <kadams54> jcsackett: yeah, I'm fixing it right now, but it's not anything that should impact QA. I need to tack 'MB' onto a string and everything will be happy again :-)
[15:12] <kadams54> jujugui: browser crash, having problems getting back into the hangout now…
[15:13] <jcsackett> kadams54: cool beans. i'll finish my review then.
[15:13] <jcsackett> rick_h_: just double checking, we're skipping todays 1x1 since we effectively had it yesterday, right?
[15:13] <rick_h_> kadams54: how goes your branch in progress
[15:13] <rick_h_> jcsackett: rgr
[15:13] <rick_h_> jcsackett: kadams54 has your spot now :P
[15:13] <rick_h_> so many calls so little time...for lunch
[15:13] <rick_h_> :)
[15:14]  * jcsackett laughs
[15:17] <jrwren_> hatch__: what are you doing with haproxy?
[15:17] <kadams54> rick_h_: mentioned on standup before I dropped… I haven't done much on my in-progress since discussing it in channel yesterday. Circled back to fix the QA issues that jcsackett found in my other PR, but will be working on hiding the text based on your suggestion yesterday.
[15:17] <hatch__> jrwren_:  my ghost charm needs a front end which does cookie sticky sessions, ssl (eventually), load balancing, and url 302 redirecting
[15:17] <rick_h_> kadams54: ok thanks
[15:18] <hatch__> the current recommended haproxy charm is old and doesn't support me providing a custom config file
[15:18] <hatch__> but haproxy.org hasn't been updated in well over a year which is odd, so i have no idea where to look for docs, release notes, etc
[15:19] <jrwren_> hatch__: sounds like a good oportunity to charm it up.
[15:20] <hatch__> jrwren_: right I have to make my own haproxy charm - but I can't find the source of truth for the docs/project
[15:20] <rick_h_> kadams54: jcsackett Makyo can I get a second review please? https://github.com/juju/juju-gui/pull/530
[15:20] <jcsackett> nope.
[15:20] <rick_h_> frankban: looking at yours but might not be done until tomorrow tbh
[15:20] <hatch__> rick_h_:  you can't expose an uncommitted service because we don't show the toggle :) 
[15:20] <jcsackett> rick_h_: if no one else grabs it by the time i'm done with my current set, i'll poke at yours.
[15:20] <rick_h_> hatch__: ah, ok then. I'm ok with it atm
[15:21] <kadams54> rick_h_: taking a look
[15:21] <rick_h_> hatch__: in that way it's not something you can 'uncommit' so it's safe-ish
[15:21] <frankban> rick_h_: thanks, Jeff and Madison are already looking at it FYI
[15:21] <rick_h_> well that you can 'not yet commit' I guess
[15:21] <rick_h_> frankban: ah ok cool
[15:22] <rick_h_> hatch__: for the bookmarks http://kentwilliam.com/articles/rich-drag-and-drop-in-react-js
[15:22] <rick_h_> damned coffeescripot
[15:22] <rick_h_> coffeescript
[15:23] <rick_h_> ty kadams54 
[15:23] <hatch__> rick_h_:  sounds good
[15:24] <hatch__> heh will look at link at lunch
[15:24] <hatch__> lol coffeescript
[15:43] <hatch__> https://pub.dartlang.org/packages/android .....maybe coming? :) 
[15:44] <hatch__> heh unlikely I think their glued to android 
[15:44] <hatch__> er java
[16:10] <hatch__> frankban: ok I've finished the code portion of the review and have one largish issue 
[16:10] <hatch__> mind taking a look at the comments?
[16:13] <hatch> frankban:  hmm I'm not sure I agree that it's any simpler - you had to write all of those noop methods and keep them in sync vs calling one init/render method vs another
[16:15] <frankban> hatch: we still need to call render, and if the interface changes, we have a test that fails, and maintaining that is just adding a dummy method. If we find this is annoying, we can even build the noop view dynamically
[16:17] <frankban> hatch: with the other approach, we should also ensure that each view.method call is noop AFAICT, complicating the real header view implementation
[16:18] <hatch> frankban:  right, but in the init it checks to see if it's a dummy view or not, if it is then it doesn't call a method to add the events. In the render method it checks the same attribute to see if it should call the 'renderDummy' or 'renderFull' cycles
[16:20] <hatch> frankban:  do things like setDroppable get called on the dummy method too?
[16:20] <frankban> hatch: that's ok, we start adding if conditions in init and render, but then we need those in all the other methods, correct? e.g. setDroppable must be a noop if the view is in dummy mode. the same for all the other methods. if that's correct, then in the future we have to remember that each method can be "disabled" when adding new logic, and IMHO this is error prone. and we also need to test methods based on stat
[16:20] <frankban> e. I don't feel it's simpler
[16:21] <hatch> ok I see where you're coming from
[16:21]  * hatch thinks about it some more
[16:21] <frankban> hatch: yes. otherwise my argument is the same, but moved to the caller. we need an if for each time a view method is called
[16:21] <frankban> hatch: the current approach just switches components, and no other imperative stuff is required
[16:22] <frankban> hatch: we have two components implementing the same interface, and we ensure they do implement it with a single test
[16:22] <hatch> the issue now however is that we have to know to test every interaction with the container header in disabled and non disabled mode on every change 
[16:22] <hatch> crap js sucks for this problem
[16:24] <hatch> frankban:  I'm entertaining the idea of having the 'real' view extend the 'dummy' view and having some check that the methods line up....
[16:24] <hatch> not sure how it's possible yet
[16:24]  * hatch wishes for a more featureful language atm 
[16:24] <frankban> hatch: I'd like to avoid inheritance there, and I am not sure I understood what we need to further test re interactions
[16:25] <hatch> yeah inheritance is'nt the best - I'd like an "implements" feature in js
[16:25] <hatch> frankban:  so if joe developer adds a method to the 'real' view, he has to know to go and add it to the dummy as well
[16:25] <hatch> but there is nothing forcing that
[16:25] <hatch> so it could introduce a hidden bug
[16:26] <frankban> hatch: he will know it because he sees a test miserably failing
[16:27] <hatch> but how will the test fail if he didn't know to add one for that functionality?
[16:27] <hatch> oh son-of-a
[16:27] <hatch> I missed the test I was going to ask for
[16:27] <hatch> lol
[16:27] <frankban> hatch: the "implements the machine panel header view interface" ensures the dummy view implements the public interface of the real one. JS type system does not have that, but we can easily work arounf that with a test
[16:27] <hatch> haha yeah I JUST saw that
[16:27] <hatch> oops :)
[16:27] <hatch> so sorry
[16:28] <frankban> np :-)
[16:31] <hatch> +1 to the code, going to drop into qa now
[16:32] <frankban> hatch: thanks a lot
[16:32] <hatch> luckily I have a env already up :)
[16:33] <hatch> frankban:  also....can you edit the initial message to only include the details of the merge and not include the qa steps. GH puts everything in the first message as the merge message and we decided that we would only put the changes made in this message and put the qa instructions in a separate comment
[16:34] <frankban> hatch: sure
[16:35] <frankban> hatch:  done
[16:40] <hatch> frankban:  all done
[16:41] <frankban> hatch: thanks!
[16:41] <frankban> hatch: good to know it is already a bug
[16:41] <hatch> yeah, irritating bug because I thought I fixed all the token icon related bugs :)
[16:42] <frankban> heh
[16:42] <frankban> Makyo: thank you for the review, at this point I'd be inclined to ship it
[16:43] <Makyo> I agree, unless you want another QA.
[16:44] <frankban> rick_h_: do you want me to wait for your review?
[16:44] <hatch> sssshhhhhiiiippppiiiitttttt
[16:44] <hatch> :)
[16:44] <frankban> :-)
[16:44] <rick_h_> frankban: no, I'm sorry. I added a couple of comments but all good
[16:44] <rick_h_> frankban: on my end
[16:45] <frankban> thanks rick_h_ 
[16:45] <frankban> rick_h_: I think the conversation with hatch (above) was around one of your comments too
[16:45] <frankban> shipping it
[16:46] <rick_h_> frankban: yep, I'll catch up the traceback in a bit but trust you guys hashed it out
[16:46] <frankban> rick_h_: great
[16:47] <rick_h_> ty hatch nd kadams54 for the reviews!
[16:48]  * rick_h_ runs and tries to get a lunch in here
[17:17] <hatch> lazyPower: is there any way I can find out who the maintainer of the haproxy charm is and get in touch with him/her? 
[17:19] <rick_h_> hatch: we use it internally, maybe chat in #webops and see if there's a diff charm or anything there?
[17:20] <hatch> rick_h_:  well I'd really prefer the maintainer to update it and add support if possible
[17:20] <hatch> vs me doing through the whole process of learning haproxy
[17:20] <rick_h_> hatch: understoood
[17:21] <rick_h_> but if you're looking for the best charm, and maintained (as we're using it in prod) it's something to keep in mind
[17:21] <hatch> yeah definitely - it probably shouldn't be promoted if it's no longer up to date :)
[17:23] <hatch> I asked there, maybe some luck :)
[18:11] <Makyo> hatch, found the databinding issue, updated pr https://github.com/juju/juju-gui/pull/527
[18:15] <hatch> Makyo:  hah nice find
[18:16] <hatch> I'm just qa'ing my branch atm, will pull yours down again soon
[18:16] <Makyo> Cool, thanks
[18:16] <hatch> Makyo:  also with this https://github.com/hatched/juju-gui/commit/4c38c98e36290555572864f3de527226621d87df we can now actually delete units via the inspector :) 
[18:17] <Makyo> Oh, rock on
[18:17] <hatch> seems we have hit the obscure bug portion of the release lol
[18:18] <Makyo> Yeah, right? :P
[18:20] <rick_h_> kadams54: call running long, will ping when done for 1-1 but not able to jump away any time soon
[18:20] <rick_h_> kadams54: sorry for the mess around that today
[18:22] <jcastro> rick_h_, hey, the use of elasticsearch in the gui
[18:22] <jcastro> does that apply to self hosted versions too or just jujucharms.com?
[18:23] <rick_h_> jcastro: right now it's as long as the gui looks to manage.jujucharms.com
[18:23] <rick_h_> jcastro: that'll move to the new store once we release it
[18:24] <jcastro> ok so  like, each user isn't deploying ES internally right?
[18:24] <jcastro> like, we're not bundling it?
[18:24] <rick_h_> jcastro: correct
[18:24] <jcastro> ack
[18:24] <rick_h_> we're bundling it for our own prodstack needs, but not to each gui deploy or the like
[18:24] <jcastro> ack
[18:30] <hatch> Makyo:  ok doing your qa
[18:33] <hatch> Makyo:  am I supposed to be able to click the 'delete' button in the mv still?
[18:33] <hatch> Makyo:  sorry another qa issue, added to pr
[18:35] <Makyo> hatch, can't reproduce.  And what delete button?
[18:35] <hatch> says "Remove" sorry
[18:36] <hatch> in the unplaced unit tokens more menu
[18:36] <Makyo> Yeah, I can't reproduce that.
[18:36] <hatch> hmm
[18:36] <hatch> can you make sure you have develop updated?
[18:38] <Makyo> For pete's sake >:/
[18:38] <Makyo> Why the hell was env removed?
[18:38] <Makyo> Attrs are there for a reason.
[18:39] <hatch> Makyo:  looks like we both missed it in the review :/ https://github.com/juju/juju-gui/pull/531/files#diff-68c965ef8aa2aaad942d780b3b1cf450L413
[18:40] <Makyo> Oh crap, you're right.  I thought that was cleanup.
[18:41] <Makyo> Let me see if I can get that back in.  Sorry if the merge screws up my ability to rebase.
[18:50] <kadams54> hatch: yesterday you mentioned an event being fired when a service was added to the changeset… I see a changeSetModified event, but that's not specific to services being added.
[18:52] <hatch> when a service gets added to the canvas 
[18:52] <hatch> is handled differently than when it's clicked on once on the canvas
[18:54] <Makyo> hatch, alright, now try
[18:54] <Makyo> Sorry for the mixup
[18:54] <kadams54> hatch: what code should I be looking through for that?
[18:54] <kadams54> topology?
[18:54] <hatch> kadams54: yeah the topology/service.js
[18:54]  * rick_h_ hears a ripping noise as the headphone come off
[18:55] <hatch> for once it's already landed
[18:55] <rick_h_> kadams54: I'm free now whenever you are. Just ping and we'll do this thing
[18:55] <hatch> Makyo:  ok looking
[18:55] <hatch> rick_h_:  can you explain to kadams54 about your idea wrt the different ways the inspector opens
[18:55] <hatch> just trying to get to lunch :D
[18:56] <rick_h_> hatch: okie dokie
[18:56] <hatch> Makyo:  did you want to add a 'remove' button to the inspector for uncommitted units section? probably a follow-up hey?
[18:57] <hatch> rick_h_:  thx
[18:57] <kadams54> hatch, rick_h_: I think I have the general idea in mind… display the help message when the inspector is opened by adding a service to the canvas. Hide it otherwise.
[18:58] <kadams54> rick_h_: ready
[18:58] <rick_h_> kadams54: ok, in the room
[18:58]  * hatch runs away for lunch
[19:00] <Makyo> hatch, yeah, follow up
[19:34] <lazyPower> hatch: just wrapped validation on 3 ot 6 substrates and I'm not seeing that behavior from the MySQL charm
[19:35] <lazyPower> hatch: if you can reproduce it, can you attach the steps you took to reproduce the behavior you're seeing?
[19:35] <hatch> was one of those ec2? What version of Juju?
[19:35] <lazyPower> hatch: http://paste.ubuntu.com/8252799/
[19:35] <lazyPower> 1.20.7, and yes EC2, LXC, and MAAS
[19:36] <hatch> ok I'm on 1.20.6-trusty
[19:36] <hatch> lemme try again
[19:37] <hatch> lazyPower:  it'll take a bit, I'll report back
[19:37] <lazyPower> hatch: feel free to ping me if you see teh same behavior - I'll want to look at your deployment command history so i can verify on my end.
[19:38] <hatch> lazyPower:  I'm just doing `juju bootstrap` `juju deploy mysql` 
[19:38] <hatch> so we'll see
[19:38] <lazyPower> ack
[19:45] <hatch> lazyPower: umm ok it worked fine
[19:45] <hatch> lazyPower: I'll now do what I was doing yesterday, using the GUI and whatnot
[19:46] <lazyPower> hatch: not sure why you saw a nothing in there, it may be a response it was expecting that it didn't receive... but if its working thats a step in the right direction, if you can find the missing link I'll be happy to try and verify the bug on my end.
[19:46] <lazyPower> holy run-on batman... 
[19:47] <hatch> yeah I don't get it, I did those exact steps yesterday and it failed multiple times
[19:47]  * lazyPower goes back to code, where run-ons are denoted by 80col rules.
[19:47] <hatch> unless maybe a keyserver was down or something?
[20:09] <hatch> lazyPower:  ok I have reproduced it
[20:09] <hatch> *phew*
[20:10] <hatch> :)
[20:10] <hatch> I'll outline the somewhat numerous steps I took
[20:10] <lazyPower> hatch: can you update the bug with steps to reproduce? I'll run down what you've done so i can confirm the bug.
[20:16] <hatch> lazyPower:  ok added, sorry about the # of steps :) 
[20:16] <hatch> ahead of time
[20:16] <hatch> heh
[20:16] <hatch> lazyPower:  I also still have the env up if you want to see it
[20:17] <lazyPower> hatch: can you attach the output of juju run --service mysql 'config-get'?
[20:18] <hatch> done
[20:18] <hatch> any other tasks? :)
[20:19] <hatch> lazyPower:  I also added the mysql portion of the juju status
[20:20] <hatch> lazyPower: hmm, my local is 1.20.6 but it says the mysql one is 1.20.7 could that cause the issue?
[20:21] <jcsackett> rick_h_: do you have any of the login information for the jenkins instance running charmworld autoland?
[20:22] <rick_h_> jcsackett: no, that's run by QA. I think brad might have had some access. Might need to ping abentley or sinzui
[20:22] <jcsackett> rick_h_: i've pinged sinzui as well.
[20:53] <abentley> jcsackett: Here are the docs about the charmworld lander that I wrote up when we handed it off to your team https://docs.google.com/a/canonical.com/document/d/1IH_a8evtcbJ_bcF2m0SmcvWEO1dT_R6zpjYpp6M_sRU/edit#heading=h.e2vmlmlyb2x0
[20:53] <jcsackett> abentley: fantastic! thanks.
[20:54]  * jcsackett stars that document
[21:11]  * rick_h_ walks away for a little bit until the AU calls, biab
[21:32] <hatch> rick_h_:  looks like all my issues with mysql charm yesterday were actually caused by the GUI :O
[21:39] <hatch> rick_h_:  https://bugs.launchpad.net/juju-gui/+bug/1365205 it's a pretty high priority one blocking release 
[21:39] <mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <juju-gui:New> <mysql (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1365205>
[22:00] <rick_h_> hatch: rgr thanks for the heads up
[22:00] <hatch> it's pretty obscure hah
[22:00] <hatch> glad it happened to me lol
[22:00] <rick_h_> yea, no kidding
[22:01] <rick_h_> jujugui no AU call tonight. huw called in sick
[22:01] <rick_h_> reminds me, jcsackett did you file that?
[22:01] <hatch> alrighty thanks
[22:01] <jcsackett> rick_h_: no, i did not. thanks for the reminder.
[22:01]  * jcsackett goes to hr site
[22:02] <jcsackett> rick_h_: done.
[22:02] <rick_h_> jcsackett: rgr ty
[22:03] <rick_h_> jujugui made hatch's bug up in urgent. When grabbing next available card please tackle next
[22:03] <rick_h_> and bug hatch for details/info
[22:03] <rick_h_> :)
[22:03] <hatch> haha yes plz do (although I'm coming up on needing a next card)
[22:09] <hatch> jujugui lf reviews https://github.com/juju/juju-gui/pull/532 (covers two cards)
[22:12] <rick_h_> hatch: I might try to look when I come back later to finish emails for the day but brain fried atm
[22:15] <hatch> sure np
[22:15] <rick_h_> hatch: good news is first call tomorrow is 10am so might get to look at it before you start either way
[22:15] <hatch> haha yay