[01:03] huwshimi: review in, thanks for the great stuff [01:39] hatch: you do your blog post? === uru_ is now known as urulama [06:19] morning [09:27] Hi urulama [09:27] Rick said I can make some cards on the Juju GUI kanban [09:28] do you know which column I should put them on? [09:31] luca__: I suppose I would put them under ready to code [09:32] thanks fabrice_ [09:32] I’ll add them there [09:32] rick can move them if need be [09:34] luca__: he will be there in 90 minutes most likely so you can check with him [09:35] thanks :) [09:46] luca__: hey, was otp [09:46] urulama: no worries [09:46] urulama: I have added them now [09:47] * urulama gets worried :D [09:48] luca__: where did you put it? [09:48] ready to code in the urgent section [09:50] luca__: oh, robin will be happy :) [09:50] urulama: haha, he’s sitting near me. He’s on it :) === fabrice_ is now known as fabrice|lunch [09:54] 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] frankban: what flags were passed? [09:55] urulama: I just made the Urgent section of ready to code go red! [09:55] urulama: rick_h_ is not going to be happy with me [09:55] lol [09:55] marcoceppi: yes | juju-test --timeout=60m -v -e "ec2-precise" 20-functional.test [09:56] luca__: that is a great good morning welcome! [09:56] 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] marcoceppi: reset my juju-home? [09:57] frankban: not reset, sorry, override [09:58] 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] actually, we're not doing that anymore, good [09:59] hum. Why can't you access it [09:59] 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] frankban: could it just be that the instance took too long to come online? [10:02] marcoceppi: tried several times, trying again [10:03] it's weird that it's listing the internal IP address. I mean, nothing has changed in juju-test in months [10:03] 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] frankban: that is totally werid [10:04] the bootstrap command is literally a Popen to juju bootstrap [10:04] marcoceppi: yeah I know that [10:05] * marcoceppi scratches head and wakes up a bit more [10:21] marcoceppi: uhm, same error, Connection refused [10:27] * frankban bbiab [11:42] luca__: hah [11:42] * luca__ starts hiding up his desk [11:46] frankban: need me to test something out to see if I get the same issues? [11:47] rick_h_: it would be great, to double check there is not something crazy here [11:47] frankban: what branch are you running and I'll pull it done and try to run the tests [11:48] frankban: is this the symlink branch? === fabrice|lunch is now known as fabrice [11:48] rick_h_: "make ftest JUJU_ENV=ec2" in charm trunk could dupe the problem [11:49] ~juju-gui-charmers/charms/trusty/juju-gui/trunk/ ? [11:49] frankban: ok, starting up [11:50] rick_h_: the dev branch should work: lp:~juju-gui/charms/trusty/juju-gui/trunk [11:50] rick_h_: thank you [11:51] 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] frankban: is this from the maas host? [11:51] frankban: and did you generate an ssh key on that user? [11:51] frankban: or you're letting juju generate the ssh key and then usnig juju ssh? [11:52] 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] rick_h_: could it be we need to do that before commissioning the node? [11:53] 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] rick_h_: I'll try to commission the node again [11:54] frankban: rgr, tests are running here. [11:54] frankban: juju-test.conductor DEBUG : State for 1.21.0: started [11:54] juju-test.conductor.20-functional.test DEBUG : Running 20-functional.test (tests/20-functional.test) [11:54] darn [11:54] rick_h_: so this is something on my side [11:54] that's on the main branch, I'll try the dev branch as well [11:56] thanks [12:07] rick_h_: what charm-tools version are you using? [12:07] 1.3.3-0ubuntu1~ubuntu14.04.1~ppa1 [12:07] and the other branch is running tests here as well [12:08] brb [12:13] rick_h_: can I see the initial output from make ftest? [12:14] frankban: sure [12:14] https://pastebin.canonical.com/117908/ [12:14] frankban: ^ [12:16] 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] oh :/ [12:21] rick_h_: I removed some old ssh keys and now it works :-/ [12:21] frankban: woot [12:22] marcoceppi: is it possible that the juju-test failure was caused by too many keys in ~/.ssh? [12:24] rick_h_: nuc1 is still in commissioning state, do you have any logs to check what's wrong with maas? [12:24] frankban: let me log in and check the maas logs in /var/log/maas [12:26] frankban: hmm, bunch of errors OAuthUnauthorized: 'Expired timestamp: given 1411951792 and now 1412009155 has a greater difference than threshold 300' [12:26] frankban: that's weird, but...possibly? [12:26] frankban: oh, I probably have to power cycle the node, let me try that out. [12:27] rick_h_: thanks [12:27] hmm, I thought maas would control power on the nodes. wonder if there's a missing step for that as well [12:28] there are power parameters in the node edit page [12:28] maybe I need to set it to static ip so that I have an ip there. [12:28] I've got the amt stuff setup for dhcp [12:33] frankban: ok, it's ready [12:35] rick_h_: uhm... no success with ubuntu@guimaas:~$ ssh 10.0.0.100 [12:37] frankban: yea, I think I need to change them to static ips to complete the power settings [12:37] 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] goes into power settings, I'll work on hooking up kvm and fixing their amt setup [12:37] oh, never mind lol [12:38] I just managed to do a stop, so I guess 'ready' means it is started [12:38] frankban: and you're doing a deploy? looks like they're both allocated now? [12:38] rick_h_: I started them bot, in order to try connecting to those via ssh [12:39] ok [12:39] rick_h_: I receive pings back from both nodes, but ssh hangs [12:40] frankban: ok, so maybe not open? [12:40] firewall/etc wise? [12:40] rick_h_: maybe [12:41] http://askubuntu.com/questions/173112/what-is-the-maas-node-login hmm, seems we're on the right path [12:42] rick_h_: yes we did everything there [12:44] frankban: ok, hooking up kvm on one of them sec [12:50] rick_h_: frankban free for a call for 2 mins? [12:50] luca__: I am [12:50] luca__: yes [12:50] rick_h_: frankban I’ll make a hangout [12:50] * rick_h_ goes to get a quick drink [12:51] frankban: https://plus.google.com/hangouts/_/gwtlakndzaeym3q5jvmwk7aq24a?authuser=1&hl=en-GB [12:51] frankban: rick_h_ https://plus.google.com/hangouts/_/gqnbftvjxao6zsvpnnaehd2viya?hl=en [12:52] rick didn’t pick up the last call [13:11] frankban: ok cool, I can ssh to nuc1 now [13:11] it took forever going through a big install for 10min, but it's up now [13:11] rick_h_: me too \o/ [13:11] going to power cycle nuc2 and see what it does [13:12] the lack of visibilty kind of sucks [13:12] I need to figure out how to do the remote kvm over the browser to these things [13:12] I think the amt stuff supports it [13:18] guihelp: anyone for a quick review of a doc-only branch? https://github.com/juju/juju-gui/pull/596 [13:18] frankban: looking [13:19] frankban: lgtm ty much I kept meaning to add that in [13:19] rick_h_: thank you! [13:21] 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] frankban: and the nuc2 is up and showing ssh key info so think that's set as well [13:21] frankban: hopefully it all works now! [13:21] rick_h_: is Jeff's fix merged? [13:21] frankban: yes [13:22] rick_h_: cool, so I'll restart the process [13:22] https://github.com/juju/juju-gui/pull/593 [13:22] frankban: sorry, missed you had started it [13:22] rick_h_: np [13:23] rick_h_: is it the only thing worth being included in the changelog? [13:23] frankban: I believe so, /me dbl checks [13:23] frankban: yes, that's it. Other stuff is small/internals [13:25] rick_h_: stopping the nucs and trying juju [13:25] frankban: rgr [13:38] frankban: any luck? I didn't see the nuc shut down [13:39] rick_h_: quickstart failed: ERROR waited for 10m0s without being able to connect: /var/lib/juju/nonce.txt does not exist [13:40] frankban: ugh [13:41] rick_h_: /var/lib/juju/nonce.txt should be created by cloud-init AFAICT [13:41] https://lists.ubuntu.com/archives/juju/2014-May/003849.html [13:41] yea [13:41] rick_h_: trying to bootstrap without quickstart [13:48] 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] rick_h_: it seems this still fails [13:48] frankban: ok, booo and such. [13:48] 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] rick note that without the trailing /bin/bash the command succeeds when run on a shell [13:49] frankban: hmm, that's interesting, I can't imagine bin/bash isn't allowed ? [13:51] rick_h_: everything is possible on "Weirdness Tuesday" [13:54] rick_h_: yeah it exited with the same (ambiguous) error [13:56] rick_h_: https://bugs.launchpad.net/juju-core/+bug/1314682 [13:56] Bug #1314682: Bootstrap fails because of virt-manager config

[14:07] frankban: resetup the amt on the nucs to 10.0.0.101 hard coded ip and 10.0.0.102 [14:08] frankban: I've adjusted the dhcp config in the mass that 10.0.0.100-105 is static allocated [14:08] and 10.0.0.200-250 is dynamic [14:08] frankban: and readding the two nodes to maas, hopefully with more success this time [14:09] rick_h_: thanks [14:10] bah, how did it get to be .104?! [14:13] * rick_h_ is about to have a fit and start chucking nucs [14:14] would they then be called "nuc chucks" ? [14:18] oh c'mon that was hilarious [14:19] * rick_h_ stops grinding teeth long enough to chortle at it [14:19] lol [14:20] rick_h_: so the MAAS experience was not designed for non sysadmins hey? [14:21] jujugui heads up, working on a new GUI release now, please don't land changes [14:21] oh is this to fix the upgrade issue? [14:22] frankban: ack. [14:22] hatch: it's actually more of a total install issue [14:23] hatch: so bigger than ugprades, and including your search fix as part of the release [14:23] kadams54: your latest PR update is missing a test for the float branch [14:23] rick_h_: ahh ok [14:23] maybe we can do bi/weekly releases now :) [14:24] 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] I thought you did because it was in your parsing code [14:24] hah [14:25] I did in my parsing code because the docs say configs can have floats :-) [14:25] oh well then the tests should test for that [14:26] I added another comment [14:38] 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] frankban: not off the top of my head no [14:38] rick_h_: note that 1.1.1 is 5.1 [14:39] frankban: maybe I had something on my system that made a bad tarball? [14:39] rick_h_: ok, I'll continue with the process [14:49] rick_h_: the manual build on CI step failed: http://ci.jujugui.org:8080/job/juju-gui-merge/698/console [14:51] jujugui call in 10 [14:51] frankban: rgr looking [14:52] rick_h_: do I need to use juju gui or juju gui merge? [14:53] frankban: wiped the workspace and retrying. Worst case I'll have to ssh in and git fetch in the tree [14:53] frankban: looks like it's running your sha now http://ci.jujugui.org:8080/job/juju-gui-merge/699/console [14:53] rick_h_: cool thanks [14:53] frankban: sorry, head is in 5 different places and I'm not 100% following [14:54] rick_h_: no worries, long time did not make a gui release, it's an interesting process [14:56] frankban: oh, I see what you're doing yea heh that should be just juju-gui [14:56] frankban: the -merge job will attemt to land a pr that's not there [14:56] agreed, release is confusing [14:57] rick_h_: ok trying on "juju gui" (trying not to ping everyone) [14:57] kadams54: to avoid failures in CI you can run make check before pushing [14:58] frankban: all good [14:59] hatch: yeah, one day I'll get that commit hook setup :-) [15:04] bac: call? === b is now known as Guest78070 === fabrice is now known as fabrice|family [15:27] jujugui afk for a few min I need a coffee break === urulama is now known as urulama-afk === Guest78070 is now known as bac [15:39] heh this notifier code is so old it's not even using Base.create() [15:48] jujugui uploaded the new GUI tarball, you can now land branches [15:49] thanks frankban [15:52] frankban: <3 [15:52] rick_h_: now running the charm tests [16:05] rick_h_: I think this bug is invalid now? https://bugs.launchpad.net/juju-gui/+bug/1218011 [16:06] Bug #1218011: full notification list is difficult to read and to use [16:10] hatch: yea, not really sure. we don't really get that many notifications at once these days [16:21] jujugui quick branch for review/qa https://github.com/juju/juju-gui/pull/597 [16:22] Makyo: not able to remove the environment.js stuff eh? :) [16:23] hatch, wasn't any. [16:24] That whole file was just dead code. [16:25] I was ready for that branch to be a million times harder than it was. [16:25] haha gotcha [16:30] Makyo: so were there no tests for this code? [16:31] I mean, obviously not if they didn't fail [16:31] hatch, as far as I can tell, every use of the code had been removed, the file was just left there. [16:31] heh...but wow [16:31] Someone did my work for me :) [16:32] haha nice [16:49] rick_h_: gui/charm release done, and now to wait for ingestion. done for the day, have a nice evening! [16:49] frankban: night thanks! [17:01] 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] 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] 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] bic2k: ok, kadams54 ^ [17:04] 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] bic2k: rgr, makes sense and we'll add the note to the current wip to make sure we fix that [17:05] bic2k: thanks for the report. Does the machine show back up with a refresh? [17:06] kadams54 ya, machine reappears on refresh. [17:07] whew [17:08] bic2k: did you have the charms in containers or all on the root machine? [17:10] hatch all root machine charms [17:11] ok I think I know what the issue is [17:11] 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] hatch: yeah, but destroying a service shouldn't destroy the container, regardless of whether it's root or not. [17:13] true true [17:37] bic2k: https://bugs.launchpad.net/juju-gui/+bug/1375918 [17:37] Bug #1375918: units can be created without a service causing cascading failures [17:38] 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] hmmm [17:39] hatch stack traced added to #1375918 [17:39] Bug #1375918: units can be created without a service causing cascading failures [17:39] That particular line of code been there since April of last year. [17:39] bic2k thanks [17:39] feeling like QA this morning :-) [17:39] kadams54: ohh we process the delta information so that we can add the unit information to the machine models [17:40] OK… but just straight up passing the same action (as we currently do now) is dangerous… [17:40] 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] kadams54: how do you figure? [17:41] oh because the action is remove [17:41] haha duh [17:41] 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] Ditto for adding a unit. [17:41] good find [17:42] Ditto (probably) for just about any action on the unit. [17:42] wow how have we never noticed this (or any of our users) in a year [17:42] It sounds like we want *:unitInfo actions to trigger an update:Machine action. [17:42] well we'll still need new units to add machines [17:43] 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] because we'll need machines to place units on in the event that the machine delta comes in afterwards [17:43] wana have a quick chat about this in standup? [17:43] 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] ok joining [17:44] hatch: will be there in a moment [17:58] jujugui I need a review on https://github.com/juju/juju-gui/pull/598 plz and thx [17:59] bic2k: looks like kadams54 has a good way forward on fixing the 'remove root machine' issue [17:59] On it === fabrice is now known as fabrice|family [18:01] bic2k: and the expose toggle is also being worked on now :) we are stomping your bugs into the pavement :P [18:01] 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] arosales: I don't but I can figure it out, 1 min [18:03] testing.... [18:05] arosales: yui.one('#environment-name').set('text', 'My rockin env'); [18:05] that of course will only work until you refresh [18:05] arosales: that won't however change the one in the machine view - would you like one for there as well? [18:07] arosales: here use this one instead app.env.set('environmentName', 'this environment is the best'); [18:07] that one will update it throughout the app [18:08] hatch: thank you sir [18:08] * arosales will write it down this time ;-) [18:08] haha [18:08] that also will only work until you refresh [18:08] :) [18:09] then it'll reset to whatever Juju says the environment name is [18:09] ack [18:27] * hatch lunching === uru_ is now known as urulama [18:45] * Makyo runs to the store over lunch, back in a few. [19:07] * rick_h_ goes to doc, back later [19:21] hmm what card to work on === urulama is now known as urulama-afk [20:05] jujugui if the user has conflicted config changes should we block them from comitting their changeset? Or simply notify them? [20:08] hatch: i'm sort of leaning towards block until they resolve. [20:08] jcsackett: I am too but also not sure if that's very good UX [20:09] hatch: it's not great, but just notifying and then paving over isn't either. [20:09] it may not be clear that there is a conflict even with it in the changeset list [20:09] the conflict likely indicates there's something setup that's not good. [20:09] hatch: so then we need better UI about what's wrong. [20:10] hatch: when you say notify, do you mean like we do with machines that can't be destroyed? [20:10] maybe allow them to click commit - but then pop up that black tooltip [20:10] 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] 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] it's not clear that the conflicts must be resolved [20:11] ( it doesn't help that we don't have a mockup for this ) :) [20:14] jcsackett: I'll block it and work on some way to make it clear that this needs to be resolved first [20:15] hatch: kick it to UX. [20:15] I ain't got no time for their jibber jabber [20:15] * jcsackett laughs [20:34] of course there is a bug in YUI's model list map function [20:37] BUGS EVERYWHERE. [20:39] lol [21:07] wow this branch was a little too easy....I bet the tests are going to be impossible [21:07] hah [21:14] 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] haha [21:15] rick_h_: https://github.com/juju/juju-gui/pull/599 [21:22] 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] hatch: yea, needs to be called out for sure [21:23] jujugui going to eod and run away night all [21:24] enjoy [23:02] Morning