=== mimizone_ is now known as mimizone
=== SaMnCo_ is now known as SaMnCo
=== arosales_ is now known as arosales
=== idobos_ is now known as idobos
=== coreycb_ is now known as coreycb
=== fenar_ is now known as fenar
=== plars_ is now known as plars
=== infinityplusb is now known as infinityplusb_
=== infinityplusb_ is now known as infinityplusb
[07:38] <kjackal_> Good morning Juju world!
[10:36] <magicaltrout> kubernetes hackers I have a snap pattern question for you
[10:37] <magicaltrout> it looks to me like you provide the snap as a resource
[10:37] <magicaltrout> how does the charm know an upgrade is available when you push a new snap k8s version?
[10:40] <kjackal_> hey magicaltrout
[10:42] <kjackal_> we provide the snap as a resource so as to deploy on network restricted environments. The resource is usualy a zero sized file and that causes the charm to go and fetch the snap from the snap store
[10:43] <magicaltrout> ah cool
[10:43] <magicaltrout> that solves that riddle
[10:43] <magicaltrout> i snapped up openldap and wondered how best to ship it
[10:44] <kjackal_> in the config of each charm we set a channel from which the snaps are fetched (eg, 1.7/stable). Everything we push to that channel you get it transparently. So if you deploy kubernetes now you will get the 1.7/stable channel and we will be pushing (through the snap store) all the 1.7.x updates
[10:45] <kjackal_> if you want to upgrade from 1.7 to 1.8 you should follwo the upgrade instructions that involve updating the channel in the charms config
[10:45] <kjackal_> magicaltrout: ^
[10:46] <magicaltrout> ah yeah the multichannel stuff as well, cause 1.7 branch updates should happen automatically right?
[10:46] <kjackal_> yes, that is ithe idea. 1.7.x releases of kubernetes should be compatible with eachother
[10:47] <magicaltrout> what happens when you screw everything up like conjure-up? ;)
[10:49] <kjackal_> we get fired... I guess
[10:50] <kjackal_> what do you not like about conjure-up ?
[10:50] <magicaltrout> i have no problem with conjure up
[10:50] <magicaltrout> but there was an email sent out last night saying it was borked
[10:51] <magicaltrout> and everyone will suffer cause of the rolling updates ;)
[10:51] <magicaltrout> https://lists.ubuntu.com/archives/juju/2017-July/009211.html
[10:51] <magicaltrout> that one :)
[11:31] <stokachu> magicaltrout:to be fair it wasn't conjure-up it was snapd
[11:52] <magicaltrout> indeed stokachu, I'm only ribbing ya'll, but I am curious about the checks and balances
[11:53] <stokachu> magicaltrout:yea obviously there are some additional validations that need to be made as this is a problem that affects a _ton_ of users
[11:53] <stokachu> in the same vein as how apt packages are handled
[11:55] <magicaltrout> yeah but also apt updates are generally user defined so you'd hope to find out about some massive issue on a small number of users before everyone gets it
[11:55] <magicaltrout> snaps automatic updating makes that harder I guess
[11:55] <rick_h> well it's trading one pain for the other. Otherwise you have folks with giant old xxx out there with holes in it left and right.
[11:55] <rick_h> but since they're afraid of touching production, wheeeee
[11:56] <rick_h> there was a post on that recently, let me find it. they're going to allow more control
[11:57] <magicaltrout> nice
[11:57] <rick_h> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/11
[11:58] <magicaltrout> looks sensible
[11:58] <rick_h> so the agreement is some additional knobs, but fundamentally the thing is servers ship with automatic apt updates as well and someone publishes a new apt package for something it hits.
[11:59] <rick_h> I think it's generally in line on both the snap/apt side to try to help keep these production microservices/scale out stuff safe by default
[11:59] <magicaltrout> thanks for those sage words rick_h
[12:00] <rick_h> heh, haven't had my coffee yet so :P
[12:00] <magicaltrout> I was saying on the drive in this morning that it makes sense, like "install charm a", forget about it, but keept it in sync via snap updates
[12:00] <magicaltrout> i like it so its certainly a pattern I'm trying to construct for my charms going forward
[12:01] <rick_h> yea, I think for a lot of folks it's something helpful. e.g. every self hosted wordpress ever lol
[12:01] <rick_h> and it helps with that idea of CI/CD we all think is the holy grail
[12:02] <rick_h> and hopefully folks use the different channels in there to beta test/etc
[12:42] <ak_dev> https://www.irccloud.com/pastebin/cFegoDAR/
[12:42] <ak_dev> There seems to be a problem with the above interface (peer)
[12:43] <ak_dev> the states go as such : .connected -> .unsigned.cert.available -> .signed.cert.available
[12:44] <ak_dev> .connected and .ip_request is set by the first charm and .master_ip.available and .signed.cert.available are set by theother
[12:45] <ak_dev> somehow, the relation state does not change after".signed.cert.available" , anything I could be doing wrong?
[12:45] <ak_dev> the ideal states should be such : .connected -> .unsigned.cert.available -> .signed.cert.available -> .ip_request -> .master_ip.available
[12:45] <ak_dev> thank you!
[13:28] <xnox> hi
[13:28] <xnox> where is the source code for https://jujucharms.com/u/containers/kubernetes-master/ ?
[13:29] <xnox> the git tree and/or bzr tree? i'm failing to find it.
=== rogpeppe1 is now known as rogpeppe
[13:30] <xnox> found it at https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/config.yaml
[13:30] <xnox> finally
[13:38] <kjackal_> hi xnox the code for the kubernetes charms are pushed upstream, give me a sec to get you the link
[13:38] <kjackal_> ahh and now i saw your last two lines!
[13:50] <xnox> kjackal_, still confused about snaps, and the "canonical distribution" charms they seem to be complicated.
[13:51] <kjackal_> xnox: this is why we are here :) Tell me!
[13:51] <kjackal_> xnox: What do you want to do?
[13:53] <xnox> kjackal_, i'm confused what enable-dashboard-addons do and what is the contents of cdk-addons snap
[13:53] <xnox> and what it translates upstream
[13:54] <xnox> i guess my lack of understanding of kubernetes itself and their addons shows now.
[13:56] <kjackal_> xnox: no do not loose faith! The dashboard-addons are enabled here:https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L462
[13:57] <kjackal_> they are essentialy passed as an argument to the cdk-addons snap https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L462
[13:57] <xnox> which i traced to deploying charms / installing snap which is based on https://github.com/juju-solutions/cdk-addons/blob/master/get-addon-templates
[13:57] <kjackal_> cdk-addons
[13:57] <kjackal_> https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L469
[13:57] <xnox> but i'm confused as to what is inside the cdk-addons snap =) https://github.com/juju-solutions/cdk-addons
[13:58] <kjackal_> you got it!
[13:58] <kjackal_> Lets see
[13:58] <xnox> oooh, but https://github.com/juju-solutions/cdk-addons/blob/master/Makefile is hm. building cdk-addons.yaml from kubernetes upstream ?!
[14:00] <kjackal_> Yes, https://github.com/juju-solutions/cdk-addons/blob/master/Makefile will grab the addons from upstream and package them as snaps
[14:02] <kjackal_> xnox: here is what gets enabled by the addons flag: https://github.com/juju-solutions/cdk-addons/blob/master/cdk-addons/apply#L30
[14:02] <xnox> kjackal_, but that for example does not deploy influxdb or grafana services, these should be deployed by something else already right? E.g. grafana charm?
[14:04] <xnox> hm.
[14:04] <kjackal_> xnox: you need something like this: https://jujucharms.com/canonical-kubernetes-elastic/ ?
[14:04] <xnox> unless enabling the dashboard plugin, pulls grafana k8s container image, and deploys grafana as a k8s container in the k8s cluster.
[14:05] <xnox> kjackal_, i mean if i do juju config kubernetes-master enable-dashboard-addons=true as advised on
[14:06] <xnox> Accessing the Kubernetes dashboard section
[14:06] <xnox> where would influxdb and grafana come from. Do i need to provide them (e.g. my influxdb is available at influxdb.example.net on my network)
[14:06] <xnox> or would grafana charm be deployed in my environment
[14:06] <xnox> or would a grafana k8s contaienr image be deployed in my juju environments' k8s cluster.
[14:09] <kjackal_> xnox: based on https://github.com/juju-solutions/cdk-addons/blob/master/get-addon-templates#L92 the yaml files that would be applied are found in https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/cluster-monitoring/influxdb
[14:09] <joedborg> hey all, is there a way to find a controller name, even if juju status won't respond (because the controller has gone)
[14:09] <kjackal_> xnox: And that should include the services deployed within kubernetes
[14:10] <xnox> kjackal_, ack.
[14:10] <kjackal_> xnox: for example here is a docker image that gets deployed: https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml#L24
[14:11] <kjackal_> joedborg: try cat ~/.local/share/juju/controllers.yaml
[14:12] <joedborg> cheeers kjackal_
[14:13] <kjackal_> anytime
[14:15] <xnox> kjackal_, thanks.
=== kjackal_ is now known as kjackal
[14:50] <Budgie^Smore> morning 0/ juju world
[15:41] <ak_dev> hello, could anyone please help me out on the peer relation bug which I posted?
[18:07] <Purnendu> is it possible to disconnect the JUJU controller and connect it back again
[19:55] <bdx> Purnendu: yea!
[21:29] <ak_dev> kjackal:
[21:29] <ak_dev> open_port did not work on the CENGN pod it seems
[21:30] <ak_dev> dont know why exactly though
[23:03] <infinityplusb> morning! How can I kill an application deployed into Juju? I have one that is stuck in some sort of loop and won't finish trying to install. I'd rather just kill it and redeploy if such a thing is feasible?