[00:59] <ZonkedZebra> Hey. I'm developing a charm and trying to debug one of the hooks. What is the best to recover a node from an error state. According to the docs error state nodes don't run upgrade hooks.
[01:03] <sarnold> ZonkedZebra: I think ssh to the unit, fix it up, and run juju resolved
[01:03] <davecheney> sarnold: ZonkedZebra
[01:04] <davecheney> juju resolved --retry $UNIT && juju debug-hooks $UNIT
[01:04] <davecheney> will retry the failed unit
[01:04] <sarnold> ooh! --retry :) very nice
[01:04] <davecheney> then immediately (before that is actioned) start debug-hooks so you can run the unit yourself
[01:04] <davecheney> s/unit/hook
[01:05] <ZonkedZebra> in the debug-hooks it appears to drop be right before the script is exacted. Is there something functionality there I am missing? tailing /var/log/juju/unit-* has provided the best feedback so far
[01:06] <davecheney> ZonkedZebra: you get to run the hook, debug the hook
[01:06] <davecheney> the name of the hook will be in the $PS1
[01:06] <davecheney> so, if the hook that failed is config-changed
[01:06] <davecheney> at the prompt, type
[01:06] <davecheney> hooks/config-changed
[01:06] <davecheney> see where it breaks
[01:06] <davecheney> fix it
[01:06] <davecheney> run it again
[01:07] <davecheney> when you're happy that it has worked
[01:07] <davecheney> exit 0
[01:07] <davecheney> will take you to the next hook queued
[01:07] <davecheney> when you've processed all the hooks
[01:07] <davecheney> exit the final shell
[01:07] <ZonkedZebra> those changes will be saved on that node?
[01:08] <davecheney> no
[01:08] <davecheney> you will need to apply those changes to your charm
[01:08] <davecheney> then use something like
[01:08] <ZonkedZebra> Interesting, guess I can copy back out when done. I was just updating locally and then upgrading the charm
[01:08] <davecheney> ZonkedZebra: the best mental model of a chamr is to expect them to avaporate at any second
[01:08] <davecheney> any chanes done on the unit themselves are not saved anywhere
[01:09] <ZonkedZebra> davecheney: I can figure that part out :) thanks
[01:19] <davecheney> ZonkedZebra: sorry mate, it wasn't my intention to talk down to you
[01:21] <cespare> (very new to juju -- about 5 min into the docs) does juju set-constraints just change a configuration file?
[01:21] <cespare> I'm trying to understand how all these settings you're making would be shared with your team
[01:21] <cespare> I guess you keep your whole ~/.juju in version control?
[01:22] <davecheney> cespare: yeah, the .juju directory started simple but now contains a lot of files which all need to be on every client
[01:22] <davecheney> we're trying to address this
[01:22] <davecheney> but it won't happen on a timeframe useful to this discussion
[01:22] <cespare> davecheney: ok thanks
[01:23] <cespare> is there a way to use something other than .juju, perhaps with an env variable or something?
[01:23] <freeflying> does ceph charm need a second disk?
[01:24] <davecheney> cespare: you can move the location of JUJU_HOME with that environment variable
[01:24] <davecheney> freeflying: yes
[01:24] <freeflying> davecheney, any particular reason for the second disk? should only ceph-osd need a second disk?
[01:25] <axw> cespare: davecheney's right in general, but set-constraints in particular goes into the state database
[01:25] <cespare> davecheney: ok neato. So is just keeping JUJU_HOME in VC the recommended way of working as a team? The docs feel like they're addressed to a single dev or something
[01:25] <cespare> axw: oh ok, that makes sense
[01:25] <cespare> axw: that's mongo?
[01:25] <axw> yup
[01:26] <davecheney> cespare: i'd say it's a good idea
[01:26] <davecheney> we dont' have a recommendation
[01:26] <cespare> ok
[01:26] <davecheney> the contents of .juju are very much in flxu
[01:26] <davecheney> we konw that we keep too much state on dick
[01:26] <davecheney> err
[01:26] <davecheney> disk
[01:26] <davecheney> and are trying to fix it
[01:27] <davecheney> but it's not top priority compared to other stuff we want to get done
[01:28] <cespare> davecheney: i see. Are you saying that in an ideal world, your .juju would mostly just have enough info to point at the juju configuration server and everything else would be stored there?
[01:30] <davecheney> cespare: bingo
[01:30] <davecheney> would you like a job ?
[01:30] <cespare> Happy with the one I've got, thanks :)
[01:30] <cespare> Plus I could never use bzr for my dayjob. It wouldn't work out.
[01:31] <davecheney> everyone has their price
[01:31] <cespare> can't argue with that
[01:33] <sarnold> hehe
[01:37] <cespare> Is there something I can read about using juju to manage your own application? I suppose it's basically just going to involve writing a charm for it...but what about redeploying it when the code changes, monitoring, logging, etc?
[01:40] <davecheney> cespare: juju is configuration management
[01:40] <davecheney> it doesn't do monitoring or process management
[01:40] <davecheney> what it does do is define a framework for connecting services together
[01:40] <davecheney> the main driver was virtual environments like ec2
[01:40] <davecheney> when the names of the machines are not known ahead of time
[01:41] <cespare> davecheney: ok.
[01:42] <davecheney> process management is always tricky
[01:42] <davecheney> juju doesn't want to be the process manager
[01:42] <cespare> So how would juju help out if, say, I have an application that needs a database. Can I get it to just provision me some machines, and my deploy tool can ask juju for what the latest set of application servers are?
[01:42] <davecheney> ie, we don't want to, and in reality cannot demand that processes do not daemonise themselves
[01:43] <davecheney> cespare: sort of
[01:43] <davecheney> but not relaly
[01:43] <davecheney> juju lets you define an environemnt, a collection of services
[01:43] <cespare> and then I would want juju to invoke my deploy tool if i add more nodes...:\
[01:43] <davecheney> juju is your deploy tool
[01:43] <davecheney> you describe your environment, ie
[01:43] <davecheney> juju deploy wordpress
[01:43] <davecheney> juju deploy mysql
[01:43] <davecheney> juju add-relation wordpress mysql
[01:43] <davecheney> juju expose wordpress
[01:44] <davecheney> you don't describe machines, hosts, networks, firewall ports, etc
[01:44] <cespare> davecheney: that all makes sense. Does juju not help with my application servers at all?
[01:44] <davecheney> cespare: you'd have to be more specific what kind of help you are looking for ?
[01:44] <davecheney> for monitoring we have the idea of subordinate charms
[01:44] <davecheney> which let you descrive things like zenoss and nagios agents
[01:44] <cespare> well, like in my example. I have an application server that I'm hacking on and want to deploy frequently
[01:45] <cespare> (forget about monitoring and stuff for now)
[01:45] <cespare> it connects to a db that I brought up with juju deploy mysql
[01:45] <freeflying> davecheney, can we deploy ceph onto machine which only have 1 disk, and ceph-osd to machine has 2 disks
[01:45] <davecheney> you, you'd describe the process of deploying your application server as a charm
[01:45] <cespare> now, maybe I need to scale up the app server by adding more nodes, or maybe move the db to a different box...does juju do those things?
[01:45] <davecheney> freeflying: no, ceph rquires two luns
[01:46] <davecheney> you need to use constraints to make sure the unit is provisioned on a machine with that disk setup
[01:46] <davecheney> but, regretably,we haven't implemented those constraints yet
[01:46] <davecheney> cespare: juju does those things
[01:46] <freeflying> davecheney, what about ceph-osd then
[01:46] <davecheney> freeflying: that will work
[01:47] <freeflying> davecheney, one disk for osd will be fine?
[01:47] <davecheney> cespare: juju add-unit $SERVICE
[01:47] <davecheney> freeflying: i guess so, isn't it a dashboard or something
[01:47] <davecheney> cespare: juju has the model of one machine per unit of a sevice
[01:47] <cespare> davecheney: ok, so what does deploying version N+1 look like? You build a new version of the charm and then...
[01:47] <davecheney> cespare: you have two options
[01:48] <davecheney> 1. juju upgrade-charm, and write a hooks/upgrade-charm hook that will git pull your code or something
[01:48] <davecheney> or
[01:48] <davecheney> 2. juju destroy-service && juju deploy $SERVICE
[01:48] <davecheney> or juju deploy $SERVICE $NEW_NAME
[01:48] <davecheney> then destroy the old name
[01:49] <cespare> davecheney: do the subordinate charms break from the one machine per unit of service paradigm?
[01:49] <cespare> i.e. can I run the nagios charm with my app server together?
[01:49] <davecheney> cespare: yes
[01:49] <cespare> s/i.e/e.g
[01:49] <cespare> ok thanks
[01:49] <davecheney> cespare: yes, subordinate charms are deployed 'into' the machine that the thing they are subordinate too
[01:49] <davecheney> nagios isn't a subordinate
[01:50] <davecheney> its the server component
[01:50] <cespare> oh, the agent, whatever
[01:50] <davecheney> nagios-nrpe is the agent
[01:50] <cespare> yeah
[01:50] <davecheney> fair warning
[01:50] <davecheney> we understand that the one machine per service unit is a sucky requirement
[01:50] <davecheney> and makes it hard to have 'small' juju environemnts
[01:50] <davecheney> we'er working on fixing that with lxc containers
[01:50] <cespare> davecheney: yeah, saw that in the docs
[01:51] <davecheney> but there are complex problems, mainly around networking in hostile environemnts like ec2 and private openstack clouds which make the problem much harder
[01:51] <cespare> davecheney: sounds good, but actually for our infrastructure we pretty much have a machine per service
[01:51] <cespare> i mean (many) dedicated machines per service
[01:52] <davecheney> cespare: thta is why i say sevice unit
[01:52] <davecheney> the sevice is the abstract idea
[01:52] <davecheney> the unit is the physical manifestation of one instance of that service
[01:52] <cespare> davecheney: when a charm reacts to the upgrade-charm hook is it supposed to transform itself to the same state as if the upgraded charm were deployed to a fresh machine?
[01:53] <cespare> davecheney: good terminology
[01:53] <davecheney> cespare: as the charm author, we push a lot of that work onto you
[01:53] <davecheney> all we do is call the hook and wave our hands that it is your problem to figure out what that means
[01:53] <cespare> right, I'm asking if that's what I'm supposed to do as a good citizen
[01:53] <cespare> ok
[01:54] <davecheney> cespare: there are many ways of skinning the cat
[01:54] <cespare> davecheney: pretty easy if the application is a single jar/go binary
[01:54] <davecheney> you could also use a config variable to define the revision you want to use
[01:54] <davecheney> then your upgrade could be
[01:54] <davecheney> juju set revision=XXX
[01:54] <davecheney> which would fire the hooks/config-changed hook and you could do a git pull
[01:55] <davecheney> leaving upgrade charm to only change the actual code of the hooks/*
[01:55] <cespare> ah
[01:55] <davecheney> cespare: at it's core, juju is two things
[01:55] <davecheney> 1. a generic interface to varoius vm providers
[01:56] <davecheney> 2. a way of scheduling the remote execution of remote commands
[01:56] <davecheney> any assuptoins above and beyond that have to belong with the charm authors
[01:56] <davecheney> (we do push a lot of responsibility to charm authors)
[02:02] <cespare> I wish juju worked on digital ocean, that'd be cool
[02:03] <davecheney> cespare: we're working on a thing called manual provisoining
[02:03] <davecheney> which lets you supply machines via ssh
[02:03] <cespare> ah ok, still totally scriptable though heh
[02:03] <cespare> that would do the trick
[02:03] <davecheney> it's there in tip if you want to try it
[02:04] <davecheney> but not documented because there are a lot of rough edges
[02:05] <cespare> davecheney: thanks for answering all my questions
[02:06] <davecheney> np
[08:10] <jamespage> marcoceppi, please ping me when you start today re charm-tools update
[08:10] <jamespage> marcoceppi, as its pretty much a complete re-write I need more information before I go speak to the release team
[11:48] <AskUbuntu> Set up nodes for Ubuntu cloud 12.04 | http://askubuntu.com/q/349867
[13:18] <AskUbuntu> Error on juju configuration for maas | http://askubuntu.com/q/349892
[13:34] <marcoceppi> jamespage: ping
[13:34] <jamespage> hey marcoceppi
[13:35] <jamespage> marcoceppi, so a few questions re cloud-tools 1.0.0 if you have time
[13:35] <marcoceppi> jamespage: I've got all the time in the world for this
[13:35] <jamespage> marcoceppi, OK _ so I pulled the packages from the PPA and merged them into the main packaging branch in ubuntu
[13:35] <jamespage> then restored a few files under debian/* that had got dropped
[13:36] <jamespage> 1.0.0 is a complete rewrite in python right?
[13:36] <marcoceppi> jamespage: correct, the code is rewritten, the packagining is re-done, and the structure of the package changed
[13:37] <jamespage> marcoceppi, so the rationale is really about supporability going fowards right?
[13:38] <jamespage> as the current package is a mix of bash/python and not actively developed
[13:38] <marcoceppi> jamespage: the current package, 0.3, is no longer maintained. The re-write was to make charm-tools multi-platform and bring it's quality up
[13:49] <jamespage> marcoceppi, OK
[13:57] <ehw> hey, guys, is there any way to tell juju which lxc bridge name it should be using?  lxc works fine, but juju is failing with the net device not found error
[14:05] <marcoceppi> ehw: not that I know of, let me dig through the environments.yaml options
[14:08] <ehw> marcoceppi: thanks; was looking through the source, but it hasn't got any clearer for me
[14:09] <marcoceppi> ehw: there's two places for config options, one is in the providers code itself, then there's like this global options file that is env.yaml options for all environments
[14:13] <marcoceppi> ehw: it looks like there's an "JUJU_LXC_BRIDGE" environment variable you can set during bootstrap
[14:13] <marcoceppi> let me dig a little more
[14:13] <marcoceppi> ehw: oh, wait, that's for something different
[14:14] <ehw> marcoceppi: yeah, just tried that, didn't seem to get me what I needed
[14:14] <marcoceppi> ehw: line 42 of provider/local/environ.go has it hard-coded `const lxcBridgeName = "lxcbr0"`
[14:15] <marcoceppi> ehw: if you wanted that to be configurable, which isn't out of reason, you'd need to open a bug https://bugs.launchpad.net/juju-core
[14:15] <ehw> marcoceppi: yeah, looks like I'll be doing that
[14:17] <adeuring> marcoceppi: could you please have a look here: https://code.launchpad.net/~adeuring/charm-tools/python-port-check-config/+merge/186080 ?
[14:18] <marcoceppi> adeuring: sure can!
[14:18] <adeuring> thanks!
[14:18] <marcoceppi> adeuring: while you're here
[14:19] <marcoceppi> REQUIRED_OPTION_KEYS = set(('description', )) - description is the only req key? I thought type was as well?
[14:21] <adeuring> marcoceppi: http://bazaar.launchpad.net/~charmers/juju/docs/view/head:/source/service-config.rst says that "str" is the default type. so I assume that is not need to be specified (well, unless you want an int or float)
[14:21] <marcoceppi> adeuring: ah, gotchya, thanks
[14:29] <ehw> marcoceppi: done.   pad.lv/1230306
[16:03] <marcoceppi> Charm call, http://ubuntuonair.com and http://pad.ubuntu.com/7mf2jvKXNa
[16:14] <mattyw> I can't see anything on ubuntuonair?
[16:16] <marcoceppi> mattyw: http://www.youtube.com/watch?v=UPUO62DQiuw&feature=youtu.be
[16:17] <mattyw> marcoceppi, much better tnanks :)
[16:20] <mattyw> jcastro, can I ask some more questions?
[16:20] <mattyw> I know you love it
[16:23] <jcastro> sure!
[16:23] <jcastro> keep on keeping on!
[16:28] <mattyw> These pages: https://jujucharms.com/fullscreen/search/~mattyw/precise/docker-3/?text=docker
[16:28] <mattyw> how do they get generated? I expected them to update if I updated the charm - or after some interval - but they don't
[16:29] <mattyw> my 2nd question is: this is what I'm doing with the config http://bazaar.launchpad.net/~mattyw/charms/precise/docker/trunk/view/head:/hooks/config-changed. but it's not really config. is this how the framwork charms work at the moment?
[16:41] <mattyw> jcastro, I think that's all my questions actually
[16:43] <jcastro> the pages are generated ... nightly I think? rick_h_ do you know the interval?
[16:43] <jcastro> marcoceppi can answer the 2nd one
[16:46] <marcoceppi> mattyw: that hook looks fine. a lot of my charms do things like that in the conduit changed hook
[16:46] <mattyw> marcoceppi, ok cool, glad I get the basic idea
[16:47] <marcoceppi> config*
[16:50] <marcoceppi> jcastro: I think we did the charm call to soon?
[16:53] <jcastro> no it's always been at this time
[16:53] <jcastro> I just moved it to thr wrong spot
[16:56] <jcastro> fixed, thanks
[17:58] <jcastro> http://highscalability.com/blog/2013/9/25/great-open-source-solution-for-boring-ha-and-scalability-pro.html
[17:58] <jcastro> share/tweet/reddit/whatever please!
[19:11] <Cobold> Hi all!
[19:56] <AskUbuntu> Is there a juju PostGIS charm out there? | http://askubuntu.com/q/350035
[20:16] <jcastro> hey popey
[20:20] <jcastro> huh
[20:20] <jcastro> hey guys check this out
[20:20] <jcastro> http://code.scenzgrid.org/index.php/p/jujucharms/
[20:21] <jcastro> http://code.scenzgrid.org/index.php/p/jujucharms/source/tree/f906376d2ecba34e82e15b1e558e1b9e3c4d4ea1/postgis/precise/postgis/README
[21:57] <rick_h_> jcastro: used to be about every 15min