[01:31] <valeech> Not sure if anyone is around. I blew away juju beta 18 since I need to try the fixes in rc1. I have bootstrapped the controller on a maas 2.0 instance. I am trying to enable-ha with 2 additional controller nodes. The nodes get deployed by maas but they never get started in juju. they just stay at pending forever.
[05:23] <gennadiy> hi, we have private openstack cloud and we want to use different subnetworks for deployed software. is it possible to do it with juju 2.0 ?
[07:40] <stub> thedac: https://github.com/stub42/layer-apt has an example
[08:49] <zeestrat> Hey, what happened to juju set-model-config and get-model-config in rc1? I guess it's replaced by just juju config, however that seems to just work for applications.
[08:51] <Laney> hi!
[08:51] <Laney> What's the right way to re-run a relation-changed hook if there's no error state? (1.25)
[08:52] <Laney> I'm trying to deploy a website as a subordinate of apache2 and I want to do some iterating on the relation-changed thingy
[09:17] <Laney> ok, juju run works
[10:55] <SimonKLB> anyone here could tell me how to wait for a hook to finish using amulet? right now I'm testing setting a new config value and want to wait for that to finish before doing anything else, sentry.wait() doesn't seem to do the trick
[11:27] <RAJITH> Hello, while doing bootstrap I am getting ERROR failed to bootstrap model: cannot start bootstrap instance: Error calling 'lxd forkstart juju-a0744c-0 /var/lib/lxd/containers /var/log/lxd/juju-a0744c-0/lxc.conf': err='exit status 1'
[11:54] <beisner> hi SimonKLB - the best way is to have your charm set juju status when it knows it's ready.   then your amulet test can wait/block until it sees that status.
[11:55] <SimonKLB> beisner: i tried that too, the problem is that it doesn't have time to change to the "unready" status before i run the wait_for_status/wait_for_message function, so it thinks it's already done
[12:02] <SimonKLB> beisner: i also have the opposite problem where i'm testing unrelate->relate and the relate complains about the relation still existing because the unrelate doesn't have time to complete, in that case i tried waiting for the status as well, but it seems like the actual remove-relation operation isn't complety done before the status is set
[12:04] <SimonKLB> or at least the relation isn't cleaned up so that it's possible to add the same relation again
[12:05] <beisner> SimonKLB, could there be a bug in the charm's status updating logic?  ie. is it unsetting the status immediately when things start to shift?
[12:06] <SimonKLB> beisner: the status is set when the relation interface is no longer accessable, in this case: @when_not("identity-admin.available")
[12:07] <SimonKLB> could that be too early, and if so, what should i look for instead?
[12:09] <beisner> SimonKLB, in the openstack charms, we wait and check for all expected running processes on the units.  but that might not translate to every type of application.
[12:10] <SimonKLB> beisner: could you show me an example?
[12:14] <beisner> SimonKLB, the aodh charm is one reactive example.  https://github.com/openstack/charm-aodh/blob/master/src/reactive/aodh_handlers.py   which leverages a library: https://github.com/openstack/charms.openstack/blob/master/charms_openstack/charm.py#L768
[12:23] <SimonKLB> beisner: right, so i guess the difference is that you're not really basing your statuses on charm relations but rather on the actual services running on the machine?
[12:53] <beisner> SimonKLB, no not really. things like @reactive.when('shared-db.connected') trigger status to be reassessed
[12:59] <SimonKLB> beisner: i don't seem to find a when_not('shared-db.connected'), how do you handle the case where the relation is lost?
[13:00] <SimonKLB> or you want to change to a different database charm perhaps
[13:00] <SimonKLB> isn't it always going to think it's connected after it's been connected once?
[13:01] <beisner> SimonKLB, it looks like that charm doesn't handle that case.  probably because operationally it doesn't make sense to ever disconnect the service's database.
[13:02] <beisner> SimonKLB, but i think the principle illustrated there is:  you should re-assess status and set it, in nearly, if not all events.
[13:03] <SimonKLB> beisner: i guess not, perhaps im testing a case that actually isn't an issue, but i'm trying to fill the test requirement from the docs "Adding, removing, and re-adding a relation should work without error."
[13:04] <SimonKLB> beisner: yea, I agree, i think im not really taking the actual services into regard as much as you guys do though, im more looking at the state of the charm rather than the state of the services
[13:04] <SimonKLB> and that might be the issue
[13:40] <aisrael> If a deployed unit has two network interfaces, how does Juju select which one is the public and which one is the private?
[13:56] <jcastro> heya balloons
[13:57] <jcastro> I'm having a problem with adding credentials in a snapped juju
[13:57] <jcastro> actually, it all works, the question is semi-related
[13:57] <jcastro> do I need to mess with any of the juju bits in ~/snap
[13:58] <jcastro> or is .local/share/juju still the place to be?
[14:01] <balloons> jcastro, it's in the snap
[14:01] <jcastro> ok so let's say I add creds but then I want to manually mangle the file
[14:01] <jcastro> I would search in ... ?
[14:03] <balloons> jcastro, you would use juju cli commands ;-)
[14:03] <balloons> jcastro, I'm not sure off the cuff exactly where it is actually.
[14:04] <jcastro> right, but that's not what I am asking
[14:04] <jcastro> I was just thinking of adding it to the docs
[14:04] <jcastro> so like, yes, use the CLI obviously, but for reference we write config to foo, bar, baz, was my idea
[14:13] <jcastro> balloons: hah, everyone is going to make fun of me for filing this: https://bugs.launchpad.net/juju-core/+bug/1626576
[14:13] <mup> Bug #1626576: credential v. credentials is confusing <juju-core:New> <https://launchpad.net/bugs/1626576>
[14:15] <jrwren> jcastro: I did the same thing with controller v. controllers yesterday, but I thought it was just because I was tired.
[14:16] <rock_> Can't we remove published charm from store completely?
[14:16] <jcastro> you'd be surprised how worthless I am with juju now without bash-completion
[14:19] <lazyPower> rock_: You can set the ACL's of the charm as restricted, but i don't beleive there is a way to wholesale remove something, no.
[14:20] <lazyPower> rock_: eg: charm revoke
[14:21] <rock_> lazypower: oh. Thank you.
[14:23] <rock_> Can anyone please provide me detailed info of  juju networking.
[14:25] <rick_h_> rock_: what are you looking for in particular?
[14:28] <rock_> rick_h_: I am looking for basic juju netwoking model.
[14:30] <rock_> rick_h_: how juju manage networking inside and outside containers?
[14:31] <jrwren> rock_: other than what you see here: https://jujucharms.com/docs/stable/network-spaces  I think the answer is that it doesn't. It all depends on the provider. (aws, gce, azure, etc)
[14:31] <beisner> rick_h_, can you point me back to that bug about the home url not rendering on the cs side bar?
[14:31] <beisner> search foo is failing me ;-)
[14:39] <rock_> jrwren: ok. thank you.
[14:48] <balloons> jcastro, ~/snap/juju/*/.local/share/juju
[14:48] <jcastro> so ... ~/snap/juju/current/.local/share/juju should always just work then I figure
[14:48] <balloons> jcastro, I wouldn't make fun of you
[14:49] <balloons> jcastro, I don't seem to have current myself, so no..
[14:49] <balloons> it's a bit odd actually
[14:49] <jcastro> huh, none of mine do either
[14:49] <jcastro> did something change?
[15:39] <pweston> hello, does any one have a clear link for setting up juju to work with a pre-existing openstack
[15:39] <pweston> the simplestreams are killing me
[17:55] <hml> hi! i just bootstrapped juju2.0 to an private openstack cloud - the controller instance appears to be working okay, but when i deploy a charm, i end up with a unbuntu instance with no juju tools on it.  anyone else seen this?  know what to do?
[17:56] <rick_h_> hml: hmm, is there internet access to get the tools? is there anything in the debug-log on the controller (juju switch controller && juju debug-log)
[17:57] <hml> yes - i did a wget of a outside web page onthe charm instance
[17:57] <hml> didn’t see anything in the debug-log
[17:57] <rick_h_> hml: maybe check the log on the unit then. look for logs in /var/log/juju/unit*****
[17:57] <hml> there is no /var/log/juju on the unit :-)
[17:57] <hml> nor a /var/lib/juju
[17:58] <rick_h_> hml: oh hmm, makes sense if you never got the agents installed.
[17:59] <hml> rick_h_: i went thru some debugging yesterday with thedac, he was thinking the tools didn’t get installed and sent me here
[17:59] <rick_h_> hml: so how about juju logs in that directory on the controller unit
[17:59] <hml> rick_h_: let me double check
[18:03] <hml> rick_h_: i found the place in the machine-0.log that the new charm was deploy
[18:04] <hml> rick_h_: nothing is jumping out as a big error etc - is there a better log file to look at?
[18:12] <kwmonroe> hey #juju.. shilpa asked about an nginx charm, and i could have sworn we had a recommended version in the store... but i can't find it.  does such a thing exist?
[18:16] <kwmonroe> i only see nginx-passenger when searching (https://jujucharms.com/q/nginx), though i do see 10 other community charms when i deliberately 404:  https://jujucharms.com/nginx/
[18:16] <rick_h_> hml: no, maybe try debug-log with --replay to get everything?
[18:18] <kjackal> Is there a way to tell a controller (local in my case) to setup a IPv4 network instead of IPv6?
[18:20] <hml> rick_h_: looking
[18:26] <hml> rick_h_: this has happened 2 of 2 times so far - if i deploy another charm - what would be the best way to watch for errors as it goes?
[21:22] <lazyPower> kwmonroe: no nginx charm itself, we have layernginx though
[21:22] <lazyPower> (hours later)
[21:22] <lazyPower> https://github.com/battlemidget/layer-nginx  just fyi
[21:24] <kwmonroe> gratis lazyPower
[21:25] <kwmonroe> i think that url is https://github.com/battlemidget/juju-layer-nginx
[21:39] <petevg> cory_fu: do you have time to jump into the hangout? Zookeeper is misbehaving, and I'd like a second set of eyes on it.
[21:39] <cory_fu> Sure
[21:39] <cory_fu> Give me 1 sec
[21:41] <cory_fu> petevg: I'm in dbd
[21:44] <lazyPower> sure, whichever doesn't 404 :P
[22:34] <arosales> mbruzek: does the latest kubernetes charm set workload version?
[22:34] <mbruzek> arosales: you bet
[22:34] <arosales> or does anyone have a charm handy that setes workload version
[22:35] <arosales> ah ok
[22:36] <arosales> mbruzek: thanks
[22:36] <lazyPower> arosales: several
[22:36] <lazyPower> :D
[22:36] <lazyPower> https://jujucharms.com/u/lazypower/canonical-kubernetes
[22:36] <mbruzek> https://github.com/juju-solutions/kubernetes/blob/master-node-split/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L121
[22:36] <lazyPower> every charm in this bundle thats not a beats charm sets workload version
[22:36] <lazyPower> (oh and kibana because kibana)
[22:38] <arosales> lazyPower: thanks
[22:38] <arosales> and mbruzek thanks for the line ref
[22:39] <mbruzek> arosales: lazyPower did all the work, I just found the line he added
[22:39]  * lazyPower flexes
[23:26] <marcoceppi> arosales: the ubuntu charm sets workload version ;)
[23:53] <arosales> marcoceppi: ah, that may be a simple enough charm to take a look at
[23:53] <arosales> thanks marcoceppi
[23:53] <arosales> man I did a charm helper sync and now "get_platform" and now charmhelpers.osplatform module is not found
[23:54] <arosales> . . . and no results at http://pythonhosted.org/charmhelpers/search.html?q=get_platform&check_keywords=yes&area=default#
[23:54] <arosales> or http://pythonhosted.org/charmhelpers/search.html?q=platform&check_keywords=yes&area=default#
[23:54]  * arosales sigh
[23:57] <marcoceppi> arosales: wtf are you doing charmhelper-sync for
[23:58] <marcoceppi> arosales: it's also probably because you need to change your charm-helpers.yaml definitions
[23:58] <arosales> looking at adding workload status to the mariadb
[23:59] <marcoceppi> arosales: i already did
[23:59] <arosales> marcoceppi: which charm
[23:59] <marcoceppi> mariadb
[23:59] <marcoceppi> rev 5
[23:59]  * arosales looking at cs:~bigdata-dev/mariadb
[23:59] <marcoceppi> https://api.jujucharms.com/charmstore/v5/mariadb/archive/hooks/start