[01:03] <rick_h_> huwshimi: review in, thanks for the great stuff
[01:39] <rick_h_> hatch: you do your blog post?
[06:19] <fabrice> morning
[09:27] <luca__> Hi urulama 
[09:27] <luca__> Rick said I can make some cards on the Juju GUI kanban
[09:28] <luca__> do you know which column I should put them on?
[09:31] <fabrice_> luca__: I suppose I would put them under ready to code 
[09:32] <luca__> thanks fabrice_ 
[09:32] <luca__> I’ll add them there
[09:32] <luca__> rick can move them if need be
[09:34] <fabrice_> luca__: he will be there in 90 minutes most likely so you can check with him
[09:35] <luca__> thanks :)
[09:46] <urulama> luca__: hey, was otp
[09:46] <luca__> urulama: no worries
[09:46] <luca__> urulama: I have added them now
[09:47]  * urulama gets worried :D
[09:48] <urulama> luca__: where did you put it?
[09:48] <luca__> ready to code in the urgent section
[09:50] <urulama> luca__: oh, robin will be happy :)
[09:50] <luca__> urulama: haha, he’s sitting near me. He’s on it :)
[09:54] <frankban> marcoceppi: morning, any idea about why I get "ssh: connect to host 10.89.138.144 port 22: Connection refused" from ec2 when running juju-test? the same environment works when bootstrapped directly
[09:55] <marcoceppi> frankban: what flags were passed?
[09:55] <luca__> urulama: I just made the Urgent section of ready to code go red!
[09:55] <luca__> urulama: rick_h_ is not going to be happy with me
[09:55] <luca__> lol
[09:55] <frankban> marcoceppi: yes | juju-test --timeout=60m -v -e "ec2-precise" 20-functional.test
[09:56] <urulama> luca__: that is a great good morning welcome!
[09:56] <marcoceppi> frankban: so, I need to check if juju test is still making an isolated environment, if so you'll need to reset your JUJU_HOME to access the environment
[09:57] <frankban> marcoceppi: reset my juju-home?
[09:57] <marcoceppi> frankban: not reset, sorry, override
[09:58] <marcoceppi> juju-test, used to, create an isolated JUJU_HOME from the users, copy over the credentials for just that environment and bootstrap from it. This way we didn't polute people's JUJU_HOME. This was fine until juju started creating it's own SSH keys
[09:59] <marcoceppi> actually, we're not doing that anymore, good
[09:59] <marcoceppi> hum. Why can't you access it
[09:59] <frankban> marcoceppi: the weird stuff is that it worked since yesterday or a couple of days ago. btw this is the full output: http://pastebin.ubuntu.com/8464993/
[10:00] <marcoceppi> frankban: could it just be that the instance took too long to come online?
[10:02] <frankban> marcoceppi: tried several times, trying again
[10:03] <marcoceppi> it's weird that it's listing the internal IP address. I mean, nothing has changed in juju-test in months
[10:03] <frankban> marcoceppi: I don't exclude this can be some oddity on my local configuration, it's just weird that it works when the environment is bootstrapped manually
[10:03] <marcoceppi> frankban: that is totally werid
[10:04] <marcoceppi> the bootstrap command is literally a Popen to juju bootstrap
[10:04] <frankban> marcoceppi: yeah I know that
[10:05]  * marcoceppi scratches head and wakes up a bit more
[10:21] <frankban> marcoceppi: uhm, same error, Connection refused
[10:27]  * frankban bbiab
[11:42] <rick_h_> luca__: hah
[11:42]  * luca__ starts hiding up his desk
[11:46] <rick_h_> frankban: need me to test something out to see if I get the same issues?
[11:47] <frankban> rick_h_: it would be great, to double check there is not something crazy here
[11:47] <rick_h_> frankban: what branch are you running and I'll pull it done and try to run the tests
[11:48] <rick_h_> frankban: is this the symlink branch?
[11:48] <frankban> rick_h_: "make ftest JUJU_ENV=ec2" in charm trunk could dupe the problem
[11:49] <rick_h_> ~juju-gui-charmers/charms/trusty/juju-gui/trunk/ ?
[11:49] <rick_h_> frankban: ok, starting up
[11:50] <frankban> rick_h_: the dev branch should work: lp:~juju-gui/charms/trusty/juju-gui/trunk
[11:50] <frankban> rick_h_: thank you
[11:51] <frankban> rick_h_: in maas, I tried strating a node and It doesn't seem I am able to ssh into it (even without juju involved)
[11:51] <rick_h_> frankban: is this from the maas host?
[11:51] <rick_h_> frankban: and did you generate an ssh key on that user?
[11:51] <rick_h_> frankban: or you're letting juju generate the ssh key and then usnig juju ssh?
[11:52] <frankban> rick_h_: yes, from the ubuntu user in the maas host, and yes, quickstart generated the keys for me, and added them to the preferences before starting the node
[11:52] <frankban> rick_h_: could it be we need to do that before commissioning the node?
[11:53] <rick_h_> frankban: I can't imagine, it's wiped with a new ubuntu image when it's bootstrapped I had thought, but perhaps not
[11:53] <frankban> rick_h_: I'll try to commission the node again
[11:54] <rick_h_> frankban: rgr, tests are running here. 
[11:54] <rick_h_> frankban: juju-test.conductor DEBUG   : State for 1.21.0: started
[11:54] <rick_h_> juju-test.conductor.20-functional.test DEBUG   : Running 20-functional.test (tests/20-functional.test)
[11:54] <frankban> darn
[11:54] <frankban> rick_h_: so this is something on my side
[11:54] <rick_h_> that's on the main branch, I'll try the dev branch as well
[11:56] <frankban> thanks
[12:07] <frankban> rick_h_: what charm-tools version are you using?
[12:07] <rick_h_> 1.3.3-0ubuntu1~ubuntu14.04.1~ppa1
[12:07] <rick_h_> and the other branch is running tests here as well
[12:08] <rick_h_> brb
[12:13] <frankban> rick_h_: can I see the initial output from make ftest?
[12:14] <rick_h_> frankban: sure
[12:14] <rick_h_> https://pastebin.canonical.com/117908/
[12:14] <rick_h_> frankban: ^
[12:16] <frankban> rick_h_: aha, trying to manually connect to ec2 I get "Received disconnect from 54.74.124.239: 2: Too many authentication failures for frankban"
[12:18] <rick_h_> oh :/
[12:21] <frankban> rick_h_: I removed some old ssh keys and now it works :-/
[12:21] <rick_h_> frankban: woot
[12:22] <frankban> marcoceppi: is it possible that the juju-test failure was caused by too many keys in ~/.ssh?
[12:24] <frankban> rick_h_: nuc1 is still in commissioning state, do you have any logs to check what's wrong with maas?
[12:24] <rick_h_> frankban: let me log in and check the maas logs in /var/log/maas
[12:26] <rick_h_> frankban: hmm, bunch of errors OAuthUnauthorized: 'Expired timestamp: given 1411951792 and now 1412009155 has a greater difference than threshold 300'
[12:26] <marcoceppi> frankban: that's weird, but...possibly?
[12:26] <rick_h_> frankban: oh, I probably have to power cycle the node, let me try that out. 
[12:27] <frankban> rick_h_: thanks
[12:27] <rick_h_> hmm, I thought maas would control power on the nodes. wonder if there's a missing step for that as well
[12:28] <frankban> there are power parameters in the node edit page
[12:28] <rick_h_> maybe I need to set it to static ip so that I have an ip there. 
[12:28] <rick_h_> I've got the amt stuff setup for dhcp
[12:33] <rick_h_> frankban: ok, it's ready
[12:35] <frankban> rick_h_: uhm... no success with ubuntu@guimaas:~$ ssh 10.0.0.100
[12:37] <rick_h_> frankban: yea, I think I need to change them to static ips to complete the power settings
[12:37] <rick_h_> frankban: if you try to 'start' the node it can't and http://askubuntu.com/questions/481947/maas-unable-to-start-commisioned-nodes
[12:37] <rick_h_> goes into power settings, I'll work on hooking up kvm and fixing their amt setup
[12:37] <rick_h_> oh, never mind lol
[12:38] <rick_h_> I just managed to do a stop, so I guess 'ready' means it is started
[12:38] <rick_h_> frankban: and you're doing a deploy? looks like they're both allocated now?
[12:38] <frankban> rick_h_: I started them bot, in order to try connecting to those via ssh
[12:39] <rick_h_> ok
[12:39] <frankban> rick_h_: I receive pings back from both nodes, but ssh hangs
[12:40] <rick_h_> frankban: ok, so maybe not open?
[12:40] <rick_h_> firewall/etc wise?
[12:40] <frankban> rick_h_: maybe
[12:41] <rick_h_> http://askubuntu.com/questions/173112/what-is-the-maas-node-login hmm, seems we're on the right path
[12:42] <frankban> rick_h_: yes we did everything there
[12:44] <rick_h_> frankban: ok, hooking up kvm on one of them sec
[12:50] <luca__> rick_h_: frankban free for a call for 2 mins?
[12:50] <frankban> luca__: I am
[12:50] <rick_h_> luca__: yes
[12:50] <luca__> rick_h_: frankban I’ll make a hangout
[12:50]  * rick_h_ goes to get a quick drink
[12:51] <luca__> frankban: https://plus.google.com/hangouts/_/gwtlakndzaeym3q5jvmwk7aq24a?authuser=1&hl=en-GB
[12:51] <luca__> frankban: rick_h_ https://plus.google.com/hangouts/_/gqnbftvjxao6zsvpnnaehd2viya?hl=en
[12:52] <luca__> rick didn’t pick up the last call
[13:11] <rick_h_> frankban: ok cool, I can ssh to nuc1 now
[13:11] <rick_h_> it took forever going through a big install for 10min, but it's up now
[13:11] <frankban> rick_h_: me too \o/
[13:11] <rick_h_> going to power cycle nuc2 and see what it does
[13:12] <rick_h_> the lack of visibilty kind of sucks
[13:12] <rick_h_> I need to figure out how to do the remote kvm over the browser to these things
[13:12] <rick_h_> I think the amt stuff supports it
[13:18] <frankban> guihelp: anyone for a quick review of a doc-only branch? https://github.com/juju/juju-gui/pull/596
[13:18] <rick_h_> frankban: looking
[13:19] <rick_h_> frankban: lgtm ty much I kept meaning to add that in
[13:19] <frankban> rick_h_:  thank you!
[13:21] <rick_h_> frankban: when you cut the charm release can you do a micro gui release with the bug fix from hatch's work please?
[13:21] <rick_h_> frankban: and the nuc2 is up and showing ssh key info so think that's set as well
[13:21] <rick_h_> frankban: hopefully it all works now!
[13:21] <frankban> rick_h_: is Jeff's fix merged?
[13:21] <rick_h_> frankban: yes
[13:22] <frankban> rick_h_: cool, so I'll restart the process
[13:22] <rick_h_> https://github.com/juju/juju-gui/pull/593
[13:22] <rick_h_> frankban: sorry, missed you had started it 
[13:22] <frankban> rick_h_: np
[13:23] <frankban> rick_h_: is it the only thing worth being included in the changelog?
[13:23] <rick_h_> frankban: I believe so, /me dbl checks
[13:23] <rick_h_> frankban: yes, that's it. Other stuff is small/internals
[13:25] <frankban> rick_h_: stopping the nucs and trying juju
[13:25] <rick_h_> frankban: rgr
[13:38] <rick_h_> frankban: any luck? I didn't see the nuc shut down
[13:39] <frankban> rick_h_: quickstart failed: ERROR waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist
[13:40] <rick_h_> frankban: ugh
[13:41] <frankban> rick_h_: /var/lib/juju/nonce.txt should be created by cloud-init AFAICT
[13:41] <rick_h_> https://lists.ubuntu.com/archives/juju/2014-May/003849.html 
[13:41] <rick_h_> yea
[13:41] <frankban> rick_h_: trying to bootstrap without quickstart
[13:48] <frankban> rick_h_: 2014-09-30 13:47:54 DEBUG juju.utils.ssh ssh_openssh.go:129 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -i /home/ubuntu/.juju/ssh/juju_id_rsa -i /home/ubuntu/.ssh/id_rsa ubuntu@10.0.0.100 /bin/bash 
[13:48] <frankban> rick_h_: it seems this still fails
[13:48] <rick_h_> frankban: ok, booo and such. 
[13:48] <rick_h_> frankban: let me hard code ip addresses on the boxes for their power settings and such and see if we can find something to try 
[13:49] <frankban> rick note that without the trailing /bin/bash the command succeeds when run on a shell
[13:49] <rick_h_> frankban: hmm, that's interesting, I can't imagine bin/bash isn't allowed ?
[13:51] <frankban> rick_h_: everything is possible on "Weirdness Tuesday"
[13:54] <frankban> rick_h_: yeah it exited with the same (ambiguous) error
[13:56] <frankban> rick_h_: https://bugs.launchpad.net/juju-core/+bug/1314682
[13:56] <mup> Bug #1314682: Bootstrap fails because of virt-manager config <bootstrap> <juju> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1314682>
[14:07] <rick_h_> frankban: resetup the amt on the nucs to 10.0.0.101 hard coded ip and 10.0.0.102 
[14:08] <rick_h_> frankban: I've adjusted the dhcp config in the mass that 10.0.0.100-105 is static allocated
[14:08] <rick_h_> and 10.0.0.200-250 is dynamic
[14:08] <rick_h_> frankban: and readding the two nodes to maas, hopefully with more success this time
[14:09] <frankban> rick_h_: thanks
[14:10] <rick_h_> bah, how did it get to be .104?!
[14:13]  * rick_h_ is about to have a fit and start chucking nucs
[14:14] <hatch> would they then be  called "nuc chucks" ?
[14:18] <hatch> oh c'mon that was hilarious 
[14:19]  * rick_h_ stops grinding teeth long enough to chortle at it
[14:19] <hatch> lol
[14:20] <hatch> rick_h_: so the MAAS experience was not designed for non sysadmins hey?
[14:21] <frankban> jujugui heads up, working on a new GUI release now, please don't land changes
[14:21] <hatch> oh is this to fix the upgrade issue?
[14:22] <jcsackett> frankban: ack.
[14:22] <rick_h_> hatch: it's actually more of a total install issue
[14:23] <rick_h_> hatch: so bigger than ugprades, and including your search fix as part of the release
[14:23] <hatch> kadams54: your latest PR update is missing a test for the float branch
[14:23] <hatch> rick_h_: ahh ok
[14:23] <hatch> maybe we can do bi/weekly releases now :)
[14:24] <kadams54> hatch: you know a charm with float config? I looked for one in all of the featured charms and couldn't find any.
[14:24] <hatch> I thought you did because it was in your parsing code
[14:24] <hatch> hah
[14:25] <kadams54> I did in my parsing code because the docs say configs can have floats :-)
[14:25] <hatch> oh well then the tests should test for that
[14:26] <hatch> I added another comment
[14:38] <frankban> rick_h_: any idea about why 1.2.1 xz is 5.1MB and 1.2.0 is 8.5? https://launchpad.net/juju-gui/+download
[14:38] <rick_h_> frankban: not off the top of my head no
[14:38] <frankban> rick_h_: note that 1.1.1 is 5.1
[14:39] <rick_h_> frankban: maybe I had something on my system that made a bad tarball?
[14:39] <frankban> rick_h_: ok, I'll continue with the process
[14:49] <frankban> rick_h_: the manual build on CI step failed: http://ci.jujugui.org:8080/job/juju-gui-merge/698/console
[14:51] <rick_h_> jujugui call in 10
[14:51] <rick_h_> frankban: rgr looking
[14:52] <frankban> rick_h_: do I need to use juju gui or juju gui merge?
[14:53] <rick_h_> frankban: wiped the workspace and retrying. Worst case I'll have to ssh in and git fetch in the tree
[14:53] <rick_h_> frankban: looks like it's running your sha now http://ci.jujugui.org:8080/job/juju-gui-merge/699/console
[14:53] <frankban> rick_h_: cool thanks
[14:53] <rick_h_> frankban: sorry, head is in 5 different places and I'm not 100% following
[14:54] <frankban> rick_h_: no worries, long time did not make a gui release, it's an interesting process
[14:56] <rick_h_> frankban: oh, I see what you're doing yea heh that should be just juju-gui
[14:56] <rick_h_> frankban: the -merge job will attemt to land a pr that's not there
[14:56] <hatch> agreed, release is confusing
[14:57] <frankban> rick_h_: ok trying on "juju gui" (trying not to ping everyone)
[14:57] <hatch> kadams54: to avoid failures in CI you can run make check before pushing
[14:58] <rick_h_> frankban: all good
[14:59] <kadams54> hatch: yeah, one day I'll get that commit hook setup :-)
[15:04] <rick_h_> bac: call?
[15:27] <rick_h_> jujugui afk for a few min I need a coffee break
[15:39] <hatch> heh this notifier code is so old it's not even using Base.create()
[15:48] <frankban> jujugui uploaded the new GUI tarball, you can now land branches
[15:49] <hatch> thanks frankban
[15:52] <rick_h_> frankban: <3
[15:52] <frankban> rick_h_: now running the charm tests
[16:05] <hatch> rick_h_:  I think this bug is invalid now? https://bugs.launchpad.net/juju-gui/+bug/1218011
[16:06] <mup> Bug #1218011: full notification list is difficult to read and to use <juju-gui:Triaged> <https://launchpad.net/bugs/1218011>
[16:10] <rick_h_> hatch: yea, not really sure. we don't really get that many notifications at once these days
[16:21] <Makyo> jujugui quick branch for review/qa https://github.com/juju/juju-gui/pull/597
[16:22] <hatch> Makyo: not able to remove the environment.js stuff eh? :)
[16:23] <Makyo> hatch, wasn't any.
[16:24] <Makyo> That whole file was just dead code.
[16:25] <Makyo> I was ready for that branch to be a million times harder than it was.
[16:25] <hatch> haha gotcha
[16:30] <hatch> Makyo: so were there no tests for this code? 
[16:31] <hatch> I mean, obviously not if they didn't fail 
[16:31] <Makyo> hatch, as far as I can tell, every use of the code had been removed, the file was just left there.
[16:31] <hatch> heh...but wow
[16:31] <Makyo> Someone did my work for me :)
[16:32] <hatch> haha nice
[16:49] <frankban> rick_h_: gui/charm release done, and now to wait for ingestion. done for the day, have a nice evening!
[16:49] <rick_h_> frankban: night thanks!
[17:01] <bic2k> if I have a single machine with three services on it and I destroy one service on it, should it destroy the entire machine? I'm reproducing right now to confirm thats what happened.
[17:02] <rick_h_> bic2k: does it do it in a live env? we have a known bug that it does it in the demo mode that's being worked on atm 
[17:03] <bic2k> rick_h_ I really hope I'm in live mode, otherwise I've been pretending to update our services all morning ;-) So yes :-D
[17:03] <rick_h_> bic2k: ok, kadams54 ^
[17:04] <bic2k> rick_h_ is appears that I removed the service in juju-gui and juju-gui decided not to show the machine anymore, but `juju status` still shows it with the other services and a refresh of the gui shows it... may just be a bug in destroying services on the UX side
[17:04] <rick_h_> bic2k: rgr, makes sense and we'll add the note to the current wip to make sure we fix that
[17:05] <kadams54> bic2k: thanks for the report. Does the machine show back up with a refresh?
[17:06] <bic2k> kadams54 ya, machine reappears on refresh.
[17:07] <kadams54> whew
[17:08] <hatch> bic2k: did you have the charms in containers or all on the root machine?
[17:10] <bic2k> hatch all root machine charms
[17:11] <hatch> ok I think I know what the issue is
[17:11] <hatch> kadams54: it's probably because when the service is destroyed it matches on the machine assuming it's in a container but it's not
[17:12] <kadams54> hatch: yeah, but destroying a service shouldn't destroy the container, regardless of whether it's root or not.
[17:13] <hatch> true true
[17:37] <hatch> bic2k: https://bugs.launchpad.net/juju-gui/+bug/1375918 
[17:37] <mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:New> <https://launchpad.net/bugs/1375918>
[17:38] <kadams54> guihelp: So I've traced bic2k's issue (and likely some of the WIP cards) to this line: https://github.com/juju/juju-gui/blob/develop/app/models/handlers.js#L211 Does anyone know why we'd want to invoke machine delta processing as part of unitInfo delta processing?
[17:38] <hatch> hmmm
[17:39] <bic2k> hatch stack traced added to #1375918
[17:39] <mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:New> <https://launchpad.net/bugs/1375918>
[17:39] <kadams54> That particular line of code been there since April of last year.
[17:39] <hatch>  bic2k thanks
[17:39] <bic2k> feeling like QA this morning :-)
[17:39] <hatch> kadams54: ohh we process the delta information so that we can add the unit information to the machine models
[17:40] <kadams54> OK… but just straight up passing the same action (as we currently do now) is dangerous…
[17:40] <hatch> bic2k: haha - it's odd that no one else ran into these issues before but I'm glad you're helping us by reporting it :)
[17:41] <hatch> kadams54: how do you figure?
[17:41] <hatch> oh because the action is remove
[17:41] <hatch> haha duh
[17:41] <kadams54> hatch: Because in this case, the action (remove) only applies to the unit. But since we pass it into the machine delta processing…
[17:41] <kadams54> Ditto for adding a unit.
[17:41] <hatch> good find
[17:42] <kadams54> Ditto (probably) for just about any action on the unit.
[17:42] <hatch> wow how have we never noticed this (or any of our users) in a year
[17:42] <kadams54> It sounds like we want *:unitInfo actions to trigger an update:Machine action.
[17:42] <hatch> well we'll still need new units to add machines 
[17:43] <kadams54> hatch: it was sorta noticed. I wrapped it in an if statement that prevented trying to create machines when there is no machine ID. But that's not a complete fix.
[17:43] <hatch> because we'll need machines to place units on in the event that the machine delta comes in afterwards
[17:43] <hatch> wana have a quick chat about this in standup?
[17:43] <kadams54> hatch: Yeah, that's what I'm getting at here. I think we need to nail down exactly what the behavior ought to be.
[17:44] <hatch> ok joining
[17:44] <kadams54> hatch: will be there in a moment
[17:58] <hatch> jujugui I need a review on https://github.com/juju/juju-gui/pull/598 plz and thx
[17:59] <hatch> bic2k: looks like kadams54 has a good way forward on fixing the 'remove root machine' issue 
[17:59] <Makyo> On it
[18:01] <hatch> bic2k: and the expose toggle is also being worked on now :) we are stomping your bugs into the pavement :P
[18:01] <arosales> hatch: I recall a javascript console "trick" to change the name of the provider in the GUI do you know what that is?
[18:01] <hatch> arosales: I don't but I can figure it out, 1 min
[18:03] <hatch> testing....
[18:05] <hatch> arosales: yui.one('#environment-name').set('text', 'My rockin env');
[18:05] <hatch> that of course will only work until you refresh 
[18:05] <hatch> arosales: that won't however change the one in the machine view - would you like one for there as well?
[18:07] <hatch> arosales: here use this one instead   app.env.set('environmentName', 'this environment is the best');
[18:07] <hatch> that one will update it throughout the app
[18:08] <arosales> hatch: thank you sir
[18:08]  * arosales will write it down this time ;-)
[18:08] <hatch> haha
[18:08] <hatch> that also will only work until you refresh
[18:08] <hatch> :)
[18:09] <hatch> then it'll reset to whatever Juju says the environment name is
[18:09] <arosales> ack
[18:27]  * hatch lunching
[18:45]  * Makyo runs to the store over lunch, back in a few.
[19:07]  * rick_h_ goes to doc, back later
[19:21] <hatch> hmm what card to work on
[20:05] <hatch> jujugui if the user has conflicted config changes should we block them from comitting their changeset? Or simply notify them?
[20:08] <jcsackett> hatch: i'm sort of leaning towards block until they resolve.
[20:08] <hatch> jcsackett: I am too but also not sure if that's very good UX
[20:09] <jcsackett> hatch: it's not great, but just notifying and then paving over isn't either.
[20:09] <hatch> it may not be clear that there is a conflict even with it in the changeset list
[20:09] <jcsackett> the conflict likely indicates there's something setup that's not good.
[20:09] <jcsackett> hatch: so then we need better UI about what's wrong.
[20:10] <jcsackett> hatch: when you say notify, do you mean like we do with machines that can't be destroyed?
[20:10] <hatch> maybe allow them to click commit - but then pop up that black tooltip
[20:10] <jcsackett> b/c that works for me--don't do the thing we aren't sure about and pop up an error about why.
[20:11] <hatch> so user clicks the commit button, it opens the changeset list, they miss the 'conflict' section and they see that the commit button is now disabled but not sure why
[20:11] <hatch> it's not clear that the conflicts must be resolved
[20:11] <hatch> ( it doesn't help that we don't have a mockup for this ) :)
[20:14] <hatch> jcsackett: I'll block it and work on some way to make it clear that this needs to be resolved first
[20:15] <jcsackett> hatch: kick it to UX.
[20:15] <hatch> I ain't got no time for their jibber jabber
[20:15]  * jcsackett laughs
[20:34] <hatch> of course there is a bug in YUI's model list map function
[20:37] <jcsackett> BUGS EVERYWHERE.
[20:39] <hatch> lol
[21:07] <hatch> wow this branch was a little too easy....I bet the tests are going to be impossible
[21:07] <hatch> hah
[21:14] <rick_h_> hatch: yes, block but lead them straigh to the problem
[21:14]  * rick_h_ is back from damn doc trying to break my arm
[21:14] <hatch> haha
[21:15] <hatch> rick_h_: https://github.com/juju/juju-gui/pull/599
[21:22] <hatch> rick_h_: thanks for the comments . I'll take a screenshot and send it to luca et'al for some more design input - maybe the background colour should be red or something...iunno
[21:23] <rick_h_> hatch: yea, needs to be called out for sure
[21:23] <rick_h_> jujugui going to eod and run away night all
[21:24] <hatch> enjoy
[23:02] <huwshimi> Morning