| === defunctzombie is now known as defunctzombie_zz | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| 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. | 00:59 |
|---|---|---|
| sarnold | ZonkedZebra: I think ssh to the unit, fix it up, and run juju resolved | 01:03 |
| davecheney | sarnold: ZonkedZebra | 01:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| ZonkedZebra | davecheney: I can figure that part out :) thanks | 01:09 |
| davecheney | ZonkedZebra: sorry mate, it wasn't my intention to talk down to you | 01:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| davecheney | but it's not top priority compared to other stuff we want to get done | 01:27 |
| 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:28 |
| 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:30 |
| davecheney | everyone has their price | 01:31 |
| cespare | can't argue with that | 01:31 |
| sarnold | hehe | 01:33 |
| 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:37 |
| 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:40 |
| cespare | davecheney: ok. | 01:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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) | 01:56 |
| cespare | I wish juju worked on digital ocean, that'd be cool | 02:02 |
| 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:03 |
| davecheney | but not documented because there are a lot of rough edges | 02:04 |
| cespare | davecheney: thanks for answering all my questions | 02:05 |
| davecheney | np | 02:06 |
| === defunctzombie is now known as defunctzombie_zz | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === defunctzombie_zz is now known as defunctzombie | ||
| === freeflying is now known as freeflying_away | ||
| === axw_ is now known as axw | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| 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 | 08:10 |
| === defunctzombie is now known as defunctzombie_zz | ||
| AskUbuntu | Set up nodes for Ubuntu cloud 12.04 | http://askubuntu.com/q/349867 | 11:48 |
| === freeflying_away is now known as freeflying | ||
| === cereal_b_ is now known as cereal_bars | ||
| AskUbuntu | Error on juju configuration for maas | http://askubuntu.com/q/349892 | 13:18 |
| marcoceppi | jamespage: ping | 13:34 |
| jamespage | hey marcoceppi | 13:34 |
| 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:35 |
| 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:36 |
| jamespage | marcoceppi, so the rationale is really about supporability going fowards right? | 13:37 |
| 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:38 |
| jamespage | marcoceppi, OK | 13:49 |
| 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 | 13:57 |
| marcoceppi | ehw: not that I know of, let me dig through the environments.yaml options | 14:05 |
| ehw | marcoceppi: thanks; was looking through the source, but it hasn't got any clearer for me | 14:08 |
| 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:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| adeuring | marcoceppi: could you please have a look here: https://code.launchpad.net/~adeuring/charm-tools/python-port-check-config/+merge/186080 ? | 14:17 |
| marcoceppi | adeuring: sure can! | 14:18 |
| adeuring | thanks! | 14:18 |
| marcoceppi | adeuring: while you're here | 14:18 |
| marcoceppi | REQUIRED_OPTION_KEYS = set(('description', )) - description is the only req key? I thought type was as well? | 14:19 |
| 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:21 |
| ehw | marcoceppi: done. pad.lv/1230306 | 14:29 |
| marcoceppi | Charm call, http://ubuntuonair.com and http://pad.ubuntu.com/7mf2jvKXNa | 16:03 |
| mattyw | I can't see anything on ubuntuonair? | 16:14 |
| marcoceppi | mattyw: http://www.youtube.com/watch?v=UPUO62DQiuw&feature=youtu.be | 16:16 |
| mattyw | marcoceppi, much better tnanks :) | 16:17 |
| mattyw | jcastro, can I ask some more questions? | 16:20 |
| mattyw | I know you love it | 16:20 |
| jcastro | sure! | 16:23 |
| jcastro | keep on keeping on! | 16:23 |
| 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:28 |
| === defunctzombie_zz is now known as defunctzombie | ||
| 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:29 |
| === defunctzombie is now known as defunctzombie_zz | ||
| mattyw | jcastro, I think that's all my questions actually | 16:41 |
| 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:43 |
| 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:46 |
| marcoceppi | config* | 16:47 |
| marcoceppi | jcastro: I think we did the charm call to soon? | 16:50 |
| jcastro | no it's always been at this time | 16:53 |
| jcastro | I just moved it to thr wrong spot | 16:53 |
| jcastro | fixed, thanks | 16:56 |
| === defunctzombie_zz is now known as defunctzombie | ||
| 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! | 17:58 |
| Cobold | Hi all! | 19:11 |
| AskUbuntu | Is there a juju PostGIS charm out there? | http://askubuntu.com/q/350035 | 19:56 |
| jcastro | hey popey | 20:16 |
| jcastro | huh | 20:20 |
| jcastro | hey guys check this out | 20:20 |
| jcastro | http://code.scenzgrid.org/index.php/p/jujucharms/ | 20:20 |
| jcastro | http://code.scenzgrid.org/index.php/p/jujucharms/source/tree/f906376d2ecba34e82e15b1e558e1b9e3c4d4ea1/postgis/precise/postgis/README | 20:21 |
| === CyberJacob is now known as CyberJacob|Away | ||
| rick_h_ | jcastro: used to be about every 15min | 21:57 |
| === freeflying is now known as freeflying_away | ||
| === thumper is now known as thumper-dogwalk | ||
| === thumper-dogwalk is now known as thumper | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!