[00:01] <hatch> later though
[00:01] <huwshimi> np
[02:08] <hatch> huwshimi: you have been doing a lot js lately :P
[02:16] <hatch> huwshimi: code looks good and it tests good on sandbox - i am just going to do the qa in a real env now
[02:17] <huwshimi> Thanks!
[02:55] <hatch> huwshimi: shipppit
[02:56] <huwshimi> hatch: Thanks!
[03:01] <hatch> Makyo: you in?
[03:21] <hatch> huwshimi: so my blog post seems to have taken off....almost at 2000 views today
[03:22] <huwshimi> hatch: Woah, nice!
[03:23] <hatch> lol yup, because of that I should hit 50,000 pageviews for the year tonight
[03:23] <hatch> I kind of wish I had something worth while to say haha
[03:24] <hatch> I just started downloading Divinity Original Sin...at the current rate it'll be morning before it's done :(
[03:27] <huwshimi> hatch: I was thinking you could do another post about what things you can actually do with juju, e.g. deploy any service, with no install/config knowledge, scale, redeploy, redeploy on another cloud, swap out a service etc.
[03:28] <huwshimi> Would be a pretty good way of explaining juju
[03:28] <hatch> yeah that would make a good follow-up wouldn't it
[07:40] <rogpeppe> mornin' all
[11:16]  * frankban lunches
[12:19] <bac> hi jcastro
[12:23] <rick_h_> bac: heh ruh roh
[12:23] <bac> hi rick_h_.  what you talking 'bout?
[12:24] <rick_h_> bac: your email on the config proof stuff
[12:24] <rick_h_> I'm tring to recall a config issue with those a while ago
[12:24] <rick_h_> but ignore me for now, it looks like I'm recalling a diff config issue/debate
[12:25] <bac> rick_h_: yeah, i'm not sure if the default being required is new but it isn't working as is.
[12:26] <bac> like i said, even if you explicitly say "default: null" the tool issues a warning
[12:26] <rick_h_> right
[13:04] <jcsackett> Morning jujugui. 
[13:04] <bac> hey jcsackett
[13:04] <urulama> hey there jcsackett
[13:04] <jcsackett> Anyone have info about the "clear config-changed entries" card? Is that part of the clear all changes interaction?
[13:07] <jcsackett> rick_h_ ^
[13:11] <rick_h_> jcsackett: yes, conbined with config changed on a service that's not yet committed
[13:11] <rick_h_> jcsackett: it needs the work hatch was working on
[13:12] <rick_h_> jcsackett: I think the two cards to look at from here for you might be the remove relation UX (kind of done but little more I think) or the bundle export work
[13:13] <rick_h_> jcsackett: let me know if you want to chat on either of those
[13:13] <rick_h_> the others I'd like to sync with Makyo and hatch and make sure we have those stacked in the right order 
[13:13] <rick_h_> frankban: do you have time to chat?
[13:14] <frankban> rick_h_: I do
[13:14] <rick_h_> frankban: standup hangout?
[13:29] <jcsackett> rick_h_ bundle stuff is just about updating bundles to handle n+ services on one machine? Or capturing the whole machine setup as part of the bundle?
[13:30] <jcsackett> I can talk on IRC, but my connection in phone is too crap for hangout. (1 bar)
[13:33] <rick_h_> jcsackett: the idea is to look at the bundle syntax, it allows for specifying colocated services and machines (only new ones) 
[13:34] <jcsackett> Bundle syntax == deployer syntax, right?
[13:34] <rick_h_> jcsackett: so in theory, we can express a custom machine view layout in a bundle syntax. So the first card is to investigate the deployer/bundle syntax and to make a plan to update our bundle export to match
[13:34] <jcsackett> rick_h_ ok, I can start running with that. 
[13:34] <rick_h_> jcsackett: yes, make sure to match up with the bundle ideas in the updated charmstore as well. I'll make sure to share out the bundle doc your way
[13:35] <jcsackett> rick_h_ ok. 
[13:35] <rick_h_> jcsackett: sent
[13:35] <jcsackett> rick_h_ And received. 
[13:37] <kadams54> Changing locations, will back back shortly
[13:58] <rick_h_> jujugui looks like 4 cards in review atm. Please check if you can help with any of those.
[14:04] <rick_h_> luca__: I'm confooosed pls help
[14:05] <luca__> rick_h_: ok, whats up?
[14:05] <rick_h_> luca__: the onboarding, we don't have a commit button. I understand the onboarding the first time you do something that 'enables the button' 
[14:06] <luca__> rick_h_:  we do have a commit button
[14:06] <rick_h_> luca__: but the second one I just don't get. If you click on the 'deploy' button you get a giant screen
[14:06] <rick_h_> and that's 'confirm'
[14:06] <rick_h_> luca__: so maybe we're missing some updates then to match design?
[14:06] <luca__> rick_h_: want to have a call to clear this up?
[14:06] <rick_h_> luca__: or have I not had enough coffee today?
[14:06] <rick_h_> luca__: sure thing
[14:07] <luca__> ping me a link :)
[14:07] <rick_h_> cheater
[14:07] <rick_h_> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[14:07] <aisrael> I'm getting an error while bootstrapping the juju-gui. https://pastebin.canonical.com/116651/
[14:07] <rick_h_> aisrael: looking
[14:07] <aisrael> Looks like a missing dependency. It's looking for 'concurrent', but the closest package I can find is concurrency
[14:08] <rick_h_> aisrael: hmm, background info? It should be going out to pypi unless you mess with dev mode/etc
[14:10] <aisrael> rick_h_: upping a vagrant image and running the provisioner
[14:11] <kadams54> rick_h_: just noticed that you were talking about luca with the onboarding for the commit button…
[14:11] <frankban> aisrael: do you have the whole debug-log output?
[14:13] <aisrael> frankban: I can get you the juju-setup.log once it's finished. Is there another log that'd be useful?
[14:15] <frankban> aisrael: the unit log, it should be placed in /var/log/juju/
[14:17] <aisrael> juju-setup.log: https://pastebin.canonical.com/116656/
[14:17] <aisrael> unit-juju-gui-0.log: https://pastebin.canonical.com/116657/
[14:21] <rick_h_> kadams54: yes, we've got some UX updates and onboarding to create cards for and we had to hash it out
[14:21] <frankban> aisrael: from the logs it seems to me the juju-gui charm is being deployed correctly
[14:21] <rick_h_> frankban: aisrael that package is long gone https://pypi.python.org/pypi?%3Aaction=search&term=concurrent&submit=search it appears
[14:21] <kadams54> rick_h_: I'm getting ready to start work on one of those cards I think… the onboarding for the commit button…
[14:21] <rick_h_> kadams54: do we have a card yet? 
[14:22] <kadams54> rick_h_: Yeah
[14:22]  * rick_h_ is blind, where is the card for it?
[14:22] <kadams54> Look in the in progress column
[14:22] <kadams54> Project 1
[14:22] <kadams54> Er, the Code column
[14:22] <kadams54> Deployment bar onboarding (see desc)
[14:22] <rick_h_> oh, deployment bar onboarding gotcha
[14:22] <kadams54> http://goo.gl/kwnJhD
[14:22] <rick_h_> yes, ok let's chat
[14:22] <rick_h_> kadams54: standup hangout pleaase?
[14:23] <kadams54> OK
[14:23] <rick_h_> sorry, was looking for the wrong words I am blind today
[14:24] <rick_h_> frankban: aisrael doh, that's the futures package, not concurrent oh wtf 
[14:24] <frankban> rick_h_: yes the package is called futures. 
[14:25] <frankban> aisrael: I am not sure about what script generates the juju-setup.log log file
[14:25] <kadams54> rick_h_: Hangouts seems to hate me right now? Just sitting with a "Please wait" message.
[14:25] <rick_h_> kadams54: k
[14:26] <frankban> rick_h_: do you know where is the source of this vagrant+gui setup?
[14:26] <rick_h_> frankban: sec, I got some links in that bug about deploying gui the other day
[14:26] <rick_h_> frankban: otp atm will look
[14:27] <aisrael> frankban: https://launchpad.net/jujuredirector/quickstart
[14:29] <frankban> rick_h_, aisrael: http://bazaar.launchpad.net/~utlemming/jujuredirector/trunk/view/head:/setup-juju.sh#L42 seems wrong, it should be pip install futures
[14:30] <rick_h_> frankban: aisrael +1
[14:30] <rick_h_> as noted there's no concurrent
[14:30] <rick_h_> frankban: aisrael looks like that was in rev #1 of that so it's been that way for a long time
[14:31] <rick_h_> frankban: aisrael so I'd also assume that if it 'appears' broken now there might be something else where
[14:32] <aisrael> rick_h_: ok, I'll continue to triage.
[14:32] <rick_h_> aisrael: I think that's worth a bug/fix though in the director stuff 
[14:32] <rick_h_> aisrael: let us know if we can help
[14:32] <frankban> aisrael: rick_h_: since we don't maintain the vragrant redirector, maybe it's better to chat with utlemming in #juju
[14:33] <rick_h_> frankban: yea, I know he's been handing it off and such. I just mean if aisrael needs help reading any of our logs/etc. 
[14:33] <aisrael> rick_h_: ack, I'll do a MP against the redirector
[14:33] <rick_h_> ty
[14:33] <frankban> aisrael: thanks!
[14:36] <kadams54> rick_h_: I also took a look at https://bugs.launchpad.net/juju-gui/+bug/1364956 and the associated card
[14:36] <mup> Bug #1364956: Removing a unit via the inspector creates a sticky remove unit command in the deployer bar <juju-gui:Triaged> <https://launchpad.net/bugs/1364956>
[14:37] <kadams54> Per hatch's comments, the bug seems to be fixed.
[14:37] <bac> hi rick_h_, when you have a chance would you approve my request for friday afternoon?
[14:37] <rick_h_> bac: sure thing
[14:37]  * rick_h_ opens pagfe
[14:38] <rick_h_> bac done
[14:38] <bac> thanks
[14:38] <bac> dumb system put it in duplicate to start...
[14:38] <hazmat> rick_h_, i hear containers won't work in machine view?
[14:39] <rick_h_> hazmat: only in MAASA
[14:39] <rick_h_> MAAS
[14:39] <rick_h_> hazmat: and will be enabled (works in the code) for ec2 once juju releases network addressibility for containers on ec2
[14:39] <hazmat> rick_h_, i'm not sure we should enforce that limitation in the gui
[14:40] <hazmat> rick_h_, ie. i've got charms that address this by just deploying a container overlay network with out support for core
[14:40] <rick_h_> hazmat: I'm very hesitent of the bug reports due to networking issues to those container
[14:40] <rick_h_> hazmat: I saw that and it's interesting, but I'm thinking of the ootb GUI user use case
[14:40] <hazmat> rick_h_, log warning to the user
[14:40] <rick_h_> hazmat: since advances users can do this via the cli
[14:40] <hazmat> rick_h_, or at the very least have a flag that enables it
[14:40] <rick_h_> hazmat: right, but then we have to warn based on what the charm does, how many of them there are, which things are exposed/not/etc
[14:40] <hazmat> rick_h_, demo for advanced cases is the gui.. let's not cripple it
[14:40] <rick_h_> hazmat: we can look into a flag for it
[14:41] <hazmat> rick_h_, ie. let advanced users use the gui as well via flag
[14:41] <hazmat> cool
[14:41] <rick_h_> hazmat: +1 will look at a flag
[14:42] <hatch> hazmat: the real fix is to quickly do a juju release which adds support :)
[14:43] <hazmat> hatch some of us like to live in the real world and have perfectly good workarounds for storage, networking, provisioning to deliver value today.. iotw we can't hold our breath.
[14:44] <hatch> haha...the real world sucks....I don't care what that Paramore song says
[14:46] <frankban> rick_h_: a config flag to enable all known containers everywhere seems reasonable, defaulting to false in the config and the gui charm
[14:53] <hatch> This is the song I was talking about https://play.google.com/music/m/Tzf7d2wsb3eqgosyy34ob2nhzha
[14:53] <rick_h_> frankban: +1 
[14:54] <rick_h_> jujugui call in 6
[14:54] <hatch> woah already
[14:54] <rick_h_> time flies when you're...
[14:55] <hatch> living in the real world?
[14:55] <hatch> :P 
[14:59] <rick_h_> jujugui call in 1 go go go
[14:59] <rick_h_> ant__: ^ ?
[15:22] <rick_h_> luca__: ! I needs you again :) We need visuals on the 'a commit is in progress' stuff that you showed up in london
[15:23] <rick_h_> can our dear old pal spencer help us out with that? 
[15:23]  * rick_h_ checks the folder of visuals to see if it might already be there.
[15:24] <rick_h_> grrr kadams come back!
[15:24] <hatch> lol he has the worst internet
[15:25] <hatch> or he frequenly 
[15:25] <hatch> just closes his computer haha
[15:25] <rick_h_> well he was out of the house today at a co-working space or something
[15:25] <rick_h_> and seems like they've got crappy internet for a co-working space
[15:25] <hatch> oh.....best place to have crappy internet haha
[15:35] <frankban> jcsackett: reviewed
[15:36] <jcsackett> frankban: thanks.
[15:51] <frankban> rick_h_: it seems that andreas completed his packaging work, which patching the relevant parts of websocket-client and publishing to his own PPAs. Do you want me to try to reuse those packages for quickstart and eventually move them to the juju stable PPA? precise would be also supported in that case
[15:51] <frankban> s/which patching/which includes patching
[15:53] <rick_h_> frankban: what did he do with the six package though?
[15:53] <rick_h_> frankban: I'm nervous about those packages if the six ones are involved with precise
[15:54] <frankban> rick_h_: it's in his last email, it seems it patched websocket-client to not require the newer six version (or at least it seems like one of the patch has that goal)
[15:54] <rick_h_> frankban: oh ok. /me has been on calls and not seen email
[15:56] <rick_h_> frankban: I'm on calls for the next bit. Can you sanity check the diff?
[15:56] <rick_h_> if it seems ok I guess I'd rather we work together so we can reuse his work
[15:56] <rick_h_> just want to make sure we do it safely as a lot of people run that juju stable ppa
[15:57] <frankban> rick_h_: sure
[16:01] <luca__> rick_h_: hey, was afk
[16:23] <hatch> jcsackett: think you have a moment to qa my branch?
[16:24] <jcsackett> hatch: i had to fix my lxc stuff so i can qa against a real env, but yes, i'm starting now.
[16:24] <hatch> cool thanks
[16:29] <hatch> ugh reddit people.....seriously
[16:29] <hatch> I think people just type to look stupid, like it's some kind of game
[16:50] <jcsackett> has anyone noticed a slow down in lxc deployments? i've been sitting at pending for half an hour or so for deploying the GUI. that doesn't seem right.
[16:51] <hatch> jcsackett: definitely not heh
[16:51] <hatch> maybe 15mins
[16:51] <hatch> but my lxc has always been slow for some reason
[16:51] <hatch> haven't looked into it
[16:53] <jcsackett> ok, but your "slow" lxc is 15 min, and i'm *way* past that.
[16:53] <jcsackett> dammit.
[16:53] <hatch> yeah....is the machine provisioned?
[16:53] <hatch> if so you can probably check the logs to see if its hung on npm or something
[16:54] <rick_h_> jcsackett: there's some known lxc bugs around these days
[16:54] <rick_h_> jcsackett: watch out what version of juju you're on and such
[16:54] <jcsackett> rick_h_: oh goodie.
[16:54] <jcsackett> thanks. :p
[16:54] <rick_h_> jcsackett: ec2 or azure or something are good options as well
[16:55] <rick_h_> jcsackett: especially with quickstart to get it on one machine
[16:55] <jcsackett> rick_h_: yeah, i was avoiding ec2 b/c it's slower and i wanted to get hatch's QA done...but since lxc is being peculiar, i think ec2 is probably the best bet.
[16:55] <jcsackett> hatch, sorry this is taking so long.
[16:56] <hatch> np
[16:56] <hatch> Im just sitting here rocking out
[16:56] <hatch> if I had some glowsticks and e it might turn into a rave
[16:56]  * rick_h_ steps away for lunchables
[16:57]  * jcsackett laughs
[16:57] <hatch> haha
[17:01] <jcsackett> what the hell, my ec2 stuff no longer works.
[17:03] <jcsackett> hrm; amazon is telling me about some IAM user thing i'm supposed to use now, and that we can't retrieve secret-keys anymore...has anyone else hit oddities around that?
[17:04] <hatch> oh that's odd
[17:04] <hatch> nope never
[17:06] <jcsackett> huh; looks like my old key was revoked by amazon as "insecure". generating new ones worked.
[17:06] <jcsackett> that's...weird.
[17:06] <jcsackett> i wonder what criteria they use to determine that.
[17:06] <jcsackett> b/c if someone else used them...i would really like to know that. :p
[17:06] <hatch> ohh right I've seen that - i had some which weren't used in a while so they revokedc them
[17:15] <rick_h_> jcsackett: yea, they changed how they work a while ago (year?) and you have to migrate to the new system
[17:15] <jcsackett> rick_h_: so why did ec2 work for me last month w/o changes? :p
[17:15] <rick_h_> jcsackett: because they've been providing a warning for months you've ignored? 
[17:15] <jcsackett> and juju still works off the secretkey/accesskey thing, doesn't it?
[17:16] <jcsackett> rick_h_: that's probably true. :p
[17:16] <rick_h_> helpful I know :)
[17:16] <jcsackett> rick_h_: anyway, making a new key worked. let's hope they don't randomly delete it on me again. :p
[17:20] <hatch> updated 
[17:20] <hatch> the attribut name
[17:20] <hatch> bleh I still aren't that good with this keyboard haha
[17:31] <hatch> jcsackett: got everything spinning up now?
[17:31] <jcsackett> hatch: coming up on ec2 yes, though gui just threw an install hook error.
[17:31] <hatch> make sure you're on trusty
[17:31] <hatch> :)
[17:32] <hatch> https://github.com/hatched/juju-gui.git remote-config
[17:32] <hatch> tha;ts the source string that you should use
[17:34] <jcsackett> hatch: yeah, it's not crapping out on that.
[17:36] <jcsackett> hatch: incidentally, you can get custom gui-source to work on precise if you use the @sha syntax rather then the branchname syntax.
[17:36] <jcsackett> like source="https://github.com/someuser/somerepo.git @12345..."
[17:38] <hatch> oh hinteresting i never did that before
[17:57] <rick_h_> jujugui added 3 new cards around the multiple changeset idea. It might need to break down farther, but can start here. Let me know if you have any questions or such.
[17:57] <rick_h_> I've emailed for visuals, but we can get started on the back end without
[17:57] <Makyo> rick_h_, cool, thanks
[18:26] <jcsackett> hatch: so, i resolved the install hook issue by way of just redoing deployment, and it's sitting at pending forever. again.
[18:26] <jcsackett> hatch: i can keep waiting, but i'm not entirely sure what's up.
[18:27] <rick_h_> jcsackett: check the log on the unit
[18:27] <rick_h_> juju ssh juju-gui/0
[18:27] <hatch> jcsackett:  ok I think I'll just shippit then so I can continue on this string of cards
[18:27] <rick_h_> tail /var/log/juju/unit-<tab>
[18:27] <jcsackett> huh. looks like it's progressing, just *really* slowly.
[18:28] <rick_h_> it might take some 15min to change sources
[18:28] <hatch> oh ok well I'll go get lunch now then
[18:28] <jcsackett> rick_h_: huh. feel like we're past 15min, but ok.
[18:28] <jcsackett> hatch: good plan.
[18:45] <Makyo> jujugui going to duck out over lunch and see about a haircut
[18:51] <rick_h_> jujugui /me is going afk until the meetings tonight. If you need anything email or hit me up on hangouts
[19:09] <jcsackett> hatch: qa notes up on your PR, *finally*; all looked good, though i encountered oddities i think later work aims to resolve.
[19:09] <hatch> yeah thanks yes there is a bug already for that
[19:09] <hatch> i believe it has madisons head on it
[19:11] <jcsackett> hatch: not sure of that, but we'll hold off on analysis until Makyo's work is WIP at least--i may not really understand the bug.
[19:11] <jcsackett> seems to just be about asterisk vs circle, whereas this also had oddities about commit being available when it shouldn't and commiting changes that were discarded.
[19:11] <jcsackett> happens in develop too, though, so not your branch.
[19:12] <hatch> jcsackett: tbh the conflict resolution is a pretty complex bag the changes that I've made don't actually touch any of that code
[19:12] <hatch> right
[19:26] <jcsackett> rick_h_: how did you mean "match up with bundle ideas in new charmstore" for this bundle export thing? something that matches up with the new charmstore spec won't work with the current deployer.
[20:33] <rick_h_> jcsackett: well the deployer allows for specifying services to be colocated 
[20:34] <rick_h_> jcsackett: and I'm trying to recall if the machine stuff works atm or not
[20:34] <rick_h_> jcsackett: I guess let's run through them when you have a sec
[20:43] <jcsackett> rick_h_: give me just a moment and i can chat, if you like.
[20:46] <hatch> jujugui is there a util method somewhere for getting the ghost id from a display name?
[20:47] <Makyo> hatch, don't think so
[20:50] <hatch> Makyo: 
[20:50] <hatch> ok thanks
[20:50] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1367921
[20:50] <mup> Bug #1367921: Setting the config of a ghost service causes the deployer bar to throw an error. <juju-gui:New> <https://launchpad.net/bugs/1367921>
[20:50] <hatch> ^ rick_h_
[20:50] <jcsackett> rick_h_: free when you are.
[20:56] <rick_h_> jcsackett: ok standup
[20:56] <rick_h_> hatch: how dare you file bugs!
[20:56] <hatch> well if we would just stop writing them into the code I wouldn';t have to!!!!!
[20:56] <rick_h_> hey, don't look at me :P
[20:56] <hatch> lol
[21:31] <hatch> hey I think fabrice is doing a js talk tomorrow at a conf
[21:32] <rick_h_> hatch: cool!
[21:32] <hatch> https://twitter.com/briancavalier/status/509815485555564544
[21:32] <hatch> that's his twitter right?
[21:33] <rick_h_> fabricematrat yep
[21:34] <hatch> man this world is too small lol
[21:35] <hatch> some random i follow from yui world just happens to be going to a talk with a new guy on the team haha
[21:54] <hatch> ears must have been burning
[22:41] <hatch> jujugui I need some quick reviews and sandbox qa's https://github.com/juju/juju-gui/pull/542
[22:42] <Makyo> hatch, on it
[22:43] <hatch> thanks
[22:50] <hatch> rick_h_: it seems like the core guys are liking reviewboard....any idea what feature rb has that isn't as good on github? 
[22:51] <hatch> jujugui any others for a review? it's just a quicky :)
[23:01] <huwshimi> Morning
[23:07] <hatch> hey huwshimi
[23:14] <hatch> huwshimi:  wana do a review? https://github.com/juju/juju-gui/pull/542
[23:21] <huwshimi> hatch: So "case '_set_config':" get's called for each service?
[23:21] <huwshimi> (somewhere else)
[23:22] <hatch> huwshimi:  basically this is 'unwinding' the ecs working backwards to clear it out
[23:22] <hatch> so it only gets called if there is an ecs record for set config
[23:23] <rick_h_> hatch: the thing with reviewboard is the process
[23:23] <rick_h_> it's another tool, it doesn't integrate well, the history is harder to work with, etc
[23:23] <rick_h_> hatch: we've got a card to look at it on friday
[23:23] <rick_h_> hatch: well talk about it
[23:24] <hatch> yeah when I was playing wth it I didn't really see why one would switch to it over GH besides maybe getting less email :)
[23:24] <hatch> I thought maybe I was missing something
[23:24] <rick_h_> hatch: well it lets you do things like reviews dependant on another
[23:24] <rick_h_> they do a lot of chain branches
[23:24] <rick_h_> they can't land but every few days it seems
[23:24] <rick_h_> so they stack up 4 or 5 branches that chain together
[23:24] <rick_h_> and get reviews started/etc
[23:25] <rick_h_> and reviewboard does a lot better with the review history
[23:25] <rick_h_> makes it easier to see what changed from update to update and the like
[23:25] <hatch> ohh....that sounds like a dangerous process lol
[23:25] <rick_h_> and GH JUST got side by side diffs
[23:25] <rick_h_> so this started a bit ago
[23:25] <hatch> yeah...I'm over side by side diffs now, I actually prefer inline haha
[23:26] <hatch> just as they got it I no longer want it lol
[23:26] <rick_h_> but yes, I setup a test reviewboard instance, I tried to work it into our flow, and had a chat with the reviewboard folks over holes in their workflows vs ours
[23:26] <rick_h_> heh, yea same here. After years of inline diffs on launchpad the side by side was nice but not killer
[23:27] <huwshimi> hatch: all good +1
[23:27] <hatch> thanks done
[23:29] <huwshimi> hatch: Did you have any ideas about how to know when things are in a pending state?
[23:30] <huwshimi> (for commit in progress)
[23:30] <rick_h_> yes as he worked on it :P
[23:33] <hatch> huwshimi: do you mean uncommitted?
[23:34] <hatch> or between uncommitted and committed?
[23:34] <hatch> or pending pending
[23:34] <hatch> :) 
[23:34] <rick_h_> hatch: he means the card about chaning the icon to yellow while it's in progress
[23:34] <hatch> ohh
[23:34] <huwshimi> hatch: I mean, between when you click commit and the change taking affect.
[23:35] <hatch> lemme open some code....sec
[23:36] <hatch> huwshimi: https://github.com/juju/juju-gui/blob/develop/app/utils/environment-change-set.js#L188
[23:36] <hatch> this fn gets called just before the callback for each env call
[23:37] <huwshimi> hatch: Once the commit is complete?
[23:37] <hatch> this is called for every call
[23:37] <hatch> it wraps the callback you sent in during your env call
[23:37] <hatch> so the question is...do we want to do somethin gjust for machines, or for everything
[23:39] <hatch> so what I mean is that there is nothing that says 'I have sent this to juju, but juju hasn't ack'd yet"
[23:39] <hatch> so you need to signify the start of the commit execution to trigger the ui change
[23:39] <hatch> then use this callback to turn it off
[23:40] <hatch> we are essentially adding another state to the models
[23:40] <huwshimi> yeah
[23:40] <huwshimi> a "pending commit" state
[23:42] <huwshimi> hatch: I think that card is probably beyond me then...
[23:45] <hatch> huwshimi: well it definitely should be a couple branches
[23:47] <hatch> if you wanted to learn about how the ecs stuff works you could tackle it :)
[23:47] <hatch> the ecs stuff is easy to step through, just lots of steps heh
[23:48] <hatch> buuut none the less I think there are quite a few other cards