| === 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 | ||
| kjackal_ | Good morning Juju world! | 07:38 |
|---|---|---|
| magicaltrout | kubernetes hackers I have a snap pattern question for you | 10:36 |
| 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:37 |
| kjackal_ | hey magicaltrout | 10:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| magicaltrout | what happens when you screw everything up like conjure-up? ;) | 10:47 |
| kjackal_ | we get fired... I guess | 10:49 |
| 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:50 |
| 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 :) | 10:51 |
| stokachu | magicaltrout:to be fair it wasn't conjure-up it was snapd | 11:31 |
| magicaltrout | indeed stokachu, I'm only ribbing ya'll, but I am curious about the checks and balances | 11:52 |
| 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:53 |
| 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:55 |
| rick_h | there was a post on that recently, let me find it. they're going to allow more control | 11:56 |
| magicaltrout | nice | 11:57 |
| rick_h | https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/11 | 11:57 |
| 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:58 |
| 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 | 11:59 |
| 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:00 |
| 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:01 |
| rick_h | and hopefully folks use the different channels in there to beta test/etc | 12:02 |
| ak_dev | https://www.irccloud.com/pastebin/cFegoDAR/ | 12:42 |
| ak_dev | There seems to be a problem with the above interface (peer) | 12:42 |
| ak_dev | the states go as such : .connected -> .unsigned.cert.available -> .signed.cert.available | 12:43 |
| 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:44 |
| 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! | 12:45 |
| xnox | hi | 13:28 |
| xnox | where is the source code for https://jujucharms.com/u/containers/kubernetes-master/ ? | 13:28 |
| xnox | the git tree and/or bzr tree? i'm failing to find it. | 13:29 |
| === rogpeppe1 is now known as rogpeppe | ||
| xnox | found it at https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/config.yaml | 13:30 |
| xnox | finally | 13:30 |
| 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:38 |
| xnox | kjackal_, still confused about snaps, and the "canonical distribution" charms they seem to be complicated. | 13:50 |
| kjackal_ | xnox: this is why we are here :) Tell me! | 13:51 |
| kjackal_ | xnox: What do you want to do? | 13:51 |
| 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:53 |
| xnox | i guess my lack of understanding of kubernetes itself and their addons shows now. | 13:54 |
| 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:56 |
| 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:57 |
| 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 ?! | 13:58 |
| kjackal_ | Yes, https://github.com/juju-solutions/cdk-addons/blob/master/Makefile will grab the addons from upstream and package them as snaps | 14:00 |
| 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:02 |
| 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:04 |
| xnox | kjackal_, i mean if i do juju config kubernetes-master enable-dashboard-addons=true as advised on | 14:05 |
| 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:06 |
| 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:09 |
| 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:10 |
| kjackal_ | joedborg: try cat ~/.local/share/juju/controllers.yaml | 14:11 |
| joedborg | cheeers kjackal_ | 14:12 |
| kjackal_ | anytime | 14:13 |
| xnox | kjackal_, thanks. | 14:15 |
| === kjackal_ is now known as kjackal | ||
| Budgie^Smore | morning 0/ juju world | 14:50 |
| ak_dev | hello, could anyone please help me out on the peer relation bug which I posted? | 15:41 |
| Purnendu | is it possible to disconnect the JUJU controller and connect it back again | 18:07 |
| bdx | Purnendu: yea! | 19:55 |
| ak_dev | kjackal: | 21:29 |
| ak_dev | open_port did not work on the CENGN pod it seems | 21:29 |
| ak_dev | dont know why exactly though | 21:30 |
| 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? | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!