=== frankban|afk is now known as frankban
=== admcleod is now known as admcleod_afk
[09:18] <Zic> hi here, do you have any progress on Kubernetes 1.6 for CDK? I'm kinda excited to test it, as some feature of K8s in 1.6 will really simplify our lives :p (I don't know how to check your advancement except by lurking the juju-solutions GitHub)
[09:19] <sparkiegeek> https://insights.ubuntu.com/2017/04/12/general-availability-of-kubernetes-1-6-on-ubuntu/ ?
=== Spads_ is now known as Spads
[10:45] <Zic> sparkiegeek: oh, thanks, did not notice that :)
[10:52] <Zic> I'm reading the procedure to upgrade from CDK 1.5.3 -> what do you mean by "Wait until the software upgrade is complete before migrating the etcd data (a manual step)."
[10:54] <Zic> do I need to restore the etcd cluster like this? https://github.com/coreos/etcd/blob/master/Documentation/op-guide/recovery.md#restoring-a-cluster
[10:57] <Zic> cc lazyPower / kjackal when you will be around :)
[12:03] <Trefex> cholcombe: ok great thanks
[12:17] <tvansteenburgh> Zic: are you asking what is meant by "wait until the software upgrade is complete"?
[12:56] <Zic> tvansteenburgh: nop, the "before migrating the etcd data (a manual step)"
[12:57] <Zic> does this mean that I need to restore my etcd data manually?
[12:57] <Zic> or that Juju covers it with the "snap-upgrade" extra-step?
=== hml_ is now known as hml
=== coreycb_vaca is now known as coreycb
[14:29]  * lazyPower reads backscroll
[14:29] <lazyPower> sorry, getting in freenode a bit late this morning :) o/
[14:29] <lazyPower> Zic: hey there, nope. that migration we refer to is a charm upgrade (wait for the charm uprade to complete) then run the manual action specified by the status message
[14:30] <lazyPower> Zic: we moved etcd to snap based delivery, and its a downtime incurring event. Total time down should be ~ 5 minutes, so not crazy required downtime, but something to plan for for sure.
[14:32] <Zic> lazyPower: oh cool indeed, I thought I must do the restore myself :(
[14:33] <Zic> was a bit stressed up about it since etcd and me are not good friends
[14:45] <lazyPower> Zic: not at all
[14:46] <lazyPower> just make sure you snapshot and fetch it. the upgrade process does do a checkpoint, but get in the habit of snapshotting before making operational changes to etcd :)
[14:57] <Zic> lazyPower: fantastic :p thanks for all this automation :)
[14:57] <lazyPower> Zic: also, if you're curious about the upgrade, i do encourage you to deploy revision 24, and then upgrade to 29
[14:58] <lazyPower> see what its doing and become familiar with what you'll be doing in prod
[14:58] <Zic> thanks
[14:58] <lazyPower> Zic: and this unlocks the pathway to etcd 3.x
[14:59] <lazyPower> juju config etcd channel=3.0/stable, juju config etcd channel=3.1/stable  -- this process (waiting for each config-chagned event to complete ofcourse) will automatically ingest the next series, and upgrade the cluster through the major versions. Would love feedback on your experience there
[14:59] <lazyPower> note: 3.0 is mandatory stopgap to do the config/data format change. this is outlined in teh readme.
[15:00] <Zic> my next question was actually how to force Juju to deploy an old pre-1.6 version of CDK to train myself :D
[15:00] <lazyPower> 2.x => 3.1 is not supported at this time, I'll look into migrating those scripts in 3.0 to 3.1 so it gets carried forward
[15:00] <lazyPower> ah
[15:00] <lazyPower> Zic: you should be able to use the older bundle revision
[15:00] <Zic> so I have my answer :p
[15:00] <lazyPower> yep :)
[15:00] <lazyPower> we do support channel configs to deploy the older k8s. i think we only have 1.5 and 1.6 in the snaps tore
[15:00] <Zic> yup, by specify it in the Juju GUI at the charm level
[15:00] <lazyPower> Cynerva: ryebot:   can you confirm this?
[15:01] <ryebot> catching up
[15:04] <ryebot> lazyPower Zic: that's correct
[15:04] <lazyPower> fantastic, thanks ryebot
[15:04] <lazyPower> I didn't think we had any other versions in there but its good to confirm with the peeps that did the heavy lifting
[15:05] <ryebot> lazyPower Zic: I don't believe downgrading from 1.6 to 1.5 works, ftr, but deploy from a custom bundle with channel configuration should work.
=== rick_h_ is now known as rick_h
[15:11] <Zic> ryebot: oh no, my question was not about downgrade, simply force an old version for a fresh-install
[15:11] <ryebot> Zic: That should work well, I tested that personally
[15:11] <Zic> to train/test myself for the D Day for the upgrade in production :)
[15:12] <Zic> (mostly the etcd2 (deb) -> etcd3 (snap) part which feared me a bit)
[15:12] <Zic> fearing*
[15:12] <Zic> as we're really in prod now
=== Dmitrii-Sh_ is now known as Dmitrii-Sh
=== diddledan_ is now known as diddledan
=== salmankhan1 is now known as salmankhan
=== BradCrittenden is now known as bac
=== frankban is now known as frankban|afk
[16:45] <Zic> lazyPower: what's the purpose of kube-control?
[16:45] <Zic> (saw it in new/deprecated juju relations)
[16:46] <lazyPower> This interface provides communication between master and workers in a Kubernetes cluster.
[16:46] <lazyPower> at this time we're using it to send DNS information and expose information for the GPU based workloads
[16:46] <lazyPower> instead of interface proliferation it made sense to abstract into an administrative interface
[16:57] <Zic> thanks for the info :)
=== blackboxsw is now known as blackboxsw_bbl
=== blackboxsw_bbl is now known as blackboxsw
=== jhobbs_ is now known as jhobbs
=== coreycb is now known as coreycb_vaca
=== skayskay is now known as skay_
=== scuttle` is now known as scuttle|afk