rick_h_ | huwshimi: review in, thanks for the great stuff | 01:03 |
---|---|---|
rick_h_ | hatch: you do your blog post? | 01:39 |
=== uru_ is now known as urulama | ||
fabrice | morning | 06:19 |
luca__ | Hi urulama | 09:27 |
luca__ | Rick said I can make some cards on the Juju GUI kanban | 09:27 |
luca__ | do you know which column I should put them on? | 09:28 |
fabrice_ | luca__: I suppose I would put them under ready to code | 09:31 |
luca__ | thanks fabrice_ | 09:32 |
luca__ | I’ll add them there | 09:32 |
luca__ | rick can move them if need be | 09:32 |
fabrice_ | luca__: he will be there in 90 minutes most likely so you can check with him | 09:34 |
luca__ | thanks :) | 09:35 |
urulama | luca__: hey, was otp | 09:46 |
luca__ | urulama: no worries | 09:46 |
luca__ | urulama: I have added them now | 09:46 |
* urulama gets worried :D | 09:47 | |
urulama | luca__: where did you put it? | 09:48 |
luca__ | ready to code in the urgent section | 09:48 |
urulama | luca__: oh, robin will be happy :) | 09:50 |
luca__ | urulama: haha, he’s sitting near me. He’s on it :) | 09:50 |
=== fabrice_ is now known as fabrice|lunch | ||
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:54 |
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:55 |
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:56 |
frankban | marcoceppi: reset my juju-home? | 09:57 |
marcoceppi | frankban: not reset, sorry, override | 09:57 |
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:58 |
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/ | 09:59 |
marcoceppi | frankban: could it just be that the instance took too long to come online? | 10:00 |
frankban | marcoceppi: tried several times, trying again | 10:02 |
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:03 |
marcoceppi | the bootstrap command is literally a Popen to juju bootstrap | 10:04 |
frankban | marcoceppi: yeah I know that | 10:04 |
* marcoceppi scratches head and wakes up a bit more | 10:05 | |
frankban | marcoceppi: uhm, same error, Connection refused | 10:21 |
* frankban bbiab | 10:27 | |
rick_h_ | luca__: hah | 11:42 |
* luca__ starts hiding up his desk | 11:42 | |
rick_h_ | frankban: need me to test something out to see if I get the same issues? | 11:46 |
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:47 |
rick_h_ | frankban: is this the symlink branch? | 11:48 |
=== fabrice|lunch is now known as fabrice | ||
frankban | rick_h_: "make ftest JUJU_ENV=ec2" in charm trunk could dupe the problem | 11:48 |
rick_h_ | ~juju-gui-charmers/charms/trusty/juju-gui/trunk/ ? | 11:49 |
rick_h_ | frankban: ok, starting up | 11:49 |
frankban | rick_h_: the dev branch should work: lp:~juju-gui/charms/trusty/juju-gui/trunk | 11:50 |
frankban | rick_h_: thank you | 11:50 |
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:51 |
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:52 |
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:53 |
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:54 |
frankban | thanks | 11:56 |
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:07 |
rick_h_ | brb | 12:08 |
frankban | rick_h_: can I see the initial output from make ftest? | 12:13 |
rick_h_ | frankban: sure | 12:14 |
rick_h_ | https://pastebin.canonical.com/117908/ | 12:14 |
rick_h_ | frankban: ^ | 12:14 |
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:16 |
rick_h_ | oh :/ | 12:18 |
frankban | rick_h_: I removed some old ssh keys and now it works :-/ | 12:21 |
rick_h_ | frankban: woot | 12:21 |
frankban | marcoceppi: is it possible that the juju-test failure was caused by too many keys in ~/.ssh? | 12:22 |
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:24 |
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:26 |
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:27 |
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:28 |
rick_h_ | frankban: ok, it's ready | 12:33 |
frankban | rick_h_: uhm... no success with ubuntu@guimaas:~$ ssh 10.0.0.100 | 12:35 |
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:37 |
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:38 |
rick_h_ | ok | 12:39 |
frankban | rick_h_: I receive pings back from both nodes, but ssh hangs | 12:39 |
rick_h_ | frankban: ok, so maybe not open? | 12:40 |
rick_h_ | firewall/etc wise? | 12:40 |
frankban | rick_h_: maybe | 12:40 |
rick_h_ | http://askubuntu.com/questions/173112/what-is-the-maas-node-login hmm, seems we're on the right path | 12:41 |
frankban | rick_h_: yes we did everything there | 12:42 |
rick_h_ | frankban: ok, hooking up kvm on one of them sec | 12:44 |
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:50 | |
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:51 |
luca__ | rick didn’t pick up the last call | 12:52 |
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:11 |
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:12 |
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:18 |
rick_h_ | frankban: lgtm ty much I kept meaning to add that in | 13:19 |
frankban | rick_h_: thank you! | 13:19 |
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:21 |
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:22 |
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:23 |
frankban | rick_h_: stopping the nucs and trying juju | 13:25 |
rick_h_ | frankban: rgr | 13:25 |
rick_h_ | frankban: any luck? I didn't see the nuc shut down | 13:38 |
frankban | rick_h_: quickstart failed: ERROR waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist | 13:39 |
rick_h_ | frankban: ugh | 13:40 |
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:41 |
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:48 |
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:49 |
frankban | rick_h_: everything is possible on "Weirdness Tuesday" | 13:51 |
frankban | rick_h_: yeah it exited with the same (ambiguous) error | 13:54 |
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> | 13:56 |
rick_h_ | frankban: resetup the amt on the nucs to 10.0.0.101 hard coded ip and 10.0.0.102 | 14:07 |
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:08 |
frankban | rick_h_: thanks | 14:09 |
rick_h_ | bah, how did it get to be .104?! | 14:10 |
* rick_h_ is about to have a fit and start chucking nucs | 14:13 | |
hatch | would they then be called "nuc chucks" ? | 14:14 |
hatch | oh c'mon that was hilarious | 14:18 |
* rick_h_ stops grinding teeth long enough to chortle at it | 14:19 | |
hatch | lol | 14:19 |
hatch | rick_h_: so the MAAS experience was not designed for non sysadmins hey? | 14:20 |
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:21 |
jcsackett | frankban: ack. | 14:22 |
rick_h_ | hatch: it's actually more of a total install issue | 14:22 |
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:23 |
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:24 |
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:25 |
hatch | I added another comment | 14:26 |
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:38 |
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:39 |
frankban | rick_h_: the manual build on CI step failed: http://ci.jujugui.org:8080/job/juju-gui-merge/698/console | 14:49 |
rick_h_ | jujugui call in 10 | 14:51 |
rick_h_ | frankban: rgr looking | 14:51 |
frankban | rick_h_: do I need to use juju gui or juju gui merge? | 14:52 |
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:53 |
frankban | rick_h_: no worries, long time did not make a gui release, it's an interesting process | 14:54 |
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:56 |
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:57 |
rick_h_ | frankban: all good | 14:58 |
kadams54 | hatch: yeah, one day I'll get that commit hook setup :-) | 14:59 |
rick_h_ | bac: call? | 15:04 |
=== b is now known as Guest78070 | ||
=== fabrice is now known as fabrice|family | ||
rick_h_ | jujugui afk for a few min I need a coffee break | 15:27 |
=== urulama is now known as urulama-afk | ||
=== Guest78070 is now known as bac | ||
hatch | heh this notifier code is so old it's not even using Base.create() | 15:39 |
frankban | jujugui uploaded the new GUI tarball, you can now land branches | 15:48 |
hatch | thanks frankban | 15:49 |
rick_h_ | frankban: <3 | 15:52 |
frankban | rick_h_: now running the charm tests | 15:52 |
hatch | rick_h_: I think this bug is invalid now? https://bugs.launchpad.net/juju-gui/+bug/1218011 | 16:05 |
mup | Bug #1218011: full notification list is difficult to read and to use <juju-gui:Triaged> <https://launchpad.net/bugs/1218011> | 16:06 |
rick_h_ | hatch: yea, not really sure. we don't really get that many notifications at once these days | 16:10 |
Makyo | jujugui quick branch for review/qa https://github.com/juju/juju-gui/pull/597 | 16:21 |
hatch | Makyo: not able to remove the environment.js stuff eh? :) | 16:22 |
Makyo | hatch, wasn't any. | 16:23 |
Makyo | That whole file was just dead code. | 16:24 |
Makyo | I was ready for that branch to be a million times harder than it was. | 16:25 |
hatch | haha gotcha | 16:25 |
hatch | Makyo: so were there no tests for this code? | 16:30 |
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:31 |
hatch | haha nice | 16:32 |
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! | 16:49 |
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:01 |
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:02 |
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:03 |
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:04 |
kadams54 | bic2k: thanks for the report. Does the machine show back up with a refresh? | 17:05 |
bic2k | kadams54 ya, machine reappears on refresh. | 17:06 |
kadams54 | whew | 17:07 |
hatch | bic2k: did you have the charms in containers or all on the root machine? | 17:08 |
bic2k | hatch all root machine charms | 17:10 |
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:11 |
kadams54 | hatch: yeah, but destroying a service shouldn't destroy the container, regardless of whether it's root or not. | 17:12 |
hatch | true true | 17:13 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
hatch | ok joining | 17:44 |
kadams54 | hatch: will be there in a moment | 17:44 |
hatch | jujugui I need a review on https://github.com/juju/juju-gui/pull/598 plz and thx | 17:58 |
hatch | bic2k: looks like kadams54 has a good way forward on fixing the 'remove root machine' issue | 17:59 |
Makyo | On it | 17:59 |
=== fabrice is now known as fabrice|family | ||
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:01 |
hatch | testing.... | 18:03 |
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:05 |
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:07 |
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:08 |
hatch | then it'll reset to whatever Juju says the environment name is | 18:09 |
arosales | ack | 18:09 |
* hatch lunching | 18:27 | |
=== uru_ is now known as urulama | ||
* Makyo runs to the store over lunch, back in a few. | 18:45 | |
* rick_h_ goes to doc, back later | 19:07 | |
hatch | hmm what card to work on | 19:21 |
=== urulama is now known as urulama-afk | ||
hatch | jujugui if the user has conflicted config changes should we block them from comitting their changeset? Or simply notify them? | 20:05 |
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:08 |
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:09 |
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:10 |
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:11 |
hatch | jcsackett: I'll block it and work on some way to make it clear that this needs to be resolved first | 20:14 |
jcsackett | hatch: kick it to UX. | 20:15 |
hatch | I ain't got no time for their jibber jabber | 20:15 |
* jcsackett laughs | 20:15 | |
hatch | of course there is a bug in YUI's model list map function | 20:34 |
jcsackett | BUGS EVERYWHERE. | 20:37 |
hatch | lol | 20:39 |
hatch | wow this branch was a little too easy....I bet the tests are going to be impossible | 21:07 |
hatch | hah | 21:07 |
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:14 |
hatch | rick_h_: https://github.com/juju/juju-gui/pull/599 | 21:15 |
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:22 |
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:23 |
hatch | enjoy | 21:24 |
huwshimi | Morning | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!