[06:31] <AskUbuntu> Bootstrapping Juju 1.13 to private OpenStack | http://askubuntu.com/q/329198
[07:33] <bbcmicrocomputer> fo0bar: ircd-charybdis promulgated..thanks for your work :)
[09:16] <stub> Has anyone running trunk (not) seen missing log messages from juju-log? Per https://bugs.launchpad.net/charms/+source/postgresql/+bug/1205082/comments/4
[09:16] <_mup_> Bug #1205082: Relation errors when deploying two units <postgresql (Juju Charms Collection):New> <https://launchpad.net/bugs/1205082>
[12:42] <pavelpachkovskij> guys, can I deploy charm from my custom launchpad repo?
[12:49] <ahasenack> pavelpachkovskij: you will have to branch it locally first, then use --repository and the local: prefix
[12:50] <pavelpachkovskij> that's quite clear
[12:50] <pavelpachkovskij> I thought there could be a way to do this remotely
[12:51] <ahasenack> no, the charm store syntax doesn't allow for custom charm stores
[12:53] <rick_h> pavelpachkovskij: I think if the branch is the right format it'll be available from the store: see https://juju.ubuntu.com/docs/authors-charm-store.html
[12:53] <rick_h> pavelpachkovskij: and you can see others like this in the new charms section of jujucharms.com
[12:54] <rick_h> then you can deploy the long charm name. cs:~matsubara/precise/tarmac-jenkins-0
[12:54] <rick_h> for instance
[12:55] <rick_h> pavelpachkovskij: see https://juju.ubuntu.com/docs/charms-deploying.html for some notes on those urls and the local option
[12:56] <pavelpachkovskij> rick_h, I'm trying to deploy this way, but get an error
[12:56] <pavelpachkovskij> juju deploy --config ~/projects/charms/precise/rack.yml cs:~pavel-pachkovskij/precise/rack-4  discourse
[12:56] <pavelpachkovskij> error: unknown option "repo"
[12:57] <pavelpachkovskij> but you can see here http://bazaar.launchpad.net/~pavel-pachkovskij/charms/precise/rack/trunk/view/head:/config.yaml
[12:57] <pavelpachkovskij> that there is this option
[12:57] <pavelpachkovskij> and if I do bzr branch it works well
[13:01] <ahasenack> the store has a table which tells it which bzr branch to use for a specific charm
[13:02] <ahasenack> the cs: prefix doesn't work for random branches, the store has to know about it
[13:02] <rick_h> pavelpachkovskij: k, I see your charm here https://jujucharms.com/sidebar/~pavel-pachkovskij/precise/rack-4/
[13:03] <rick_h> ahasenack: so it should be deployable I thought. We don't ingest charms into the gui that aren't in the juju go store.
[13:03] <pavelpachkovskij> rick_h, but it contains an old `Configuration`
[13:03] <ahasenack> rick_h: it's a matter of being deployable with the cs:~ syntax or not
[13:04] <pavelpachkovskij> rick_h, since then it had changed significantly
[13:04] <pavelpachkovskij> rick_h, and for some reasons 'Readme' is blank
[13:08] <rick_h> ahasenack: ok, haven't tried it, but had thought that if it's in the gui it can be deployed from the 'store'. Otherwise there's no point in showing it.
[13:08] <ahasenack> rick_h: the guy might just make a local copy and then deploy, I don't know
[13:08] <ahasenack> gui
[13:08] <pavelpachkovskij> rick_h, exactly, but looks like it doesn't update update config from the branch
[13:08] <rick_h> pavelpachkovskij: looking into it. I'll file a bug on the missing readme. There might be an issue with the charm
[13:09] <pavelpachkovskij> rick_h, this is my charm and there is a readme
[13:09] <rick_h> pavelpachkovskij: yes, I see the readme, but store says it's not there so I'll look into it/file a bug as I said ^^
[13:10] <pavelpachkovskij> rick_h, so as it doesn't try to parse new config.yaml
[13:10] <pavelpachkovskij> rick_h, so as metadata.yaml
[13:12] <rick_h> pavelpachkovskij: so basically whenever you submit a new branch of the charm our back end pulls the changes and updates things. If there's a problem it can't update and serves out the old data.
[13:13] <rick_h> pavelpachkovskij: I've got to look into what the problem might have been.
[13:13] <rick_h> pavelpachkovskij: so yes, I see you've updated the charm and such and that we don't have the latest data. I'll take a bit to figure out why that is.
[13:13] <pavelpachkovskij> rick_h, I see... How can I find what's the issue with it?
[13:13] <rick_h> pavelpachkovskij: did you run the charm proof tool against the charm?
[13:13] <pavelpachkovskij> rick_h, on first revision
[13:13] <rick_h> pavelpachkovskij: that usually catches most things from what I understand
[13:13] <pavelpachkovskij> rick_h, I'll rerun now
[13:14] <pavelpachkovskij> ➜  precise  charm proof rack
[13:14] <pavelpachkovskij> W: Maintainer address should contain a real-name and email only. [Altoros]
[13:14] <pavelpachkovskij> W: No icon.svg file.
[13:14] <pavelpachkovskij> ➜  precise  charm proof rack
[13:14] <pavelpachkovskij> W: Maintainer address should contain a real-name and email only. [Altoros]
[13:14] <pavelpachkovskij> W: No icon.svg file.
[13:14] <pavelpachkovskij> E: revision file in root of charm is required
[13:14] <pavelpachkovskij> could the last error be the issue?
[13:15] <pavelpachkovskij> In one of charmers meetings Marco told that revision file is no more required
[13:15] <rick_h> pavelpachkovskij: yea, that would do it
[13:15] <rick_h> pavelpachkovskij: make sure the proof tool is up to date maybe? /me checks that
[13:16] <pavelpachkovskij> charm-tools is already the newest version.
[13:18] <pavelpachkovskij> rick_h, I can try to push revision file and see if this is the issue
[13:27] <rick_h> pavelpachkovskij: yea, give that a shot please. I'll work on seeing if I can get access to the server and check the logs
[13:29] <pavelpachkovskij> rick_h, how long it takes to fetch data?
[13:30] <rick_h> pavelpachkovskij: should be aroud 15-20min usually
[13:30] <rick_h> pavelpachkovskij: can see here http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack
[13:31] <pavelpachkovskij> rick_h, ok, waiting
[13:50] <pavelpachkovskij> rick_h, nope, stays the same http://manage.jujucharms.com/~pavel-pachkovskij/precise/rack
[13:52] <rick_h> pavelpachkovskij: yea, looking
[13:55] <rick_h> pavelpachkovskij: so I'm running a script to pull it in locally and trying to find my notes on getting into the server logs. I'll ping back with what I find but will be a few.
[13:56] <pavelpachkovskij> rick_h, thanks
[14:28] <jcastro_> marcoceppi, I could have sworn we updated charmtools to not check for a revision file? ^^
[14:28] <rick_h> and he's gone...ugh
[14:31] <marcoceppi> jcastro_: Yeah, it should be fixed
[14:31]  * marcoceppi checks
[14:32] <rick_h> jcastro_: marcoceppi yea let us know and if there's a new version please file a bug on charmworld to update what version we're using in our proofing as well
[14:32] <rick_h> he said he had the latest but didn't verify
[14:32] <rick_h> issue was way beyond that
[14:33] <marcoceppi> rick_h: jcastro_: I see what I did. I fixed it in the wrong branch. Let me see if I can pop that change over to the current branch and kick off a package re-build
[14:34] <rick_h> marcoceppi: ah cool
[14:40] <aimatt> hello, I have juju bootstrapped, but a charm is stuck as pending
[14:40] <aimatt> it's mysql
[14:41] <juju> hi
[14:41] <marcoceppi> aimatt: what version of juju and what cloud environment are you using?
[14:41] <aimatt> marcoceppi: openstack
[14:41] <aimatt> checking version
[14:42] <juju> hi
[14:42] <aimatt> marcoceppi: it's the mac client version
[14:42] <aimatt> 1.11.2-unknown-amd64
[14:43] <marcoceppi> aimatt: Can you confirm that there are two running intances in the openstack dashboard?
[14:43] <marcoceppi> How long has it been pending?
[14:45] <aimatt> 14 hours
[14:45] <juju> what
[14:46] <juju>  8-)
[14:46] <aimatt> marcoceppi: the second instance never launched, it was always pending
[14:46] <marcoceppi> aimatt: Okay, typically it takes at most 10 minutes for the MySQL charm to come up (on even the slowest of providers) so there's something not quite right. Can you see two machines running in the dashboard? What does the machine state for machine 1 say?
[14:47] <marcoceppi> aimatt: okay, well that's the problem. What I'd do is `juju destroy-environment` bootstrap again, then deploy. If you're waiting more than 10 mins and the machine hasn't launched yet something went wrong.
[14:47] <juju> you are typing to fast
[14:47] <aimatt> ok
[14:47] <bryanmoyles> I've bootstrapped a few times over and I still ran into the same issue
[14:47] <marcoceppi> bryanmoyles: Are you also on the mac client?
[14:48] <bryanmoyles> Yeah
[14:48] <marcoceppi> bryanmoyles aimatt when you're running your commands, can you use the `-v` flag to get more verbose output?
[14:49] <bryanmoyles> when running juju deploy mysql?
[14:49] <marcoceppi> deploy, bootstrap, etc
[14:49] <bryanmoyles> bootstrap works just fine, machine-0 gets launched and is active, it's the deploy that breaks, even though juju said command finished
[14:50] <bryanmoyles> I'm in the process of wiping my env so I can't give you the exact output
[14:50] <juju> can you people meet me at aimatt
[14:50] <aimatt> juju spammer?
[14:51] <marcoceppi> bryanmoyles: that's fine, if you do run it again with -v I'd be interested in the output. Barring that /var/log/juju/* on the bootstrap node would be good to look at for possible reasons why it didn't launch
[14:51] <marcoceppi> aimatt: I'm not sure who juju is, but they appear to be just spamming the channel at this point.
[14:52] <aimatt> server moorcock.freenode.net
[14:52] <aimatt> :/
[14:52] <aimatt> k, Bryan will try verbose flags
[14:52] <juju> you are anoyen
[14:53] <bryanmoyles> well here's the question marcoceppi , I'm running the client on my local machine connecting externally to the private cloud, would the log files be on the hosted server or my local machine?
[14:53] <juju>  :@
[14:53] <marcoceppi> bryanmoyles: when you run juju commands, they connect to the bootstrap to relay the information. That's why the commands finish so quickly. The bootstrap node does all the orchestration. So the logs as to why machines failed to launch would be on the bootstrap node
[14:54] <bryanmoyles> and my ssh key should grant me access to that node? The problem I had with that earlier is that juju is creating an eth1 device on the physical server, that maps to the bootstrap node's local IP, hello recursion when i try sshing into the bootstrap node
[14:55] <bryanmoyles> did I miss something, my client is baaaad
[14:56] <marcoceppi> bryanmoyles: not yet
[14:56] <marcoceppi> bryanmoyles: SSH Key should be on the node, the eth1 device loop back thing is really odd though. It might explain why you're not getting any nodes to launch though.
[14:57] <bryanmoyles> so how do I prevent juju from creating it?
[14:57] <bryanmoyles> should I just tear it down after juju bootstraps?
[14:57] <bryanmoyles> Just out of curiosity, is it IRC proper to always include the name of the person we're talking to so you get pinged?
[14:58] <marcoceppi> bryanmoyles: my understanding is juju shouldn't be creating that, as it's not juju's job from my understanding, to mess with host as such. That's typically based on the image and cloud provider
[14:58] <bryanmoyles> well let me ensure that it is, one sec
[14:58] <marcoceppi> bryanmoyles: uh, probably. I do it out of habbit as I'm not always watching IRC
[14:59] <bryanmoyles> marcoceppi: alright, so right now ifconfig doesn't show an eth1 device, I'm almost at the point where I can just bootstrap again
[15:00] <mgz> bryanmoyles: it's probably useful to pastebin the config you're actually using
[15:01] <bryanmoyles> environments.yaml?
[15:01] <mgz> yup, unless it's trivial
[15:01] <bryanmoyles> http://collabedit.com/r5924
[15:01] <bryanmoyles> I'll start with the output first
[15:03] <mgz> that url is a redirect loop
[15:03] <bryanmoyles> Someone should also think to factor in a default constraint for juju bootstrap, it defaults to 64 MB of ram which runs out of memory -.-
[15:03] <marcoceppi> mgz: loaded for me
[15:03] <mgz> ah, borked with cookies disabled
[15:03] <mgz> go poor webserver coding
[15:03] <marcoceppi> bryanmoyles: it shouldn't, but you can use --constraints to set mem=1024, etc
[15:04] <marcoceppi> I really need to look in to the defaults because it seems recently a lot of people have been having this problem
[15:04] <bryanmoyles> I know, I just forget to and then it leads to head scratching
[15:04] <bryanmoyles> PS: I'm not all knowing, you just told me that yesterday lol
[15:04] <marcoceppi> bryanmoyles: also, you said you're using the mac version, what does `juju version` say for your local client?
[15:05] <marcoceppi> Because this is bootstraping/deploying 1.10.0, latest stable mac is 1.12.0
[15:05] <marcoceppi> which, iirc, had a bunch of openstack fixes in it
[15:05] <bryanmoyles> juju version is: 1.11.2-unknown-amd64
[15:07] <bryanmoyles> oh what the funk, all of my devices in ifconfig just went away?
[15:07] <bryanmoyles> all but 3
[15:07] <marcoceppi> bryanmoyles: try running `juju bootstrap --upload-tools` that should upload the most recent version of juju
[15:08] <bryanmoyles> I get a go error when I do that
[15:08] <bryanmoyles> one sec, sync-tools is running
[15:08] <bryanmoyles> 2013-08-06 15:08:40 ERROR juju supercommand.go:234 command failed: build command "go" failed: exit status 1; can't load package: package launchpad.net/juju-core/cmd/jujud: cannot find package "launchpad.net/juju-core/cmd/jujud" in any of:
[15:08] <bryanmoyles> 	/usr/local/go/src/pkg/launchpad.net/juju-core/cmd/jujud (from $GOROOT)
[15:08] <bryanmoyles> 	($GOPATH not set)
[15:08] <bryanmoyles> error: build command "go" failed: exit status 1; can't load package: package launchpad.net/juju-core/cmd/jujud: cannot find package "launchpad.net/juju-core/cmd/jujud" in any of:
[15:08] <bryanmoyles> 	/usr/local/go/src/pkg/launchpad.net/juju-core/cmd/jujud (from $GOROOT)
[15:08] <bryanmoyles> 	($GOPATH not set)
[15:09] <marcoceppi> bryanmoyles: Do you have go-lang installed on your machine?
[15:09] <bryanmoyles> thought I did, new-host-8:TrapCall_v2 bryanmoyles$ go
[15:09] <bryanmoyles> go      godoc   gofmt   gotour
[15:09] <bryanmoyles> new-host-8:TrapCall_v2 bryanmoyles$ which go
[15:10] <bryanmoyles>  /usr/local/go/bin/go
[15:10] <marcoceppi> hum, this is a bit out of my leauge. I don't have a mac machine at my disposal
[15:11] <juju> hi my friands
[15:12] <bryanmoyles> want me to hop on my ubuntu machine and work from there?
[15:13] <mgz> marcoceppi: we shouldn't be suggesting --upload-tools
[15:13] <marcoceppi> mgz: well, why is 1.12 client using 1.10 tools?
[15:13] <mgz> that's a dev option for building juju locally and using a trunk version
[15:14] <marcoceppi> How do you get the right tools on an openstack install?
[15:14] <bryanmoyles> juju sync-tools
[15:14] <mgz> right.
[15:14]  * marcoceppi smacks head
[15:14] <marcoceppi> I need to stop running trunk for a while
[15:14] <juju> hi
[15:14] <juju> ok
[15:15] <mgz> that doesn't answer the question of why the 1.12 tools are not being selected
[15:16] <bryanmoyles> is there a flag I can set for that?
[15:18] <mgz> no, but the -v output of sync-tools may be informative
[15:18] <bryanmoyles> I might add that sync-tools is the one actually uploading 1.10*
[15:18] <mgz> bootstrap is claiming 1.10 is the newest version
[15:18] <bryanmoyles> new-host-8:TrapCall_v2 bryanmoyles$ juju sync-tools
[15:18] <bryanmoyles> listing the source bucket
[15:18] <bryanmoyles> found 6 tools
[15:18] <bryanmoyles> found 6 recent tools (version 1.10.0)
[15:18] <mgz> whih implies the 1.12 tools weren't uploaded
[15:18] <bryanmoyles> listing target bucket
[15:18] <bryanmoyles> found 0 tools in target; 6 tools to be copied
[15:18] <bryanmoyles> copying tools/juju-1.10.0-precise-amd64.tgz, download 2205kB, uploading
[15:18] <bryanmoyles> copying tools/juju-1.10.0-precise-i386.tgz, download 2306kB, uploading
[15:18] <bryanmoyles> copying tools/juju-1.10.0-quantal-amd64.tgz, download 2209kB, uploading
[15:18] <bryanmoyles> copying tools/juju-1.10.0-quantal-i386.tgz, download 2311kB, uploading
[15:18] <bryanmoyles> copying tools/juju-1.10.0-raring-amd64.tgz, download 2208kB, uploading
[15:18] <bryanmoyles> copying tools/juju-1.10.0-raring-i386.tgz, download 2312kB, uploading
[15:18] <bryanmoyles> copied 6 tools
[15:18] <bryanmoyles> right, but I'm not sure how I would
[15:20] <mgz> bryanmoyles: try the --dev flag on sync-tools
[15:20] <mgz> I bet that will get you 1.13
[15:20] <rick_h> does anyone know the timeline for the store.juju.ubuntu.com picking up revisions? It's been a bit over an hour and it's not picked up r5 from earlier https://store.juju.ubuntu.com/charm-info?charms=cs:~pavel-pachkovskij/precise/rack
[15:20] <bryanmoyles> yessir it did
[15:21] <mgz> well, that will do.
[15:21] <rick_h> and wondering if I should be patient or go bug filing
[15:21] <marcoceppi> rick_h: I have no idea the timeline for syncing. I suspected it was like 15 mins but I appear to be wrong in that assumption
[15:22] <rick_h> marcoceppi: so charmworld is 15min, but charmworld (manage.jujucharms.com) checks in with store.juju.ubuntu.com for info and it's not catching up
[15:22] <marcoceppi> rick_h: ah, that's where I got the 15 mins from
[15:22] <rick_h> marcoceppi: yea, you're not completely crazy :)
[15:22] <marcoceppi> rick_h: hazmat might know
[15:23] <rick_h> yea, I figured I'd see if anyone knew around before I bugged hazmat as I imagine he's sprinting off in IoM
[15:25] <bryanmoyles> cloud-init start-local running: Tue, 06 Aug 2013 15:25:02 +0000. up 6.65 seconds
[15:25] <bryanmoyles> no instance data found in start-local
[15:25] <bryanmoyles> cloud-init-nonet waiting 120 seconds for a network device.
[15:25] <bryanmoyles> I wasn't getting networking timeouts before :(
[15:26] <mgz> bryanmoyles: I suspect an issue with your openstack setup more than juju here....
[15:26] <mgz> can you `nova boot` with some custom cloud init successfully?
[15:45] <bryanmoyles> I'm wiping again and scripting my setup process, after 10 times I think it's about that time lol
[17:27] <juju> is same body here
[17:28] <sarnold> 12 seconds. that's gotta be some kind of record. :)
[20:55]  * hazmat backlogs
[20:56] <hazmat> rick_h, i thought it was an hrly pull or less re store, looks like the charm is there, its out of dev hands atm
[20:56] <hazmat> ie. log access only
[21:11] <marcoceppi> Apparently my IRC bouncer is offline