---
title: " Weekly Kubernetes Community Hangout Notes - April 10 2015 "
date: 2015-04-11
slug: weekly-kubernetes-community-hangout_11
url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_11
---
Every week the Kubernetes contributing community meet virtually over Google Hangouts. We want anyone who's interested to know what's discussed in this forum.

Agenda:  

* kubectl tooling, rolling update, deployments, imperative commands.
* Downward API / env. substitution, and maybe preconditions/dependencies.


**Notes from meeting:**  

1\. kubectl improvements

* make it simpler to use, finish rolling update, higher-level deployment concepts.
* rolling update

    * today
        * can replace one rc by another rc specified by a file.

        * no explicit support for rollback, can sort of do it by doing rolling update to old version.

        * we keep annotations on rcs to keep track of desired # instances; won't work for rollback case b/c not symmetric.

    * need immutable image ids; currently no uuid that corresponds to image,version so if someone pushes on top you'll re-pull that; in API server we should translate images into uuids (as close to edge as possible).

    * would be nice to auto-gen new rc instead of having user update it (e.g. when change image tag for container, etc.; currently need to change rc name and label value; could automate generating new rc).

    * treating rcs as pets vs. cattle.

    * "roll me from v1 to v2" (or v2 to v1) - good enough for most people. don't care about record of what happened in the past.

    * we're providing the module ansible can call to make something happen.

    * how do you keep track of multiple templates; today we use multiple RCs.

    * if we had a deployment controller; deployment config spawns pos that runs rolling update; trigger is level-based update of image repository.

    * alternative short-term proposal: create new rc as clone of old one, futz with counts so new one is old one and vv, bring prev-named one (pet) down to zero and bring it back up with new template (this is very similar to how Borg does job updates).
        * is it worthwhile if we want to have the deployments anyway? Yes b/c we have lots of concepts already; need to simplify.

    * deployment controller keeps track of multiple templates which is what you need for rolling updates and canaries.

    * only reason for new thing is to move the process into the server instead of the client?

    * may not need to make it an API object; should provide experience where it's not an API object and is just something client side.

    * need an experience now so need to do it in client because object won't land before 1.0.

    * having simplified experience for people who only want to enageg w/ RCs.

    * how does rollback work: ctrl-c, rollout v2 v1. rollback pattern can be in person's head. 2 kinds of rollback: i'm at steady state and want to go back, and i've got canary deployment and hit ctrl-c how do i get rid of the canary deployment (e.g. new is failing). ctrl-c might not work. delete canary controller and its pods. wish there was a command to also delete pods (there is -- kbectl stop). argument for not reusing name: when you move fwd you can stop the new thing and you're ok, vs. if you replace the old one and you've created a copy if you hit ctrl-c you don't have anything you can stop. but you could wait to flip the name until the end, use naming convention so can figure out what is going on, etc.

    * two different experiences: (1) i'm using version control, have version history of last week rollout this week, rolling update with two files -> create v2, ??? v1, don't have a pet - moved into world of version control where have cumulative history and; (1) imperative kubectl v1 v2 where sys takes care of details, that's where we use the snapshot pattern.

* other imperative commands

    * run-container (or just run): spec command on command line which makes it more similar to docker run; but not multi-container pods.