=== scuttlemonkey is now known as scuttle|afk === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === Spads_ is now known as Spads [09:58] jamespage, dosaboy, if either of you have a moment I'd like to get https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/next-1392645/+merge/241775 landed pretty sharpish [09:59] gnuoy, does that need a test case update? [09:59] jamespage, if it doesn;t then we're missing a unit test. let me fix it either way [10:00] gnuoy, +1 [10:17] jamespage, branch updated, just waiting for UOSCI to do its thing [13:10] jamespage, could you take another look at https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/next-1392645/+merge/241775 if/when you have a moment? [13:14] gnuoy, +1 [13:14] thanks [13:18] jamespage, would you mind extending your +1 to the stable equivalent https://code.launchpad.net/~gnuoy/charms/trusty/nova-cloud-controller/next-1392645/+merge/241799 ? [13:22] gnuoy, +1 [13:22] ta === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === alai` is now known as alai [14:17] does anyone know if config-changed is guaranteed to be called when a charm starts up? [14:17] fwereade: ^ [14:18] rogpeppe, essentially, yes [14:18] fwereade: ta [14:18] rogpeppe, if wecome up in an error state we won't call it until the error's resolved [14:18] fwereade: right, that's what i would expect [14:18] rogpeppe, but it's pretty much the first thing we do in ModeAbide: if c-c hasn't run yet for this instance of Uniter, run it [14:19] fwereade: but it'll be called after "start", right? [14:19] rogpeppe, before start [14:19] fwereade: ah, interesting [14:19] rogpeppe, which is a problem [14:19] rogpeppe, because "has the start hook run yet" is state we don't actually expose to the charm [14:19] fwereade: yeah, i was planning on restarting the service when the config changes [14:19] rogpeppe, so most charms, AFAIK, just assume they're always started, and always run their software in c-c [14:20] fwereade: that doesn't surprise me [14:20] fwereade: so the start hook is pretty much redundant [14:20] rogpeppe, you'd be technically wrong, but in good company, and constrained by not having a good way to do it right [14:20] fwereade: well, it would be easy to remember whether the start hook has been called or not [14:20] rogpeppe, well, IMO the true problem is that we don't expose have-you-started-yet as an env var [14:21] fwereade: but is that a bad thing to do? [14:21] rogpeppe, yeah, but it's be duplicated in every damn charm under the sun [14:21] rogpeppe, it's a good thing to do, but it's working around juju being bad [14:22] fwereade: perhaps the start hook really is somewhat redundant in fact, and could be deprecated [14:22] rogpeppe, mm, I think that stop/start are actually worthwhile [14:22] fwereade: is there some juju doc online that sets out the hook ordering guarantees succinctly? [14:23] fwereade: are you thinking about possible charm migration there? [14:23] rogpeppe, looking ahead to the possibility of migrating units and their storage from one machine to another, yeah [14:23] rogpeppe, https://juju.ubuntu.com/docs/authors-charm-hooks.html [14:25] fwereade: ah, that doc's perfect, thanks [14:26] fwereade: i guess if we always guarantee to call config-changed before start, we'd still be ok not implementing the start hook [14:27] rogpeppe, that is true [14:27] rogpeppe, I really ought to just expose started state in the env though [14:27] fwereade: that's true. although does that mean you should observe its value in every hook, and stop if it's not true... ? [14:28] rogpeppe, or maybe actually $JUJU_STOPPED, so a test for an empty STOPPED value comes closest to matching behaviour in old jujus [14:28] rogpeppe, I don't *think* so [14:28] rogpeppe, config-changed is the only hook that'll run when not started [14:28] rogpeppe, at least for now [14:28] fwereade: install :) [14:29] rogpeppe, sorry [14:29] rogpeppe, config-changed in the only hook that doesn't run in acontext where it can know whether it's started [14:30] fwereade: another unrelated charm question: where's a good place to put charm-specific persistent state? [14:31] rogpeppe, if it's only going to be read by the charm, I think the charm dir is actually fine probably [14:32] rogpeppe, the thing that freaks me out is writing stuff to the charm dir that will e read from outside a hook context [14:32] fwereade: what it's for example, a downloaded binary that is going to be used as an upstart service? [14:32] fwereade: or a config file for same [14:32] fwereade: that's the context i'm considering it in [14:33] rogpeppe, I would keep those outside the charm dir [14:33] fwereade: um, yes [14:33] rogpeppe, in my mind the dividing line is whether it's necessary for the software itself, or necessary for the management layer [14:33] rogpeppe, so templates used in hooks? fine in the charm dir [14:34] rogpeppe, stuff actually read by other processes? keep it outside, so that it's most likely to keep working even if juju manages to completely trash its own state [14:34] rogpeppe, fail as safe as possible [14:34] fwereade: i know one charm that's using /etc/init/$appname:$servicename [14:34] rogpeppe, that sounds sane to me [14:34] marcoceppi, does that sound like a reasonably-best practice to you? [14:35] fwereade: i'm not sure that's great though, as it's vulnerable to hulksmashing [14:35] rogpeppe, I'm pretty sure wedon't allow hulk-smashed units of the same service on the same machine [14:35] fwereade: i'd prefer to have the unit name in there too, and perhaps the env uuid too [14:35] rogpeppe, modulo subordinates [14:35] fwereade: interesting. i wonder why not - it seems potentially useful for testing. [14:36] rogpeppe, I don't think I have a well-reasoned answer to that beyond "it seemed like it opened more scary doors than useful ones" [14:37] rogpeppe, would indeed be useful for testing [14:37] fwereade: actually, that does work [14:37] rogpeppe, I think jam had some way around it? [14:37] fwereade: well, i'm waiting for the unit to come up... [14:37] rogpeppe, hmm, you can just do it? interesting [14:37] fwereade: yeah, seems to work [14:38] rogpeppe, and I see no code that would prevent it from so doing [14:38] jose: ping [14:38] rogpeppe, maybe it just got deleted when it was determined to be bloody hindering awkward for testing ;p [14:39] fwereade: well, i see a status with two started units from the same service on the same machine, which seems fairly clear [14:39] rogpeppe, yeah, and I remember it being akward code to write too [14:39] fwereade: yeah, i think it's reasonable - it falls out logically from the basic juju operations [14:39] rogpeppe, so, not really sorry to see it gone [14:39] rogpeppe, just puts a slightly heavier burden on the charm author [14:40] rogpeppe, and strongly pushes towards generating based on unit name [14:40] fwereade: if there was an easy way to get a name guaranteed to be unique to the charm, that would help [14:40] fwereade: because presumably with manual placement, it's possible to have services from several envs on the same machine... or maybe that's a step too far :) [14:41] rogpeppe, my suspicion is [14:41] rogpeppe, that that will fail in surprising and unhelpful ways, because of multiple machine agents trying to run at the same time [14:41] rogpeppe, and I have half an inkling that the manual provider code checks for pre-existing machine agents [14:41] fwereade: yeah, the upstart service names aren't named using the env UUID [14:41] rogpeppe, to prevent exactly that [14:42] rogpeppe, although [14:42] fwereade: otherwise it would probably be fine [14:42] rogpeppe, for general cleanliness' sake, we should absolutely be writing our code such that it should work [14:42] fwereade: oh, and /var/log/juju etc [14:42] fwereade: i wonder about $CHARM_UUID [14:42] rogpeppe, mm, I have a suspicion the machine agents would try to recall each others' deployed units [14:42] rogpeppe, UNIT_UUID? [14:43] fwereade: yeah [14:43] fwereade: although we've already got CHARM_DIR [14:49] jrwren: ping [15:00] pong [15:01] lazyPower: you have great timing. I had a question for you. [15:01] jrwren: awesome - whats up? [15:01] lazyPower: you first. You pinged first :) [15:06] lazyPower: ok, I'll ask first. https://juju.ubuntu.com/docs/authors-hook-errors.html says always return error code zero from hooks. OK. How do I return from a hook in a "bad configuration" state. e.g. charm was deployed with --config mycharmconfig.yaml and the state of that config mixes known bad options. [15:06] jrwren: was just following up on the fix you had for mongodb - did that make it as a backport to the precise charm as well? [15:06] I want the end user to somehow know their charm is misconfigured. [15:07] lazyPower: I know nothing about the precise charm. :( [15:07] jrwren: you can read the config in the install/config-changed hook and return 1 if there are bad options mixed. [15:07] but afaik you cannot do that on the CLI at present. it wont halt during pre-deployment [15:08] lazyPower: is there a way to return an error string so that status show "bad config" or something ? [15:09] jrwren: there's no state outside of "charm is in error" - the best case we have today is making sure you log the error in the unit log. [15:09] lazyPower: Thanks. That is the information I needed to know. [15:16] jrwren: can you take a look at getting your patches to the mongodb charm backported and MP'd against precise? [15:16] would be wunderbar! if you could. [15:18] lazyPower: I'll add it to my chalkboard, at the bottom. [15:18] thanks jrwren [15:25] lazyPower: My ETD on that is 2.5 years from now. === tvansteenburgh1 is now known as tvansteenburgh [15:53] rick_h_ natefinch: Great session! Lots of good info in there! If you missed it: http://summit.ubuntu.com/uos-1411/meeting/22387/whats-new-and-upcoming-in-the-work-of-juju-ui-engineering/ [16:24] lazyPower: https://bugs.launchpad.net/juju-core/+bug/1392786 [16:24] Bug #1392786: charm has no way to report error state [16:25] bazinga [17:51] marcoceppi: gaughen jose: who is going to present the Cloud & DevOps summary in an hour? [17:52] I'm still at conference [17:52] I think jose is at class, gaughen are you okay to do it? [17:52] don't think I have a choice [17:52] mhall119, I will be quick as I have another mtg [17:52] not unless you have an urgent need not to ;) [17:53] gaughen: you can go first, or last, if that would help you [17:53] mhall119, first would be perfect [17:53] now I need to go get my last session started [18:23] can anyone tell me if open-port is idempotent? [18:24] i.e. if i call it twice with the same port, will it succeed the second time? [18:31] rogpeppe: afaik, yes. I'm 90% sure. :) [18:31] jrwren: :) [18:31] jrwren: i'm just being lazy and not reading the source code tbh [18:32] rogpeppe: nothing wrong with that. charm authors shouldn't have to read the source code. [18:33] * rogpeppe is in that unusual position this afternoon :) [18:39] s/unusual/unaccustomed/ === CyberJacob|Away is now known as CyberJacob === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [20:57] rogpeppe: yes, iirc all juju commands are idempotent [22:50] lazyPower, ping [22:51] mwenning: hey, you need help with anything? [22:55] jose, I'm getting an error when I try to bring up juju - I'm behind a proxy and it keeps timing out. [22:55] can you help there? [22:55] mwenning: is that when bootstrapping? [22:55] https://pastebin.canonical.com/120521 [22:56] yes. [22:58] mwenning: not canonical, could you mind pasting it to paste.ubuntu.com? [23:03] jose, pastebin.ubuntu.com/9014361/ [23:03] thanks [23:04] mwenning: if you're using a proxy and the MAAS cluster is on your local network, then the proxy is probably the issue [23:04] can you access the MAAS admin site from your web browser? [23:06] jose, yes, that part's working fine. [23:06] hmm, I'm not sure then [23:06] this is more a MAAS thing than a Juju thing [23:06] I've been using maas to do Certs [23:06] you're getting a 502 (Service Unavailable) [23:07] jose, that's the maas server right? [23:07] mwenning: yeah. nothing related with Juju, unfortunately [23:07] sorry to not be of much help [23:07] looks like it's trying to access boot-images? [23:07] I can bring up a browser and touch that page just fine [23:08] mwenning: mind a quick PM? [23:08] PM? [23:08] private message [23:09] sure === CyberJacob is now known as CyberJacob|Away