=== freeflying_away is now known as freeflying === freeflying is now known as freeflying_away [03:39] what's the format for deploying a charm that's not in the official charm store but is in a bzr repo ? [03:40] omgponies: local ? [03:41] without having to grab it local [03:41] looks like this works - juju deploy cs:~paulcz/precise/elasticsearch [03:42] yup, that is the format for a private charm store branch [03:42] thing [03:43] is there a flag for setting a version ... which I assume is the equivalent of the 'revision' file ? [03:47] omgponies: version is the value of the revision file in the root of your charm [03:47] or 1, by default [03:48] right, I mean during deployment [03:48] for instance 'revision' for the charm above is currently 50 [03:49] can I specify that so if some jerk does a breaking change I don't find out by surprise [03:49] omgponies: make a file called revision in the root of your charm [03:49] put the numer 50 in ther [03:49] oh, hang on [03:49] i see what you are asking [03:50] cs:~paulcz/precise/elasticsearch:$REVISION [03:50] is the full name [03:50] best to commit a revision file [03:50] hm [03:50] actualy [03:50] no [03:50] that may [03:50] probably not work [03:50] i don't think private charmstore branches have a concept of revision as strong as real charms do [03:50] there is only one revision of the charm [03:50] and that is head [03:51] right [04:16] is there a doc somewhere that describes everything that is available from the 'unit-get' command ? [04:18] omgponies: not really [04:18] from memory [04:18] public-address and private-address are the only useful ones [04:20] yup, sauce says those are the only two commands [04:20] thinking about from a monitoring perspective ... be able to get a list of units/services deployed to a box and a) set a useful hostname, b) determine what metrics to care about [04:23] omgponies: unit-get probably isn't going to be what you want [04:24] yeah I don't think there's any good way to get what I want [04:25] probably need something to stick in the middle that can correlate 'ip-10-29-206-28' to data from `juju status` === CyberJacob|Away is now known as CyberJacob === _mup__ is now known as _mup_ === axw_ is now known as axw === rbasak_ is now known as rbasak === dosaboy_ is now known as dosaboy [08:47] I don't have a public bucket for juju tools and use bootstrap --upload-tools to get them into a new environment. I've upgraded my client to 1.14 and now I want to upgrade the juju tools in existing environments. How do I do that ? I don't see an --upload-tools option to sync-tools [09:38] I do see --source for sync-tools and the comment suggests I can specify a local dir but I'm unable to spot the tools on the filesystem [09:47] ok, facepalm. I didn't know about: juju upgrade-juju --upload-tools [09:53] When talking about containers in https://juju.ubuntu.com/docs/authors-subordinate-services.html, is that a general term? Or is it referring to LXC, for example? === freeflying_away is now known as freeflying [10:51] allenap, I believe it is used in a general sense. That's another page that needs a good rewrite... [10:53] evilnickveitch: Cool, thanks. === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [12:16] <_mup_> Bug #1236824 was filed: boostrap tries to build jujud === freeflying is now known as freeflying_away === TheRealMue is now known as TheMue [14:49] <_mup_> Bug #1236900 was filed: tar: unrecognized option ''--numeric-uid'' [15:15] hello [15:16] we have changed our config.yaml for a service to add a new configuration option. How do we add that configuration option to an already running service? [15:22] drj11: you'll need to upgrade the charm [15:22] marcoceppi_: thanks. I thought so. and I thought we'd tried that. me and morty are working on it. we'll try again [15:23] marcoceppi_: thanks again [15:25] drj11: was the charm initially deployed from the charm store or from local? [15:26] adeuring: I've got a few comments on your merge for charm-tools [15:26] marcoceppi_: thanks, I'll look [15:26] adeuring: You're trying to find "maintainer" of the branch, but to be honest the owner of the branch is always going to be ~charmers for promulgated branches (or ~team) [15:26] adeuring: we don't do stacking anymore for promulgated branches [15:27] marcoceppi_: from local [15:27] marcoceppi_: we never use the charm store [15:28] drj11: gotchya, that shoudl work. You should be able to verify that the charm revision is bumped in the juju status [15:28] adeuring: so if a maintainer isn't in ~charmers (which is an expected case) then your function will fail [15:29] marcoceppi_: ok, so we might need a special rule for branches owned by charmers. But what if somebody deliberately want to fork a promulgated charm? In that case, this person should change the maintiner field. Otherwise, the official maintainers might receive undeserved "hate mail". [15:32] adeuring: It's an interesting case [15:33] I think an exception will need to be made for ~chamers for sure [15:34] adeuring: also, things like the the juju gui charm are maintained by "Juju GUI Team" not sure how this would handle that [15:35] marcoceppi_: let me look how this works with today data. [15:56] marcoceppi_: the GUI is acutally a good example: Sending a mail to the address given in the maintainer field (juju-gui@lists.launchpad.net) results in an error: "host polevik.canonical.com [91.189.95.64]: 550 unknown user". OTOH, the "real" mailing list (juju-gui@ubuntu.com) can't be checked either... Anyway, I#m open to sugegstion how else to check the sanity of the maintainer field. [15:58] ah, "juju-gui@lists.launchpad.net" would have worked, if the juju-gui team had set up this list on LP [15:59] adeuring: I think just making sure it follows "Full Name " would suffice. We don't take much responsibility for personal branches and these should be checked during finaly charm review [15:59] marcoceppi_: ok, I believe the check you suggest already exists, so let's abandon the MP [16:00] adeuring: I like the moving of the version to the package [16:02] marcoceppi_: yeah, that makes things easier for some changes, but taht's easy to include in as a drive-by fix in any real branch. [16:02] adeuring: I'll see how easy it is to just cherry pick that commit [16:03] marcoceppi_: ok, let me just revert the other changes, that's the most easy way, I beleive. [16:07] marcoceppi_: done [16:38] hi there, I bootstrapped a juju environment on openstack, then juju destroyed it. When I try to bootstrap again, juju says there's already a environment bootstrapped. Any ideas on how to fix this? Logs here: http://pastebin.ubuntu.com/6210041/ === teknico1 is now known as teknico [17:05] Hi Guys - I cannot get maas-tags to work with 14.1. According to the constraints documentation, it should. Any comments? [17:07] http://pastebin.ubuntu.com/6210186/ [17:09] 1.14.1 doesn't have maas-tag support [17:10] It was just added in 1.15.1, https://lists.ubuntu.com/archives/juju/2013-October/003019.html [17:10] kurt_: ^ [17:10] marcoceppi_: is 1.15.1 support on precise? [17:11] kurt_: all juju releases are available for all current supported ubuntu releases [17:12] Ok, guess its time to upgrade :) [17:12] no weekly update today? [17:12] kurt_: however, odd series, like 1.13, 1.15, etc are considered "devel" releases [17:12] so you need to get them from ppa:juju/devel [17:13] marcoceppi_: Ok, thanks. I may have it already. === jorge_ is now known as jcastro_ [17:33] marcoceppi_: in reading the readme for 1.15.1, I'm confused by this statement: "As an unstable release we do not make guarantees about clean upgrade [17:33] paths of running environments from one 1.13.x version to another." [17:44] kurt_: 1..X releases are development releases, they are not considered stable [17:45] For 1..X repleases you should be able to safely run `juju upgrade-juju` to upgrade from one stable juju release to another [17:47] marcoceppi_: right, but I am in fact going from 1.13.1 to 1.15.1. The statement appears to guarantee it will break. :) [17:58] kurt_: it shouldn't, it's just saying it might [17:58] once 1.16 comes out I recommend you sit on that release and move between 1. releases [17:58] marcoceppi_: ok, we'll see soon enough, I have it installed ;). And yep - how far is 1.16 out? [17:59] kurt_: it should be released sometime this month [17:59] iirc [17:59] cool, thanks [18:39] Does juju keep any local state of a bootstrapped environment? I keep getting an error: ERROR juju supercommand.go:282 environment is already bootstrapped even though I destroyed the whole environment.http://pastebin.ubuntu.com/6210041/ [19:02] matsubara: is this a local environment? [19:07] marcoceppi_, canonistack [19:08] marcoceppi_, btw, I updated juju-core to 1.15.1 and now when I destroy-environment, the command returns but doesn't seem to destroy anything (i.e. If I run the command again, I get the question if I want to destroy the env) === thomi_ is now known as thomi [19:32] jcastro: marcoceppi_: halp! [19:32] mhall119: what's up? [19:32] I'm trying to make my config-changed charm call my db-relation-changed charm to re-acquire my DB credentials [19:32] http://bazaar.launchpad.net/~api-website-devs/ubuntu-api-website/api-website-canonical-is-charm/view/head:/hooks/config-changed#L49 [19:33] but according to the charm log, that's failing: https://pastebin.canonical.com/98709/ [19:33] mhall119: yeah, because relation hooks get extra environment variables [19:33] marcoceppi_: so how can I make this work? [19:33] you can't really call relation-get out-of-band without supplying a relation-id [19:34] mhall119: what I've done in charms is record the data in a dot file in the $CHARM_DIR and read that in other hooks [19:34] marcoceppi_: line 48 of the config-changed hook gets a relation-id [19:34] mhall119: you need to record the $JUJU_RELATION_ID from the db-relation-changed hook [19:34] marcoceppi_: FWIW, this is derived from the internal certificaiton website charm [19:35] marcoceppi_: $(relation-ids db) won't work? [19:36] or is it that I need to set that to a named env var in the db-relation-changed hook before calling relation-get? [19:37] mhall119: db-relation-changed, when fired during a relation event, will already have the proper JUJU_RELATION_ID set [19:37] one second [19:37] ok, so if I fire it from config-changed I need to set JUJU_RELATION_ID=$DID when I call db-relation-changed? [19:38] mhall119: yes [19:38] instead of as $1 [19:38] $1 ? [19:39] * marcoceppi_ checks code [19:39] it was passing the relation id from $(relation-ids db) as the first argument to db-relation-changed when it called it [19:39] https://pastebin.canonical.com/98709/ [19:39] I mean [19:39] DID=$(relation-ids db) [19:39] [ -n "$DID" ] && hooks/db-relation-changed $DID [19:39] right, set it as an environment variable before executing the hook [19:40] ok [19:40] and is that the only one that needs to be set? [19:40] db-relation-changed, unless programmed to, won't know what to do with $2 [19:40] $1 [19:40] mhall119: you typically need JUJU_REMOTE_UNIT [19:40] but I think you can get away without it [19:41] I'm waiting for my desktop to come back online to double check [19:41] ok [19:44] marcoceppi_: could it have ever worked passing it as the first parameter? Like I said, this was taken from one of the IS charms [19:44] mhall119: depends on how the db-relation-changed hook is set up [19:45] mhall119: doesn't look like it [19:47] ah, ok, I see how it was being used before [19:48] marcoceppi_: on, new question [19:48] suppose I have a config parameter called bzr_revno, and in config.yaml for my charm I have it default to 1 [19:48] then, I update my app's code and I update the charm's config to make bzr_revno default to 2 [19:49] now I just found out that this doesn't actually call config-changed hook [19:49] is there *any* hook that would react to a change in the default config value? [19:50] mhall119: hooks/upgrade-charm - but that's only reacting to an upgrade-charm event. What I recommend you do is call hooks/config-changed from the upgrade-charm hook [19:50] and then when IS deploys a new version, upgrade-charm will be called? [19:51] mhall119: I don't know how IS does it, but if they use upgrade-charm, then yes, hooks/upgrade-charm will run [19:51] ok, I'll check [19:52] oh, hey, hooks/upgrade-charm is a symlink to hooks/config-changed [19:52] so it should be called anyway [19:52] :) [19:52] but it wasn't... [19:52] and I'm not sure why [19:52] check the logs? [19:52] https://pastebin.canonical.com/98709/ [19:53] also, run juju get api-website [19:53] see what juju thinks the value/defaults are [19:54] mhall119: there might be a thing where juju doesnt' update default values for configs when charms are upgraded [19:54] I could see that being the case [19:55] so you'd have to still call uju set api-website-app bzr_revno=37 [19:55] mhall119: if what I described above is true, then yes [19:55] ok [19:55] between that and needing to set JUJU_RELATION_ID, I think that explains the failure I was having [19:56] thanks marcoceppi_ [19:56] mhall119: np, let me know if you bump in to any other oddities [19:59] don't worry, I will :) [20:20] marcoceppi_: odd things going on with using maas-tags and deploying services http://pastebin.ubuntu.com/6210935/ [20:21] my tag matches an existing the host, the one the bootstrap node is on, but juju still wants to spin up a second node [20:45] kurt_, specifying a tag does not force two services to deploy onto the same machine [20:45] kurt_, you have to use --to todo that [20:47] jamespage: but if those hosts are not yet known to juju, how do you accomplish deploying services to those nodes? [20:47] kurt_, deploy one service first, and then deploy using --to for subseqent services [20:48] jamespage: how is handling moving on to the next node done then? [20:48] by co-locating services you are specifically telling juju that you are taking charge of where stuff lands [20:48] to add a new node just don't specify --to [20:49] right. but if I want specific services to land on specific nodes, and they are unknown to juju, this sounds like a problem [20:49] I get that I use --to. But when I need the next set of services on the the next node... [20:50] how do I force juju to use a particular node? I thought that's what the purpose of tagging was [20:50] tagging + constaints [20:52] kurt_, tagging is just a way of grouping servers [20:52] kurt_, juju will ask maas for a new unit which matches the provided tag [20:52] ok, but it doesn't appear that was happening [20:53] kurt_, thats not what it sounded like above "juju still wants to spin up a second node" [20:53] thats the correct result [20:55] jamespage: so if the node is already running that matches the tag, juju will look to deploy elsewhere without the "--to" function? [20:55] kurt_, yes [20:55] that doesn't seem intuitive [20:55] the node is already allocated to a service [20:55] so juju won't by default place another service on it [20:56] think about a deployment with 1000 nodes [20:56] where 400 are for storage and 600 are for compute [20:56] I can assign tags for 'compute' and 'storage' to the different server types [20:56] and then use juju to target nova-compute to 'maas-tag=compute' and ceph to 'maas-tag=storage' [20:57] or servers could be tagged per physical availability zone, or switch or whatever [20:57] Ok, when we talk about more servers in the tag group than a single server it makes sense [20:58] but in the context of a single node, it didn't [20:58] tags don't really make sense in that context [21:00] ok. makes sense. I am really looking for the one-size fits all hammer for juju. It just doesn't exist. [21:00] my "--force-to" option :D === natefinch is now known as natefinch-afk [23:15] is there a way to get the unit name from inside a hook [23:16] i.e. from juju status where I see 'services:\n elasticsearch\n ... units: elasticsearch/0