[00:00] <davecheney> bummer
[00:00] <davecheney> the maas side maybe logging something more verbose
[00:00] <davecheney> maas to the client is very turse
[00:00] <davecheney> terse
[00:13] <zradmin> im back now, we had a bit of an isp issue
[00:13] <zradmin> in the logs its giving me a 401 (unauthorized) error now, it did let me deploy a few services before starting this behavior though. API keys are correct for maas
[00:19] <davecheney> zradmin: is that the juju log or the maas log
[00:19] <davecheney> from the little i know abut maas
[00:19] <zradmin> davecheney: juju log
[00:19] <davecheney> the client facing logs are pretty terse
[00:19] <davecheney> look inthe maas log
[00:20] <davecheney> that is where the juicy details are
[00:22] <zradmin> davecheney: just getting a more verbose version of the unauthorized message http://pastebin.ubuntu.com/6220330/
[00:23] <davecheney> bloody hell python
[00:24] <davecheney> what is an error and what is an exception
[00:24] <davecheney> look, i dunno if I can help you
[00:24] <zradmin> i know right?
[00:24] <davecheney> i don't have much maas experience and maas has clearlu decided that you don't own that resource
[00:24] <davecheney> and it won't be disuaded from that
[00:28] <zradmin> lame i cant even destroy the juju environment
[00:32] <zradmin> ok i removed the last node i registered with maas and now it process my destroy environment command
[00:32] <zradmin> very strange
[00:37] <davecheney> zradmin: i'm sorry to handball you, but you might get better advice in #maas
[00:39] <zradmin> davecheney: no problem I came here first because the juju update was the only thing that changed in the environment. Its working again now for some reason though so I'm fine at the moment, thanks for your assistance
[00:41] <davecheney> kk
[01:14] <julianwa> hello, how can I know which hooks will be called when I restart juju unit agent?
[01:15] <davecheney> julianwa: it depends on what the state of the unit agent was when you restart it
[01:16] <davecheney> in general, no hooks will be called
[01:22] <julianwa> davecheney: hmm.  Is there a document to tell what should be called under what state?
[01:22] <davecheney> julianwa: no
[01:23] <davecheney> but that wasn't really the question you first asked
[01:23] <davecheney> can I ask, what is the problem you want to solve ?
[01:23] <julianwa> davecheney:  does this described in charm?
[01:25] <davecheney> nope
[01:25] <davecheney> it's sort of in the docs
[01:25] <davecheney> but, you haven't answered my questoin
[01:26] <davecheney> the reason why i'm pushing back is the unit agent does not run the sevice
[01:26] <davecheney> if you stop the unit agent
[01:26] <davecheney> mysql doesn't stop, for example
[01:26] <davecheney> juju isn't a process manager
[01:26] <davecheney> the only way restarting would/wouldn't help would be if the unit agent was restarted *during* hook execution
[04:30] <jujulearner> hi guys
[04:41] <jujulearner> i need some help in bootstrapping a EC2 environment, can anyone spare a few minutes to help? Thanks!
[07:07] <Anju> hii anybody around?
[07:07] <Anju> where I can set path to set juju logs
[07:09] <Anju> anybody around?
[07:09] <Anju> ???????
[08:11] <freeflying> Anju, what do you mean set path?
[08:58] <Anju> freeflying:  are u there
[08:59] <Anju> sorry I was away
[09:23] <freeflying> Anju, what is your question about
[09:28] <Anju> freeflying:  i want to know if want to use juju in openstack
[09:28] <Anju> then where can i see the logs
[09:29] <freeflying> Anju, after you bootstrap, you can use juju debug-log to check the logs
[09:29] <Anju> yes I read this soemwhere
[09:29] <freeflying> Anju, and for sure, juju supports openstack, highly recommend to use :)
[09:29] <Anju> but all logs not save in a file
[09:30] <Anju> freeflying:  opensatck have many components
[09:30] <Anju> if ai want to see particular logs for a particular component
[09:30] <freeflying> Anju, you mean logs from openstack itself or the logs from the vm you start
[09:30] <Anju> I want logs of juju
[09:31] <freeflying> Anju,  juju debug-logs collect log from node it deployed
[09:31] <freeflying> Anju, and those logs are stored in the node juju deployed too
[09:32] <Anju> stored in the node juju deployed too ???
[09:32] <Anju> can you please tell me more
[09:32] <Anju> ?
[09:33] <freeflying> after you deploy ay service, you can juju ssh <service>/0 (the unit), and check the log under /var/log/juju/
[09:35] <Anju> ohhkkk
[09:35] <Anju> freeflying:  thanku so much
[09:36] <freeflying> Anju, np
[09:37] <Anju> freeflying:  did you use juju?
[09:38] <freeflying> Anju, sure
[09:38] <Anju> ohkk
[14:05] <jcastro> evilnickveitch, ok I've asked alanbell to check out the manual provisioning docas
[14:05] <jcastro> and see if we can get some feedback
[14:05] <evilnickveitch> jcastro, cool
[14:05] <jcastro> I'm going to ask some other people to try it too
[14:05] <evilnickveitch> I am working on the other configs
[14:05] <evilnickveitch> yes! that would be great
[14:06] <jcastro> jamespage, would today be a good day to ask about the openstack bundle or are you guys in release crunch still?
[14:11] <jamespage> bit cruchy still tbh
[14:11] <jamespage> but I can spin some time in-between helping zul push the second set of RC's from upstream
[14:11] <jamespage> jcastro, for the bundle what do you want?
[14:12] <jcastro> like so, are we going to publish it at a certain place or ... ?
[14:22] <jamespage> jcastro, it might be better after we actually land the changes for havana :-)
[14:22] <jamespage> those are still to be done
[14:22] <jamespage> well the changes are done; they are just not in the charm-store yet
[14:24] <jcastro> ok
[14:24] <jcastro> so in other words, I should wait
[14:39] <AlanBell> jcastro: did you?
[14:50] <jcastro> AlanBell, see your G+
[14:50] <jcastro> but here's the URL
[14:50] <jcastro> https://juju.ubuntu.com/docs/config-manual.html
[14:51] <AlanBell> oh cool :)
[15:00] <nesusvet> I tryied to deploy the node, but after deployment it returns: 2013-10-11 07:15:54 DEBUG juju.state open.go:88 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
[15:00] <nesusvet> hello everyone
[15:01] <nesusvet> I guess there a problem in different version on the mongodb
[15:01] <nesusvet> and I guess I should add the stable-juju repository to this file: /etc/apt/sources.list before installation, but I don't know how
[18:35] <ahasenack> hi guys, is that reported size the size of the charm? http://pastebin.ubuntu.com/6223679/
[18:36] <ahasenack> and, it copied it to my machine and then uploaded it to the bootstrap node?
[18:38] <ahasenack> hello, anyone here?
[18:40]  * sarnold waves to ahasenack :)
[18:40] <ahasenack> :)
[18:41] <sarnold> .. I've just got no idea. sorry. :)
[18:51] <ahasenack> sarnold: got it from the juju-gui guys, they are bundling the juju-gui tarball inside the charm now
[18:51] <ahasenack> sarnold: that's a 45Mb download from the charm store to my computer, and then a 45Mb upload from my computer to the bootstrap node
[19:09] <kurt_> jcastro: ping
[19:10] <Tim> Quick question: Is there a good place to follow development information and news? I'm trying to deploy juju on a very large cloud and I'm having a hard time finding current information on changes
[19:10] <Tim> like juju tools on s3
[19:12] <jcastro> kurt_, pong!
[19:13] <jcastro> Tim, there are two mailing lists
[19:13] <jcastro> juju and juju-dev
[19:13] <jcastro> You can sub to them from here: https://lists.ubuntu.com/
[19:13] <Tim> Ah, thanks. Keeping up with what works (and a lot that doesn't) has been a real headache
[19:14] <Tim> jcastro: Like the fact that the tools on s3 are currently a blank file ;)
[19:14] <ahasenack> Tim: really? what juju-core version do you have?
[19:14] <ahasenack> just curious if it's the recent 1.16 build
[19:15] <Tim> It is
[19:15] <Tim> 1.16.0-precise-amd64
[19:16] <ahasenack> Tim: and do you have public-bucket-url or tools-url defined in environments.yaml? Do you have a pastebin of juju bootstrap -v?
[19:16] <Tim> ahasenack: When bootstrapping I get 'WARNING no tools available, attempting to retrieve from https://juju-dist.s3.amazonaws.com/ ERROR Get https://juju-dist.s3.amazonaws.com/tools/releases/juju-1.16.0-quantal-i386.tgz: EOF'
[19:17] <Tim> I'll run it verbosely
[19:18] <jcastro> sinzui, ^^^
[19:18] <ahasenack> hm, the quantal url seems to be https://juju-dist.s3.amazonaws.com/tools/juju-1.16.0-quantal-amd64.tgz
[19:18] <ahasenack> I don't know about that "/releases/" path component
[19:19] <Tim> ahasenack: https://gist.github.com/timfallmk/6940517
[19:19] <Tim> The s3 tools download is new to me since I last tried juju
[19:20] <ahasenack> Tim: it's a fallback download. What is your environment?
[19:21] <ahasenack> Tim: I mean, is it aws, openstack, hp cloud, lxc, ...?
[19:21] <Tim> One in OpenStack, one in MAAS
[19:21] <Tim> and one in LXC :)
[19:21] <Tim> The one I'm trying now happens to be in MAAS
[19:22] <ahasenack> so looks like this time it downloaded the quantal tarball, but failing on the raring one
[19:22] <ahasenack> could it be a temporary error?
[19:22] <ahasenack> s/failing/failed/
[19:23] <Tim> ahasenack: Seems to be persistent
[19:23] <Tim> Also, I thought I had the tools installed from the initial repo
[19:23] <ahasenack> Tim: but above you pasted a line where it failed fetching the quantal tarball
[19:23] <Tim> Hmm, you're right
[19:23] <Tim> curious
[19:24] <ahasenack> but yeah, tools are a pain, there is always something slightly wrong
[19:24] <Tim> Weird, now it's giving me the failure for that
[19:24] <Tim> raring I mean
[19:24] <sinzui> Tim, I will look Your url is correct for 1.16.0 + and simplestreams
[19:25] <Tim> sinzui: I'm not sure why it would fail on quantal until I ran it with -v
[19:26] <Tim> sinzui: Hello, I just ran it with -v again, and it moved on to failing on saucy
[19:26] <Tim> so, to summerize, it fails persistently when run non verbosely. But can complete only the *next* step when run with -v each time
[19:27] <ahasenack> so weird
[19:27] <sinzui> Tim: interesting. I always run with --show-log (formerly -v)
[19:27] <Tim> ahasenack: Very weird
[19:27] <ahasenack> maybe it is always failing on the next on, but only -v shows you that
[19:27] <Tim> sinzui: IF I run it repeatedly until it completes everyone, then it moves on
[19:27] <ahasenack> s/on/one/
[19:28] <Tim> well it gives the failure line when run without v
[19:28] <Tim> and its always quantal
[19:28] <ahasenack> ah
[19:28] <Tim> ahasenack: or was
[19:28] <kurt_> Hi Guys - anyone know when 1.16 may be ready?  I'm looking for the fix to bug 1236734
[19:28] <_mup_> Bug #1236734: juju 1.15.1 polls maas API continually <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1236734>
[19:28] <ahasenack> kurt_: 1.16 is in the stable ppa, you can download it
[19:29] <Tim> ahasenack: Aha, its completed. Now I get the good old " gomaasapi: got error back from server: 409 CONFLICT"
[19:29] <Tim> thanks guys. Weird error
[19:29] <ahasenack> that's where my knowledge of maas ends
[19:29] <Tim> ahasenack: IT's maas node issue
[19:29] <Tim> :)
[19:29] <Tim> Thanks all!
[19:33] <sinzui> Tim have you set your tools-url:? For AWS it is https://juju-dist.s3.amazonaws.com/tools . This may not help since fallback is obviously looking in the correct place in the end
[19:39] <kurt_> ahasenack: does it include fix for 1236734?
[19:40] <kurt_> Tim: do you see that error consistently?
[19:45] <ahasenack> kurt_: I don't know
[19:46] <kurt_> ahasenack: ok, just looked it up.  Apparently it does… https://launchpad.net/juju-core/+milestone/1.16.0
[19:47] <jcastro> AlanBell, hey so https://bugs.launchpad.net/juju-core/+bug/1238934
[19:47] <_mup_> Bug #1238934: manual provider doesn't install mongo from the cloud archive <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1238934>
[19:47] <jcastro> I have failed you
[19:47] <jcastro> but I will try again!
[19:57] <kurt_> sinzui: ping
[20:08] <AlanBell> jcastro: aww :)
[20:08] <AlanBell> I will give it a go at some point over the weekend I think
[20:10] <AlanBell> mongodb with juju could well be interesting to me as it happens, http://exceptionalemails.com/ has a mongodb back end (plus some python and PHP bits)
[20:10] <AlanBell> but that was designed to scale out (not that it is likely to ever *need* to scale out)
[20:52] <Nik_> Hi all... I wanted to clarify a couple of things regarding hooks and sequence of events... Can someone help with that? for example, I am not sure when configuration-changed is invoked
[20:56] <Nik_> Does it get invoked when the service is initialy started or installed and does it get invoked when someone supplies --config to the deploy command
[20:57] <marcoceppi> Nik_: when a charm is deployed, the following hooks will run: install, config-changed, start
[20:57] <marcoceppi> Nik_: everytime `juju set` is run, config-changed hook will execute
[20:57] <marcoceppi> Nik_: so it'll always run at least once
[20:58] <Nik_> Cool good to know not to invoke it explicitly.
[20:59] <Nik_> Now does start get invoked if a relationships is optional: true?
[20:59] <Nik_> relationship^^
[20:59] <Nik_> err
[21:00] <Nik_> If relationship is optional: false (hence required), does start get invoked beffore the relationship joins?
[21:00] <Nik_> And yes, what's the meaning of optional: false in the requires: section
[21:01] <marcoceppi> Nik_: at this time all relations are optional, and setting them to false does nothing
[21:02] <marcoceppi> Nik_: that whole system isn't implemented yet, iirc
[21:02] <Nik_> Oh I see....
[21:03] <Nik_> And what about relaton-joined vs relation-changed.
[21:03] <Nik_> It said that changed gets invoked if the relation rejoins
[21:04] <Nik_> And I'm not clear on the part "rejoins" what does it mean? If a relationship departs after remove relation, isn't rejoining considered relation-joined?
[21:04] <marcoceppi> Nik_: that's not quite true. Relation-joined happens once per relation per unit, it's like the "install" hook of the relation sequence, relation-changed happens whenever there is new data on the relation wire, so the relations send stuff with relation-set and that triggers changed
[21:04] <marcoceppi> Nik_: yes, if you remove a relation, then re-create it, joined is run again
[21:05] <Nik_> Oh and new data on the wire means stuff like relation-set?
[21:05] <Nik_> But if relation-set is invoked multiple times
[21:05] <marcoceppi> Nik_: then changed will execute each time
[21:05] <Nik_> rel-changed will also get invoked mutliple times?
[21:06] <marcoceppi> Nik_: yes, all hooks need to be idempotent
[21:06] <marcoceppi> any hook could be executed multiple times
[21:07] <Nik_> Ok so then the client can simply keep restarting multiple times, if needed until it gets all the config values from the service
[21:07] <Nik_> Or, I guess a server can set some flag on the relation like done=yes to cause the client to read all the config information
[21:09] <sarnold> ahasenack: _wow_, 45M up and down, that's a significant deterrent to using juju-gui over e.g. a DSL line ..
[21:09] <ahasenack> yeah, that sucked a bit
[21:09] <ahasenack> as in, I can't deploy it from here where I happen to be now
[21:09] <sarnold> ahasenack: though I've seen enough complaints about charms needing access outside of a private cloud to deploy, and the trouble or impossibility of punching holes..
[21:09] <sarnold> ahasenack: heh, no more coffeeshop demos :)
[21:10] <ahasenack> sarnold: or outside of a big city in Brazil :)
[21:11] <sarnold> ahasenack: heh I thought even the small cities were big :) hehe
[21:11] <ahasenack> well, 200k inhabitants, but good adsl service only in the downtown area. 3km out and you are out of luck
[21:13] <Nik_> And I had one last queston (for anyone who can answer) ... Wen a server charm provides: my-service: interface:http for example just for clients, for the purpose of them obtaining its public address to the clients when they join the relation, is there a way for the server to specify that they are not interested in my-service-relation-joined so that juju doesn't spit out errors in the log that hook does not exist?
[21:14] <Nik_> I belive that juju executes my-service-relation-joined hook on the server and complains
[21:22] <sarnold> ahasenack: wow, I wouldn't have expected 3km to be the difference between good vs bad internet access..
[21:23] <ahasenack> yeah, sucks, here I get 1.5Mb/0.4Mb on a good day
[21:23] <ahasenack> downtown 15Mb/1Mb and up
[21:23] <sarnold> wow
[21:56] <AskUbuntu> MAAS Set password for node | http://askubuntu.com/q/356936