=== CyberJacob is now known as CyberJacob|Away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [05:54] Is there a way to tune juju's mongodb instance to reduce the amount of syslog spamming? === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === menn0_ is now known as menn0 [11:09] Hi ! [11:09] I use MAAS 1.7 and juju [11:09] All work fine, it's magic :) [11:09] i have one machine with maas, and one node bootstrapped by juju [11:10] i want to add a new node now. Maas can show it, and the commissioning is fine [11:10] did u know how can i add it to juju now ? [11:10] f i start "juju add-machine negligible-band.maas", i got " error: malformed container argument "negligible-band.maas" [11:10] and for "juju add-machine ssh:negligible-band.maas", i got : " ERROR rc: 255 (ssh: Could not resolve hostname negligible-band.maas: Name or service not known) " [11:11] slaan: juju add-machine --constraints "cpu-cores=2 mem=2048M" [11:11] you should not use maas to spin up new node [11:12] not use maas ? I don't need a boot from pxe ? [11:12] unless you are manually provisioning a machine with ssh [11:12] in that case juju add-machine ssh:user@10.10.0.3 [11:15] mm ok. I don't understand why when i bootstrap juju for the first time, and if i have 2 node one maas, Juju choose one random node and install all only on this [11:15] why juju don't bootstrap whithin all the node ? [11:17] what's the output of juju status? [11:20] i have two environments maas and manual (rackspace) [11:20] manual environment is working fine [11:21] when i switch to maas environment all juju commands just hang [11:21] this : http://pastebin.com/QQ8ffxwZ [11:21] any idea how to debug or force destroying manual environment [11:21] sorry maas environment [11:22] i have to add the second node manualy ? [11:24] how did you deploy services? looks as if you deployed everything to single machine in separate containers [11:25] you could spin up new node with juju add-machine (with or without constrains) [11:25] then deploy desired service to that machine [11:25] i deploy service on LXC container within one machine [11:26] i want to deploy another service within a second node that i have added after the first juju's bootstrap [11:27] as far as i can see there is only a single machine running "0" [11:27] yes, so, i have to do a "juju add-machine ubuntu@ip" [11:28] juju add-machine ssh:user@ip [11:29] " ERROR rc: 255 (ssh: connect to host 192.168.1.17 port 22: No route to host) " [11:29] is your network up and running? [11:29] the node are down. When i boot it, MAAS shut down it [11:30] that is expected behaviour [11:30] Juju don't wait that the node boot ? like a bootstrap ? [11:30] why don't you try just juju add-machine? [11:30] with no arguments [11:30] and see what is going to happen :) [11:31] how many nodes do you have defined in maas? [11:31] okay :) [11:31] is the state of all nodes ready? [11:32] yes, the first node are deployed [11:32] the second, the new, are "Ready" [11:32] but shutdown [11:33] ok [11:33] when you run juju add-machine [11:33] that node should change state to allocated to root [11:33] oh yeah [11:33] you'r right [11:33] good [11:33] you should be able to ssh to it with juju ssh (node number from juju status) [11:34] then you could juju deploy --to 0 mysql [11:34] yeah, the new node are "deploying", and boot now [11:34] sorry --to 1 [11:35] if that is the number of the new node [11:35] 0 should be juju bootstrap node [11:35] cool, i just have to "add-machine" alone [11:41] Cool, now the node is "deployed" on maas, and "pending" on juju status [11:41] many thanks :) [11:41] no mention slaan [11:43] i hope that i will find someone to help me :) [11:54] WARNING unknown config field "network-bridge" [11:54] any ideas? [11:54] in maas enevironment === plars is now known as plars-afk === wedgwood1 is now known as wedgwood [14:40] hi guys im getting following error: WARNING juju.environs.config config.go:968 unknown config field "network-bridge" [14:40] i did not change/alter environment [14:41] warning started to appear after update of kvm/maas/juju [14:41] schkovich: did youupgrade juju? [14:41] schkovich: that's the answer, juju dropped that config field [14:42] marcoceppi, can we still configure the local network bridge, somehow? [14:42] arbrandes: network-bridge for maas or local? [14:43] marcoceppi, local [14:43] i see [14:43] deleting that field would resolve the problem [14:43] arbrandes: probably, let me check [14:43] schkovich: are you doing maas or lxc? [14:44] Any love for #1377262? [14:44] Bug #1377262: please expose network-bridge to manual provider also

[14:44] (not sure if you two are working together) [14:44] maas kvm [14:44] marcoceppi, nope, completely unrelated :) [14:44] schkovich: well you can just delete the field from ~/.juju/environments/maas.jenv [14:44] or whatever the name of your maas environment is [14:44] arbrandes: it may have been removed from maas but not the local provider [14:45] marcoceppi, great, thanks [14:45] For instance, it may have been a global option that was instead moved to a few specific providers [14:45] arbrandes: need to validate that statement though, one sec [14:45] i had yet another problem after update yesterday: vms that where marked to autostart did not start including state machine [14:46] arbrandes: just confirmed it's in the local provider environments still [14:46] is that also known problem? [14:46] schkovich: that's interesting, but sounds like a maas issue, what version of maas do you have? [14:48] thanks, marcoceppi [14:49] could be maas issue [14:49] how do i get maas version? [14:49] maas --help is not helpful ;) [14:49] schkovich: on the maas machine run `dpkg -l | grep maas` [14:49] ah that one [14:50] give me a moment [14:51] 1.5.4+bzr2294-0ubuntu1.2 [14:51] client [15:06] Can someone tell me where the juju agent for machine 0 caches copies of the charm during deployment? [15:08] marcoceppi: everything is on the same version 1.5.4 [15:08] cory_fu: typically to the storage for the environment [15:08] cory_fu: so it depends on the environment [15:09] local provider, in this case [15:09] schkovich: huh, I'm not aware of a bug in that version matching your description [15:09] cory_fu: ~/.juju/local [15:09] where local is the name of your local environment [15:09] cory_fu: Sorry I missed the services framework call the other day. Did you discuss how the RelationContext classes have both name and interface, but never seem to use interface? [15:09] Is there any chance that persists across destroy / bootstraps? [15:10] cory_fu: it's possible [15:10] marcoceppi: sorry, i can't provide more information. i been going through logs for a few hours but i found nothing [15:11] Spads: Not specifically. There is at least one case where both are needed, but I can't recall it off the top of my head. I think it has to do with provide_data [15:11] heh [15:11] anyway im going to flag vms to autostart reboot the server and see what's going to happen :) [15:11] Spads: You do need both to uniquely identify a relation [15:11] I just lost a couple hours to "Oh wait, it's not actually using interface here..." [15:11] Yeah, I agree that it's confusing and it's definitely something we want to clean up [15:12] I had assumed that interface would be the relation interface it'd hook onto, and name would just be kind of internal [15:12] but it feels the other way around, at least for the stuff I was working on [15:15] marcoceppi: So where would that storage be, so that I can check it? [15:15] Oh, you already said ~/.juju [15:16] Where would it be from the point of view of machine 0, though? [15:17] Ah, nevermind. I can't ssh into 0 in local provider anyway [15:43] cory_fu: yeah, 0 is your machine === erkules_ is now known as erkules === kadams54 is now known as kadams54-away === plars-afk is now known as plars === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [16:53] jumpkick: not sure if someone answered you but this may help https://jujucharms.com/precise/mongodb#verbose === scuttle|afk is now known as scuttlemonkey [19:02] arbrandes, seems that the network-bridge directive has been removed [19:03] niedbalski, not from lxc, apparently. [19:04] niedbalski, still, I would like to see it in the manual environment, and it was never there to begin with. :) [19:05] arbrandes, ack, i could help with that then. [19:07] niedbalski, #1377262 would be nice. But if there's an alternative way to get Juju to use a certain bridge for LXC on manually provided nodes that you know about, I'd sure like to hear it. ;) [19:07] Bug #1377262: please expose network-bridge to manual provider also

[19:08] My next step was to just re-use lxcbr0 for my manually created bridge. [19:18] arbrandes, as far as i know, there is no a possible workaround, different to use lxcbr0 [19:19] Ok, that's what I'll do, then! :D === CyberJacob|Away is now known as CyberJacob === kadams54 is now known as kadams54-away [19:37] lazyPower: I think your issue #55 on amulet is actually this: https://github.com/juju/amulet/issues/57 === kadams54-away is now known as kadams54 [19:50] marcoceppi: echo $JUJU_REPOSITORY - returns nothing though :( [19:50] lazyPower: your issue is a different one [19:50] and I know how to fix it === kadams54 is now known as kadams54-away [21:36] I'm getting some VERY strange behavior from amulet which I cannot explain. I looked at the python code. it makes no sense. http://pastebin.ubuntu.com/9480773/ [21:36] line 97 is the shutil.rmtree line. shutil is python's built in shutil afaik. [21:44] jrwren: wat [21:44] its referencing a nil object? [21:44] tvansteenburgh: ^ this is weird, but i haven't looked @ jrwrens code either. [21:47] the code that triggered the fail: http://pastebin.ubuntu.com/9480848/ [21:47] such are the pitfalls of __del__. i need to refactor that code, i've seen these errors on jenkins too [21:47] i'm guessing on line 37, but could have been line 38 [21:47] __del__ considered harmful. [21:47] yes [21:48] at least ever since python 2.4 [21:49] it's an easy refactor just haven't gotten around to it [21:49] no worries. If it is a known thing, then I'm happy. [21:51] jwren: https://github.com/juju/amulet/issues/58 [21:53] oh, it is on github. I was looking on lp [22:01] hey all, I quickstarted a manual environment in a container, with nested containers enabled, but juju-gui says that sub-containers are not supported, can't find much info on that, what am I doing wrong? [22:02] Saviq: containers in containers are not officially supported as far as I know [22:02] while it may be possible, we're not testing that scenario, and should be considered purely experimental quality experience. [22:02] lazyPower, I'm fine with that, doing experiments here in the first place [22:03] lazyPower, IIUC, as long as lxc works, juju should be able to create sub-containers no problem? [22:03] Saviq: with that being said, you might have to use the CLI to run your deployments in that scenario, i'm not 100% on what the gui is sniffing and blocking, a gui team member like perhaps hatch or rick_h_ would have more info [22:04] lazyPower, thanks, will try the CLI [22:04] a who what [22:04] * hatch pokes head in [22:04] hatch: containers in containers (yo dawg) - does the gui sniff for this and prevent deployment? [22:04] yeah [22:04] i figured as much. thanks for confirmation [22:04] Saviq: ^ [22:05] Saviq: so we disable containers in the GUI for environments where networking is not supported between containers [22:05] because trying to relate them will silently fail [22:05] you can force it to allow you though [22:06] by appending /:flags:/containers [22:06] to your url [22:06] ^ Saviq [22:06] hatch, I think my case is simpler actually, I don't want to deploy to nested containers, but my machine 0 is already a container [22:06] hatch, so IIUC networking should work fine? [22:08] Saviq: when you say it's a container, are you running locally? [22:08] lxc? [22:08] hatch, it's a vps in lxc [22:09] hatch: and to note, its manual provider [22:09] hatch, but to experiment, I've nested a "juju" container and want to do everything inside there before moving to the "parent" [22:09] hatch, fwiw, CLI deploy seems to be doing just fine [22:09] I believe you should be fine then [22:09] ok great [22:10] we do that to avoid the silent failure issues :) [22:10] hatch, thanks [22:11] Saviq: if you hit Shift+/ or ? then a menu will pop up which shows "Custom GUI Settings" [22:11] you can also use that to enable the containers [22:12] hatch, hah, cheat codes! [22:12] haha yup :) [22:12] next up - konami code! [22:12] hatch: would be cool to play pong with the charm icons :) [22:12] lol [22:12] that would be very cool [22:12] hehe [22:18] lazyPower: https://bugs.launchpad.net/juju-gui/+bug/1401687 :) [22:18] Bug #1401687: force enable container support from machine view [22:19] hatch: +1 [22:21] hatch, the "{Discard,Save} changes" button panel on bottom left when editing config overlays the bottom of the config pane, is that known? [22:26] hmm, that was fixed at one point [22:26] let me check dev [22:27] Saviq: this is definitely a reintroduced bug [22:27] hatch, want me to file one? [22:27] I'd love that [22:27] https://bugs.launchpad.net/~juju-gui [22:27] :) [22:28] wait that's the wrong link [22:28] lol [22:28] https://bugs.launchpad.net/juju-gui [22:28] there we go [22:28] yeah it looked weird [22:28] (off by one character error) ;) [22:30] hatch, bug #1401697, let me know if you need a screenshot [22:30] Bug #1401697: Controls panel overlays bottom of config pane [22:32] Saviq: I know what you mean but whomever gets assigned the bug may not so a screenshot would be helpful [22:33] thanks thanks for filing the bug! [22:34] ok, a piece of a screenshot added, hopefully clear [22:34] yup very, thanks === CyberJacob is now known as CyberJacob|Away