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