[05:54] <jumpkick> Is there a way to tune juju's mongodb instance to reduce the amount of syslog spamming?
[11:09] <Slaan> Hi !
[11:09] <Slaan> I use MAAS 1.7 and juju
[11:09] <Slaan> All work fine, it's magic :)
[11:09] <Slaan> i have one machine with maas, and one node bootstrapped by juju
[11:10] <Slaan> i want to add a new node now. Maas can show it, and the commissioning is fine
[11:10] <Slaan> did u know how can i add it to juju now ?
[11:10] <Slaan> f i start "juju add-machine negligible-band.maas", i got " error: malformed container argument "negligible-band.maas"
[11:10] <Slaan> 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] <schkovich> slaan: juju add-machine --constraints "cpu-cores=2 mem=2048M"
[11:11] <schkovich> you should not use maas to spin up new node
[11:12] <Slaan> not use maas ? I don't need a boot from pxe ?
[11:12] <schkovich> unless you are manually provisioning a machine with ssh
[11:12] <schkovich> in that case juju add-machine ssh:user@10.10.0.3
[11:15] <Slaan> 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] <Slaan> why juju don't bootstrap whithin all the node ?
[11:17] <schkovich> what's the output of juju status?
[11:20] <schkovich> i have two environments maas and manual (rackspace)
[11:20] <schkovich> manual environment is working fine
[11:21] <schkovich> when i switch to maas environment all juju commands just hang
[11:21] <Slaan> this : http://pastebin.com/QQ8ffxwZ
[11:21] <schkovich> any idea how to debug or force destroying manual environment
[11:21] <schkovich> sorry maas environment
[11:22] <Slaan> i have to add the second node manualy ?
[11:24] <schkovich> how did you deploy services? looks as if you deployed everything to single machine in separate containers
[11:25] <schkovich> you could spin up new node with juju add-machine (with or without constrains)
[11:25] <schkovich> then deploy desired service to that machine
[11:25] <Slaan> i deploy service on LXC container within one machine
[11:26] <Slaan> i want to deploy another service within a second node that i have added after the first juju's bootstrap
[11:27] <schkovich> as far as i can see there is only a single machine running "0"
[11:27] <Slaan> yes, so, i have to do a "juju add-machine ubuntu@ip"
[11:28] <schkovich> juju add-machine ssh:user@ip
[11:29] <Slaan> " ERROR rc: 255 (ssh: connect to host 192.168.1.17 port 22: No route to host) "
[11:29] <schkovich> is your network up and running?
[11:29] <Slaan> the node are down. When i boot it, MAAS shut down it
[11:30] <schkovich> that is expected behaviour
[11:30] <Slaan> Juju don't wait that the node boot ? like a bootstrap ?
[11:30] <schkovich> why don't you try just juju add-machine?
[11:30] <schkovich> with no arguments
[11:30] <schkovich> and see what is going to happen :)
[11:31] <schkovich> how many nodes do you have defined in maas?
[11:31] <Slaan> okay :)
[11:31] <schkovich> is the state of all nodes ready?
[11:32] <Slaan> yes, the first node are deployed
[11:32] <Slaan> the second, the new, are "Ready"
[11:32] <Slaan> but shutdown
[11:33] <schkovich> ok
[11:33] <schkovich> when you run juju add-machine
[11:33] <schkovich> that node should change state to allocated to root
[11:33] <Slaan> oh yeah
[11:33] <Slaan> you'r right
[11:33] <Slaan> good
[11:33] <schkovich> you should be able to ssh to it with juju ssh (node number from juju status)
[11:34] <schkovich> then you could juju deploy --to 0 mysql
[11:34] <Slaan> yeah, the new node are "deploying", and boot now
[11:34] <schkovich> sorry --to 1
[11:35] <schkovich> if that is the number of the new node
[11:35] <schkovich> 0 should be juju bootstrap node
[11:35] <Slaan> cool, i just have to "add-machine" alone
[11:41] <Slaan> Cool, now the node is "deployed" on maas, and "pending" on juju status
[11:41] <Slaan> many thanks :)
[11:41] <schkovich> no mention slaan
[11:43] <schkovich> i hope that i will find someone to help me :)
[11:54] <schkovich> WARNING unknown config field "network-bridge"
[11:54] <schkovich> any ideas?
[11:54] <schkovich> in maas enevironment
[14:40] <schkovich> hi guys im getting following error: WARNING juju.environs.config config.go:968 unknown config field "network-bridge"
[14:40] <schkovich> i did not change/alter environment
[14:41] <schkovich> warning started to appear after update of kvm/maas/juju
[14:41] <marcoceppi> schkovich: did youupgrade juju?
[14:41] <marcoceppi> schkovich: that's the answer, juju dropped that config field
[14:42] <arbrandes> marcoceppi, can we still configure the local network bridge, somehow?
[14:42] <marcoceppi> arbrandes: network-bridge for maas or local?
[14:43] <arbrandes> marcoceppi, local
[14:43] <schkovich> i see
[14:43] <schkovich> deleting that field would resolve the problem
[14:43] <marcoceppi> arbrandes: probably, let me check
[14:43] <marcoceppi> schkovich: are you doing maas or lxc?
[14:44] <arbrandes> Any love for #1377262?
[14:44] <mup> Bug #1377262: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1377262>
[14:44] <marcoceppi> (not sure if you two are working together)
[14:44] <schkovich> maas kvm
[14:44] <arbrandes> marcoceppi, nope, completely unrelated :)
[14:44] <marcoceppi> schkovich: well you can just delete the field from ~/.juju/environments/maas.jenv
[14:44] <marcoceppi> or whatever the name of your maas environment is
[14:44] <marcoceppi> arbrandes: it may have been removed from maas but not the local provider
[14:45] <arbrandes> marcoceppi, great, thanks
[14:45] <marcoceppi> For instance, it may have been a global option that was instead moved to a few specific providers
[14:45] <marcoceppi> arbrandes: need to validate that statement though, one sec
[14:45] <schkovich> i had yet another problem after update yesterday: vms that where marked to autostart did not start including state machine
[14:46] <marcoceppi> arbrandes: just confirmed it's in the local provider environments still
[14:46] <schkovich> is that also known problem?
[14:46] <marcoceppi> schkovich: that's interesting, but sounds like a maas issue, what version of maas do you have?
[14:48] <arbrandes> thanks, marcoceppi
[14:49] <schkovich> could be maas issue
[14:49] <schkovich> how do i get maas version?
[14:49] <schkovich> maas --help is not helpful ;)
[14:49] <marcoceppi> schkovich: on the maas machine run `dpkg -l | grep maas`
[14:49] <schkovich> ah that one
[14:50] <schkovich> give me a moment
[14:51] <schkovich>  1.5.4+bzr2294-0ubuntu1.2
[14:51] <schkovich> client
[15:06] <cory_fu> Can someone tell me where the juju agent for machine 0 caches copies of the charm during deployment?
[15:08] <schkovich> marcoceppi: everything is on the same version 1.5.4
[15:08] <marcoceppi> cory_fu: typically to the storage for the environment
[15:08] <marcoceppi> cory_fu: so it depends on the environment
[15:09] <cory_fu> local provider, in this case
[15:09] <marcoceppi> schkovich: huh, I'm not aware of a bug in that version matching your description
[15:09] <marcoceppi> cory_fu: ~/.juju/local
[15:09] <marcoceppi> where local is the name of your local environment
[15:09] <Spads> 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] <cory_fu> Is there any chance that persists across destroy / bootstraps?
[15:10] <marcoceppi> cory_fu: it's possible
[15:10] <schkovich> marcoceppi: sorry, i can't provide more information. i been going through logs for a few hours but i found nothing
[15:11] <cory_fu> 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] <Spads> heh
[15:11] <schkovich> anyway im going to flag vms to autostart reboot the server and see what's going to happen :)
[15:11] <cory_fu> Spads: You do need both to uniquely identify a relation
[15:11] <Spads> I just lost a couple hours to "Oh wait, it's not actually using interface here..."
[15:11] <cory_fu> Yeah, I agree that it's confusing and it's definitely something we want to clean up
[15:12] <Spads> I had assumed that interface would be the relation interface it'd hook onto, and name would just be kind of internal
[15:12] <Spads> but it feels the other way around, at least for the stuff I was working on
[15:15] <cory_fu> marcoceppi: So where would that storage be, so that I can check it?
[15:15] <cory_fu> Oh, you already said ~/.juju
[15:16] <cory_fu> Where would it be from the point of view of machine 0, though?
[15:17] <cory_fu> Ah, nevermind.  I can't ssh into 0 in local provider anyway
[15:43] <marcoceppi> cory_fu: yeah, 0 is your machine
[16:53] <rsynnest> jumpkick: not sure if someone answered you but this may help https://jujucharms.com/precise/mongodb#verbose
[19:02] <niedbalski> arbrandes, seems that the network-bridge directive has been removed
[19:03] <arbrandes> niedbalski, not from lxc, apparently.
[19:04] <arbrandes> niedbalski, still, I would like to see it in the manual environment, and it was never there to begin with. :)
[19:05] <niedbalski> arbrandes, ack, i could help with that then.
[19:07] <arbrandes> 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] <mup> Bug #1377262: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1377262>
[19:08] <arbrandes> My next step was to just re-use lxcbr0 for my manually created bridge.
[19:18] <niedbalski> arbrandes, as far as i know, there is no a possible workaround, different to use lxcbr0
[19:19] <arbrandes> Ok, that's what I'll do, then! :D
[19:37] <marcoceppi> lazyPower: I think your issue #55 on amulet is actually this: https://github.com/juju/amulet/issues/57
[19:50] <lazyPower> marcoceppi: echo $JUJU_REPOSITORY - returns nothing though :(
[19:50] <marcoceppi> lazyPower: your issue is a different one
[19:50] <marcoceppi> and I know how to fix it
[21:36] <jrwren> 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] <jrwren> line 97 is the shutil.rmtree line. shutil is python's built in shutil afaik.
[21:44] <lazyPower> jrwren: wat
[21:44] <lazyPower> its referencing a nil object?
[21:44] <lazyPower> tvansteenburgh: ^ this is weird, but i haven't looked @ jrwrens code either.
[21:47] <jrwren> the code that triggered the fail: http://pastebin.ubuntu.com/9480848/
[21:47] <tvansteenburgh> such are the pitfalls of __del__. i need to refactor that code, i've seen these errors on jenkins too
[21:47] <jrwren> i'm guessing on line 37, but could have been line 38
[21:47] <jrwren> __del__ considered harmful.
[21:47] <tvansteenburgh> yes
[21:48] <jrwren> at least ever since python 2.4
[21:49] <tvansteenburgh> it's an easy refactor just haven't gotten around to it
[21:49] <jrwren> no worries. If it is a known thing, then I'm happy.
[21:51] <tvansteenburgh> jwren: https://github.com/juju/amulet/issues/58
[21:53] <jrwren> oh, it is on github. I was looking on lp
[22:01] <Saviq> 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] <lazyPower> Saviq: containers in containers are not officially supported as far as I know
[22:02] <lazyPower> while it may be possible, we're not testing that scenario, and should be considered purely experimental quality experience.
[22:02] <Saviq> lazyPower, I'm fine with that, doing experiments here in the first place
[22:03] <Saviq> lazyPower, IIUC, as long as lxc works, juju should be able to create sub-containers no problem?
[22:03] <lazyPower> 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] <Saviq> lazyPower, thanks, will try the CLI
[22:04] <hatch> a who what
[22:04]  * hatch pokes head in
[22:04] <lazyPower> hatch: containers in containers (yo dawg) - does the gui sniff for this and prevent deployment?
[22:04] <hatch> yeah
[22:04] <lazyPower> i figured as much. thanks for confirmation
[22:04] <lazyPower> Saviq: ^
[22:05] <hatch> Saviq: so we disable containers in the GUI for environments where networking is not supported between containers
[22:05] <hatch> because trying to relate them will silently fail
[22:05] <hatch> you can force it to allow you though
[22:06] <hatch> by appending /:flags:/containers
[22:06] <hatch> to your url
[22:06] <hatch> ^ Saviq
[22:06] <Saviq> 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] <Saviq> hatch, so IIUC networking should work fine?
[22:08] <hatch> Saviq: when you say it's a container, are you running locally?
[22:08] <hatch> lxc?
[22:08] <Saviq> hatch, it's a vps in lxc
[22:09] <lazyPower> hatch: and to note, its manual provider
[22:09] <Saviq> hatch, but to experiment, I've nested a "juju" container and want to do everything inside there before moving to the "parent"
[22:09] <Saviq> hatch, fwiw, CLI deploy seems to be doing just fine
[22:09] <hatch> I believe you should be fine then
[22:09] <hatch> ok great
[22:10] <hatch> we do that to avoid the silent failure issues :)
[22:10] <Saviq> hatch, thanks
[22:11] <hatch> Saviq: if you hit Shift+/ or ? then a menu will pop up which shows "Custom GUI Settings"
[22:11] <hatch> you can also use that to enable the containers
[22:12] <Saviq> hatch, hah, cheat codes!
[22:12] <hatch> haha yup :)
[22:12] <hatch> next up - konami code!
[22:12] <lazyPower> hatch: would be cool to play pong with the charm icons :)
[22:12] <hatch> lol
[22:12] <hatch> that would be very cool
[22:12] <Saviq> hehe
[22:18] <hatch> lazyPower: https://bugs.launchpad.net/juju-gui/+bug/1401687 :)
[22:18] <mup> Bug #1401687: force enable container support from machine view <juju-gui:New> <https://launchpad.net/bugs/1401687>
[22:19] <lazyPower> hatch: +1
[22:21] <Saviq> 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] <hatch> hmm, that was fixed at one point
[22:26] <hatch> let me check dev
[22:27] <hatch> Saviq: this is definitely a reintroduced bug
[22:27] <Saviq> hatch, want me to file one?
[22:27] <hatch> I'd love that
[22:27] <hatch> https://bugs.launchpad.net/~juju-gui
[22:27] <hatch> :)
[22:28] <hatch> wait that's the wrong link
[22:28] <hatch> lol
[22:28] <hatch> https://bugs.launchpad.net/juju-gui
[22:28] <hatch> there we go
[22:28] <Saviq> yeah it looked weird
[22:28] <hatch> (off by one character error) ;)
[22:30] <Saviq> hatch, bug #1401697, let me know if you need a screenshot
[22:30] <mup> Bug #1401697: Controls panel overlays bottom of config pane <juju-gui:New> <https://launchpad.net/bugs/1401697>
[22:32] <hatch> Saviq: I know what you mean but whomever gets assigned the bug may not so a screenshot would be helpful
[22:33] <hatch> thanks thanks for filing the bug!
[22:34] <Saviq> ok, a piece of a screenshot added, hopefully clear
[22:34] <hatch> yup very, thanks