=== thumper-gym is now known as thumper-hacking === vednis is now known as mars_f === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === thumper-hacking is now known as thumper [04:23] hey, guys, where are the docs for juju's command-line switches? things like --config= --debug -v that kind of stuff [04:24] I do not see it in $juju help commands [04:24] manpage also doesn't have it, or https://juju.ubuntu.com/docs/commands.html [04:25] * ehw just wants to specify which environment he's using [04:25] You found the ones I have used, --debug and -v [04:25] matt_B: completely incidental; just passed along through oral history [04:26] Is anyone able to issue juju debug-log with a local setup? I get an error and found a bug report for it, but no workaround. [04:27] https://bugs.launchpad.net/juju-core/+bug/1202682 [04:27] <_mup_> Bug #1202682: debug-log doesn't work with lxc provider

[04:27] matt_B: dug a bit more, switches are documented in the different commands; i.e. juju help deploy [04:27] Thanks _mup_ got that number too, was wondering if any of the smart people here have worked around that [04:28] thanks ehw, I will add that to my oral history [04:28] hehe [04:28] and for the record, juju switch is what I was looking for [04:28] When I sing tails of juju I will include juju help deploy === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === _mup__ is now known as _mup_ === freeflying is now known as freeflying_away === axw_ is now known as axw === CyberJacob|Away is now known as CyberJacob === freeflying_away is now known as freeflying [09:11] <_mup_> Bug #1249248 was filed: juju-charms for Wordpress doesnt work-Wordpress agent status reported as "install-error" === freeflying is now known as freeflying_away [12:02] hi, could I inderest someone into reviewing this one liner diff from the apache2 charm [12:02] that is causing hook errors for me? [12:02] https://code.launchpad.net/~ahasenack/charms/precise/apache2/apache2-no-failing-juju-log/+merge/194403 === andreas__ is now known as ahasenack [12:04] it fixes #1249016 [12:04] and this silly error [12:04] <_mup_> Bug #1249016: Shouldn't log the relation data [12:04] 2013-11-07 16:39:39 INFO juju.worker.uniter context.go:255 HOOK OSError: [Errno 7] Argument list too long [12:56] ahasenack: I'll take a look today [12:58] marcoceppi: thanks === gary_poster|away is now known as gary_poster [14:03] hello everyone! [14:04] I am adding the hosts manually, but after I run the "juju bootstrap", I see the following message: [14:04] ERROR cannot create new info for environment "null": chown /home/allods/.juju/environments: operation not permitted [14:35] nesusvet: run `ls -lah | pastebinit` [14:41] marcoceppi, http://pastebin.com/hfEzJJR1 [14:43] nesusvet: interesting. Can you rename "null" to something else in the environments.yaml? Say "manual" or another name other than null? [14:43] ok, I will [14:45] http://pastebin.com/6DXthB4u [14:46] the result is http://pastebin.com/Rs59pU4H [14:47] nesusvet: I've not seen that before [14:47] rogpeppe: thoughts? ^^ [14:51] strace result: http://pastebin.com/FPiDJmtJ [14:53] nesusvet: run juju destroy-environment, then try to bootstrap again [14:54] ERROR environment has no bootstrap configuration data [14:54] nesusvet: rm -f ~/.juju/environments/my.jenv, try to bootstrap again [14:55] allods@a1base:~/.juju$ rm -f ~/.juju/environments/my.jenv [14:55] allods@a1base:~/.juju$ juju bootstrap [14:55] ERROR cannot create new info for environment "my": chown /home/allods/.juju/environments/my.jenv: operation not permitted [14:56] juju version [14:56] 1.16.3-precise-amd64 [14:57] :\ nesusvet one second, let me try to replicate [15:02] marcoceppi, ok [15:16] marcoceppi: looking [15:18] nesusvet: what user are you running as? [15:19] what do you mean by "running as" [15:19] nesusvet: what does "id -a" print? [15:19] uid=60001(allods) gid=60001(allods) groups=60001(allods),27(sudo) [15:19] nesusvet: ha, thought so [15:20] nesusvet: what does "echo $SUDO_USER" print? [15:20] nesusvet: hmm, actually i'm probably wrong [15:20] nothing ) [15:20] nesusvet: i am [15:20] :-\ [15:21] what does "echo $SUDO_USER" print? - nothing [15:21] nesusvet: yeah, i wondered if some particular logic was kicking in, but it seems it probably isn't [15:22] so, as far as I understand we are still looking for a reason ) [15:23] rogpeppe, I appologize, I don't know English well ). And afraid that I could miss something important [15:23] nesusvet: what do you see if you do: "chown allods.allods ~/.juju/environments/my.jenv" ? [15:24] nesusvet: ah, hold on [15:24] nesusvet: what do you see if you do "env | grep SUDO" ? [15:25] SUDO_USER=nesusvet [15:25] SUDO_UID=1000 [15:25] SUDO_COMMAND=/bin/su allods [15:25] SUDO_GID=1000 [15:25] ah ha! [15:25] i thought so [15:25] right [15:25] that's a bug in our code [15:26] nesusvet: for the time being there's an easy workaround [15:26] nesusvet: export SUDO_UID="" [15:26] nesusvet: it's strange that your "echo $SUDO_USER" printed nothing, BTW [15:27] rogpeppe: interesting, is this if someone does a sudo su - ? [15:27] So, what should I do next? ) [15:27] nesusvet: i will propose a fix [15:27] (handshake) [15:27] nesusvet: do what i said - that will cause your bootstrap to work ok [15:28] thanks rogpeppe! [15:28] marcoceppi: yes [15:28] Yeah, thanks you very much ) [15:28] marcoceppi: we are assuming that if SUDO_UID is set then the effective user id is root [15:28] marcoceppi: it's actually a nasty hack caused by the fact that the local provider needs to run as root [15:28] ah, instead of trying to use that value? [15:29] marcoceppi: it should check the euid [15:29] marcoceppi: the whole situation is unfortunate - we shouldn't need to run as root, but it's not easy because lxc requires root. [15:30] rogpeppe, I did chown allods.allods .... [15:30] but still can the same [15:30] nesusvet: yeah, that's not the problem i'm afraid [15:31] juju bootstrap [15:31] ERROR environment has no bootstrap configuration data [15:31] nesusvet: the problem is that juju is trying to do the equivalent of: chown nesusvet.nesusvet my.jenv [15:31] nesusvet: ah, yes, sorry, you'll need to remove the .jenv file [15:31] nesusvet: or run juju destroy-environment my [15:35] I sshed under allods and everything works fine ) [15:36] so there is a reason definitely [15:36] in sudo [15:37] nesusvet: cool [15:55] hi, I've just used maas to deploy the boostrap node with bonded nics. However, I see no sign of juju on the server. Mongo startsup if I start it manually but ENABLE_MONGODB=no is set in /etc/default/mongodb [15:55] Where should I look next to figure out whats happened / [15:55] ? [15:56] I see these: git lxc mongodb-server [15:56] installed [15:56] and no package seems to be in an error state from dpkgs point of view [15:57] the dir /var/log/juju is empty [15:59] gnuoy: what does sudo initctl list | grep juju show? [15:59] nothing [16:00] marcoceppi, it looks like /var/log/juju is the only sign of juju. I see no juju package [16:00] gnuoy: you won't see a juju package, juju doesn't get install from the archives [16:00] ah, ok [16:00] gnuoy: if there are no upstart jobs, then something went wrong durint the setup. Check the output of /var/log/cloud-init [16:01] (I think that's where the file is) [16:02] marcoceppi, thanks, looks like a dns problem https://pastebin.canonical.com/100172/ [16:02] marcoceppi, ta, I'll have a dig around [16:02] gnuoy: it looks like it's trying to find the maas server to download the juju tools, and failing [16:04] marcoceppi, yep, an empty resolv.conf probably isn't helping. [16:09] It seems I have a new issue. After bootstrapping server was unable to deploy successfully [16:10] Target server could't connect to mongoDB [16:10] and now I don't know what to do next. [16:12] nesusvet: so you were able to bootstrap without issue? [16:12] yes [16:13] nesusvet: can you descrive what you've done from bootstrapping to getting the error? [16:13] but the target machine shown a lot of spam that could't connect to localhost [16:13] 2013-11-08 15:50:47 DEBUG juju.state open.go:88 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused [16:13] nesusvet: what does your environments.yaml stanza for "my" environment look like? [16:15] http://pastebin.com/CwGjuaCG [16:16] nesusvet: what is GPT-bart-IM? [16:17] is target host [16:17] on which I should install agent [16:17] manually [16:17] nesusvet: is it your machine? Does that address actually resolve on your machine if you type `dig GPT-bart-IM`? [16:17] Yes, I can ping it [16:18] it's localhost [16:18] I mean I added this name into the /etc/hosts file on both servers [16:18] nesusvet: you shouldn't use your local machine as the bootstrap node [16:18] No, it's not local machine, it's target standalone server [16:19] ping GPT-bart-IM [16:19] PING GPT-bart-IM (192.168.206.63) 56(84) bytes of dat [16:19] nesusvet: where are you running these juju commands? From your desktop or that server? [16:19] from server, the server hostname is GPT-base [16:20] nesusvet: you shouldn't be running the juju commands from the nodes you indend to use. You should be running the juju commands from your computer [16:20] ohh. [16:21] so what should I do with server which has been deployed incorrectly [16:23] nesusvet: uninstall juju-core, run `sudo initctl list | grep juju- | awk '{system("sudo stop " $1)}'; sudo rm -f /etc/init/juju*` [16:26] thanks [16:26] I will [16:31] nesusvet, marcoceppi: could one of you please report the above problem as a bug, so i can refer to it when i'm proposing my fix? [16:31] rogpeppe: ack [16:32] marcoceppi: ta! [16:32] here On the lunchepad? [16:35] nesusvet: I'll create one on launchpad with the details from above [16:35] Please describe the bug in a few words, for example, "weather applet crashes on logout": [16:36] "JuJu bootstrap doesn't work under sudo environment" is it ok? [16:37] nesusvet: Yup, that'll work [16:45] https://bugs.launchpad.net/juju-core/+bug/1249418 here is [16:45] <_mup_> Bug #1249418: JuJu bootstrap doesn't work under sudo environment [19:18] http://askubuntu.com/questions/373161/juju-boostrap-for-ec2-fails-with-access-denied-but-working-credentials [19:18] I wonder if this is one of those env file issues again [19:23] jcastro: maybe [20:38] Hello juju community I have a question, hope this is the right place. I have a Java WAR file that I want to add to a charm. Would the best practice be to copy the Tomcat charm and just add this WAR file to the appropriate directory thus making a new charm. Or is it best practice to install the Tomcat charm and somehow use the WAR in a different charm. [20:39] I guess I don't know if that last option is possible, and looking for a little help. [20:55] It'd be cool to add a config option to the tomcat charm to allow you to bundle WARs [20:55] either via URL or in a war/ directory or something [20:55] but if you want quick and dirty fork the tomcat charm and just embed the WAR file [20:56] Thank you jcastro [20:56] Each charm runs in its own server/container/instance right? [20:57] So making a tomcat charm point at a different WAR charm would not work? [21:11] mbruzek: So there are several things you could do [21:13] marcoceppi, Which one would you suggest? [21:13] mbruzek: internet is a little flakey, one min [21:17] mbruzek: So, one option would be to create a configuration option, like "war_location" which would be an address that people could configure. Another, more interesting option, would be to create a tomcat-war subordinate charm. Subordinates are charms that don't get deployed as standalone, but instead get attached to existing deployed services. So what you could theoretically do, is juju deploy tomcat; juju deploy tomcat-war my-war-service; juju [21:17] add-relation tomcat my-war-service [21:17] in doing so, you could have multiple WARs deployed to a single tomcat server, which I feel like is something that's done in practice already [21:18] Can charms read each other's file systems? [21:18] then the generic tomcat-war charm would have a few configuration options, like "war_location", "path", "service_name", whatever would make sense for needing to deploy a war [21:18] mbruzek: yes and no. A subordinate charm can, because it's deployed alongside that service it's attached to [21:19] so tomcat-war as a subordinate, could read/modify anything the tomcat charm would because subordinates are co-located on the same server [21:19] a subordinate charm can, but can the master charm read the subordinate's ? [21:19] mbarnett, hello welcome here [21:20] mbruzek: yes, they're both on the same system. You tell juju where to "deploy" the subordinate via the add-relation command, as such no only are the on the same system but they also have an established relation to each other which they can use to communicate [21:23] mbruzek, https://juju.ubuntu.com/docs/authors-subordinate-services.html [21:23] mbruzek: the only real seperation you have with a suboridinate and a regular service, is they each have a different $CHARM_DIR [21:23] OK [21:23] mbruzek, subordinates do require some thought to get your mind wrapped around [21:24] _charms_ themselves have taken me some thought to wrap my head around. [21:24] mbruzek, :-) [21:25] * arosales thinks of sub example ... [21:26] rsyslog may be a good example [21:27] http://manage.jujucharms.com/charms/precise/rsyslog-forwarder is the sub in this case [21:27] there are no good examples, only zuul [21:28] marcoceppi, your thoughts on rsyslog-forwarder? [21:29] arosales: aside from the fact that, iirc, it's broken? [21:32] mbruzek: here's a list of all the subordinates in the charm store: https://manage.jujucharms.com/charms/precise?sub=1 [21:32] a simple one, like ntp or unattended-upgrades, might give you a better idea of their purpose [21:32] thanks marcoceppi [21:35] marcoceppi, I haven't deployed it lately, just recall it being a sub [21:35] marcoceppi, mainly looking for a code example on subs [21:35] arosales: mm, but if you try to deploy, at least if I recall what kirkland said, it doesn't actually work [21:37] marcoceppi: deploy what? [21:37] rsyslog-forwarder [21:37] kirkland: rsyslog/rsyslog-forwarder. IIRC a month or two ago you trued and it failed to work properly [21:37] marcoceppi, I trust you :-) [21:37] just the one I remember off hand [21:38] marcoceppi: ah, yeah, failed [21:38] marcoceppi, your link to the list of subs is much better to look at code examples [21:38] arosales: :) trying to remember if it was actually broken. We should file some bugs aginst it and fix it. Or something ;) [21:39] hum, this is one clint was maintaining, so it's maintainerless as well [21:39] * arosales was just looking for a bug on it [21:40] https://bugs.launchpad.net/charms/+bug/1078147 had a merge request from a while ago [21:40] <_mup_> Bug #1078147: rsyslog and rsyslog-forwarder charm review/merge [21:41] * marcoceppi facepalm. Both are marked as needs fixing, but it looks like both were updated recently [21:41] arosales: they need to have ~charmers re-assigned to them for a review in order to show up in the queue again. We need to make that policy when communicating to people who need to fix their merges [21:42] that and be a non "closed" state [21:42] Haw even made himself a maintainer of the charm [21:42] arosales: well, the merge requests are what matter, we don't see the bugs [21:42] arosales: https://code.launchpad.net/~hloeung/charms/precise/rsyslog/trunk/+merge/134024 [21:42] good point [21:42] If it's not assigned to charmers for review we effectively don't know about it [21:43] yup [21:43] arosales: what might be a better course of action is. After a charmer reviews it, they move the merge proposal from "Ready for review" to "In Progress", then re-assign charmers. That way the author only needs to move it to ready to review and not mess with assiging it again [21:43] * marcoceppi makes task to talk about review process on the list [21:45] arosales: do you see two "bip" charms on this page? https://manage.jujucharms.com/charms/precise [21:45] stays on our radar then [21:46] * arosales looks [21:46] marcoceppi, I do, one looks blank [21:46] same with bonne [21:47] same url end point [21:47] * marcoceppi files bug [21:47] marcoceppi, thanks thas a juju-gui bug in charm world [21:47] sinzui, ^ fyi [21:48] sinzui, sorry I think the juju-gui maintains that code now [21:48] juju-gui team [21:48] https://bugs.launchpad.net/charmworld/+bug/1249496 [21:48] <_mup_> Bug #1249496: Charms listed multiple times [21:49] arosales, We are in that code too to support the charmers. The gui team added versioned charms recently, and that has caused problems for code that thinks there is only one version of each charm [21:50] sinzui, thanks for the info and marcoceppi thanks for the filing the bug [21:51] and bonnie just needs a readme, ugh [21:52] arosales: the impending audit should resolve that [21:52] * marcoceppi piles on more tasks [21:53] * arosales files bug for bonnie [21:59] sinzui, on a different not mbruzek also ran into https://bugs.launchpad.net/juju-core/+bug/1202682 [21:59] <_mup_> Bug #1202682: debug-log doesn't work with lxc provider

[22:00] I found the bug on launchpad, and asked if there was a way around it [22:01] No known workarounds? [22:01] not that I see [22:02] mbruzek arosales: yes [22:02] mbruzek: all local logs are in ~/.juju/local/log [22:02] ahh. [22:02] mbruzek: they're loopback mounted in to the containers [22:03] mbruzek: arosales: the only two commands that dont' work with local right now are juju debug-log (see above) and juju ssh the latter can be solved with juju ssh though [22:03] * marcoceppi doesn't like debug-log that much anyways; too much information [22:03] mbruzek: you'll be interested in the log files prefixed with unit- [22:05] marcoceppi, ah interesting [22:07] I saw stokachu also commented on 'juju debug-log' not working with some attempts to workaround the problem [22:07] arosales: posted a comment to that bug with the workaround [22:07] arosales: this and juju ssh need to be documented on the local provider page asap if it isn't already [22:07] * marcoceppi thought it was === JoseeAntonioR is now known as jose [22:10] marcoceppi, thanks for https://bugs.launchpad.net/juju-core/+bug/1202682/comments/5 [22:10] <_mup_> Bug #1202682: debug-log doesn't work with lxc provider

[22:31] marcoceppi, Thanks for your help today I can see the log files now. [22:31] \o/ [22:31] mbruzek: thanks for reminding me that still exists, I'm updating the docs to reflect these caveats [22:32] I am sorry if that added anything to your task list [22:35] marcoceppi, feel free to also log a quick bug in juju-core and tag it with "docs" so we can follow up on it later too [22:35] mbruzek: worse things have happened [22:35] arosales: ack [22:35] going to finish logging these other bugs [22:36] marcoceppi, thanks [22:48] So, I've been browsing the charms lately and it looks like a lot of charms use a VCS (git, bzr, svn, etc). When I have been designing charms, I like to pull from a VCS and I prefer Git. I realize that the charms I want to use don't have a Git options. Also the charms I make, I only offer Git. [22:48] So my thinking is that it would be nice to create a VCS relationship that allow a service create a subordinate VCS charm, which pulls from a repository and updates it. The parent charm can just expose a folder to pull to. I really think this would help with the modularity of the charms. [22:48] Take for example the LAMP charm. It only uses Bzr for its repo. What if it just required a VCS charm, that way I can use whatever I want (git, bzr, svn, ftp, http, S3, etc). Is there anything like this already? What do you think about this? === freeflying_away is now known as freeflying [23:29] o/ jason955 I just replied to your mailing list post, didn't see the messages here [23:29] got it. Thanks Marco === freeflying is now known as freeflying_away === CyberJacob is now known as CyberJacob|Away