[02:05] <stub> cory_fu: yo
[05:00] <moqq> $ juju service add-unit papertrail  --to=10 >>> ERROR cannot add unit 1/1 to service "papertrail": cannot add unit to service "papertrail": inconsistent state
[05:00] <moqq> anyone know how i might be able to resolve such a thing?
[05:00] <moqq> juju status says literally everything is fine
[05:37] <moqq> well i just waited awhile and it seemed to start working
[06:16] <stub> lazypower: The best you can do is announce who the leader *was*, via leadership settings is easiest. By the time other units see it, it may no longer be true.
[06:18] <stub> lazypower: I haven't found a use case for actually doing this.
[06:27] <stub> if not leader_get('foo'): status_set('waiting', 'Waiting for leader to lead')
[10:24] <Prabakaran> Hi kwmonroe, Thanks for the email on my query. I have few more doubts and issues while generating layered specific file for my charm using charm build command.
[11:35] <apuimedo> marcoceppi: when deploying a charm, does it leave some trace on the machine where I execute the "juju deploy"
[11:55] <rick_h_> apuimedo: it does not
[12:01] <apuimedo> rick_h_: thanks ;-)
[13:16] <stub> With the reactive HTTP handler https://github.com/juju-solutions/interface-http/blob/master/provides.py , how do I write a config-changed hook that updates the port? I think I need to call configure() on the HttpProvides instance for each unit, but I can't see how to get that set of instances.
[14:20] <cory_fu> stub: You wouldn't use @hook('config-changed'), you would use @when('website.available') and then call website.configure(config('port'))
[14:21] <cory_fu> If you wanted to, you could wrap that in a data_changed() condition, but I think that relation-set is basically a noop if called with the same data, so I'm not sure it's necessary
[14:28] <stub> cory_fu: Yeah, I think I actually need to make this UNIT scope (I'm not using HTTP, just using it as an example trying to get my head around the relations stuff)
[14:32] <stub> cory_fu: http://pastebin.ubuntu.com/13931316/ (maybe to be a layer) and http://pastebin.ubuntu.com/13931345/ (the charm bit) is what I have so far. I haven't tested it at all yet, but I seem to need to implement it as UNIT scope even though to me it should be GLOBAL
[14:36] <stub> I need to hook into config-changed as that is how the operator changes the settings that need to propagate to the clients (or, in the simpler example, when the operator changes the HTTP port in the config)
[14:36] <kwmonroe> anyone have the syntax for exposing a service in a bundle.yaml?
[14:37] <stub> Similarly, I think we might need to propagate private-address changes (I think everyone is a little fuzzy on this, and nobody does it)
[14:38] <cory_fu> stub: The interface layer shouldn't contain implementation, and the charm layer shouldn't have to deal with converstations.  Also, reconfigure_syslog should also be @when('syslog.available') and you wouldn't have to do the manual from_name
[14:40] <tvansteenburgh> kwmonroe: expose: True
[14:40] <cory_fu> You don't have to explicitly handle config-changed, though.  When config-changed is triggered, it will run any handlers whose conditions are valid and those handlers can just ask "am I connected to syslog?  If so, send it the (new) config value"
[14:40] <tvansteenburgh> kwmonroe: (under the service)
[14:41] <kwmonroe> heh.. awesome tvansteenburgh.  so simple it hurts.
[14:41] <cory_fu> kwmonroe: I am surprised to see that our big data bundles don't expose any of the services by default.
[14:48] <kwmonroe> like what services cory_fu?  i don't think we should expose namenode (you can browse hdfs from there, so ashley madison).  i also don't think we should expose notebooks by default (same reason, with the added bonus of hdfs actions).
[14:48] <kwmonroe> that pretty much leaves benchmark-gui, and that has a big fat POST ME button, so maybe we shouldn't expose that one either.
[14:49] <cory_fu> kwmonroe: Hrm.  Fair enough.  It just seems weird to deploy a bundle with zero exposed services.  Like, how do you expect to use that?
[14:54] <kwmonroe> agreed -- i think it would be helpful to expose any service that has a service health dashboard.. maybe spark?  i dunno. as annoying as it is to be locked out by default, it's safer, and it's plenty easy to type 'juju expose'.
[15:07] <cory_fu> stub: So this is more how I would structure your example: interface: http://pastebin.ubuntu.com/13932246/ charm: http://pastebin.ubuntu.com/13932247/
[15:08] <cory_fu> That keeps the implementation in the charm layer and the communication protocol in the interface layer.  I'm not sure whether the log_line_prefix was supposed to come from the pgsql relation or config, but it doesn't matter, you'd just change the one line that sets that var (maybe remove the postgres condition on the when if it's not needed)
[15:09] <cory_fu> You don't have to explicitly react to config-changed (or pgsql changed), you just react to whether or not you have the things you need (attached loggers and maybe available pgsql) and then act accordingly
[15:11] <cory_fu> marcoceppi: That also touches on what we were discussing last night.  I'm back to thinking that it really should be the charm's responsibility to detect changes in values, because it may actually care about changes in state from multiple sources.
[15:15] <cory_fu> Though, if we had a reasonable way to react to "any of a set of states" it might still be useful for the interface layer to expose a "changed" state, but that's hampered by the difficulty in dealing with the difference between a state being set vs not
[15:16] <cory_fu> That is to say, if you say when_any(foo, bar) and only foo is set, then you can't get an instance of the bar relation because it might not exist
[15:16] <cory_fu> I guess it could just pass in None and leave it up to you to handle that.  Hrm
[15:18] <cory_fu> Or maybe @when_any should never provide values and you have to combine it with @when since you need that to have any reasonable assurance about what is available
[15:24] <marcoceppi> I'm interested but have no really feedback
[15:24] <mbruzek> Good morning cory_fu.  Question about interface layers.  I changed the code in the interface "peers.py" then re built the layer into a charm but I am getting the same error I saw before.  I realize that deleting the charm directory will likely solve my problem but I am certain that I fixed this before the re build and it was not picked up by new charm code that was built.
[15:28] <cory_fu> mbruzek: I think you are running up against https://github.com/juju/charm-tools/blob/master/charmtools/build/tactics.py#L232
[15:29] <cory_fu> mbruzek: That will be fixed by https://github.com/juju/charm-tools/pull/75
[15:29] <mbruzek> cory_fu: I used the --force flag when I built, should that not be honored in this case
[15:30] <cory_fu> mbruzek: It should be.  I think that line is in fact a bug.  Hence why I changed it in my PR
[15:31] <mbruzek> OK thanks cory_fu.  I will delete the charm dir and build again
[15:31] <mbruzek> as a temporary workaround
[15:31] <cory_fu> Yep, that'll work
[15:31] <cory_fu> mbruzek: Feel free to review that PR and offer your +1 if it looks ok to you
[15:31] <cory_fu> I know I still didn't add doc strings, though, so you'll probably -1 it
[15:32] <cory_fu> :)
[15:32] <mbruzek> cory_fu: confusing code needs to be explained
[15:33] <cory_fu> Yeah.  I need to spend some time going through that and adding a bunch of docstrings and comments
[16:00]  * stub has a think
[18:36] <roadmr> hey jujuers :) what's a good way to determine which version of the juju agent is running on units of a service?
[18:37] <mgz> roadmr: juju status tells you
[18:37] <roadmr> mgz: %) haha should have checked that first.
[18:39] <roadmr> mgz: indeed it does! thank you so much!
[19:43] <TheJeff> hey #juju
[19:43] <TheJeff> me again... I've started over.  Attempting to load up juju inside an lxc container
[19:44] <TheJeff> did deploy juju-gui --to lxc:0
[19:44] <TheJeff> stuck on installing charm software :(
[19:44] <TheJeff> logs to tail?
[19:44] <TheJeff> also if i run debug-hooks there's no ./hooks :(
[19:45] <rick_h_> TheJeff: should be a /var/log/unit/juju-guixxxxxxxx
[19:45] <rick_h_> TheJeff: or if it didn't get that far the all machines log
[19:57] <marcoceppi> TheJeff rick_h_ /var/log/juju/unit-juju-gui*
[19:58] <rick_h_> marcoceppi: doh ty for the correction
[19:58] <marcoceppi> also, /var/log/juju/machine-0.log