docs(roadmap): add July 2015 planning meeting

Author: carmstrong

docs/roadmap/planning.rst

@@ -30,6 +30,14 @@ Major decisions affecting the Roadmap are discussed during Release Planning Meet
 Release Planning Meetings are open to the public with access coordinated via the #deis IRC channel on Freenode.
 Notes from past meetings are below, along with links to a recording of the entire meeting on YouTube.
 
+July 2015 (Deis v1.9)
+~~~~~~~~~~~~~~~~~~~~~
+
+Roadmap items completed: Pluggable Storage Subsystem, User-defined Health Checks
+Roadmap items added: Stateless Logger, Production Hardening
+
+Archive: https://www.youtube.com/watch?v=f_rJFWSFY5I
+
 June 2015 (Deis v1.8)
 ~~~~~~~~~~~~~~~~~~~~~
 

docs/roadmap/roadmap.rst

@@ -12,18 +12,6 @@ important to the future of Deis.
 Given the project's rapid :ref:`Release Schedule, <release_schedule>` roadmap items are designed to provide a sense of
 direction over many releases.
 
-Pluggable Storage Subsystem
----------------------------
-Deis uses Ceph to provide a highly-available storage subsystem for stateful control plane components.
-While Ceph is the right default storage subsystem, it is tricky to operate and can result in control plane instability.
-Ceph should be optional, especially for users on AWS with direct access to services like S3.
-
- - [ ] Registry S3 configuration
- - [ ] Database S3 configuration
- - [ ] Stateless logger (in-memory ring buffer)
-
-This feature is tracked as GitHub issue `#2812`_.
-
 TTY Broker
 ----------
 Today Deis cannot provide bi-directional streams needed for log tailing and interactive batch processes.
@@ -50,16 +38,47 @@ report their findings and help guide the future direction of Deis.
  - [ ] `Mesos preview`_
  - [ ] `Kubernetes preview`_
 
-Networking v2
--------------
-To provide a better container networking experience, Deis must provide an overlay network
-that can facilitate SDN and improved service discovery.
+Etcd 2
+------
+A CP database like etcd is central to Deis, which requires a distributed lock service and key/value store.
+As problems with etcd directly impact platform stability, Deis must move to the more stable etcd2.
 
- - [ ] Overlay Network
- - [ ] `Internal Service Discovery`_
- - [ ] Migration Strategy
+ - [ ] Switch to etcd2
+ - [ ] Migration strategy for etcd 0.4.x -> etcd2
 
-This feature is tracked as GitHub issue `#3812`_.
+This feature is tracked as GitHub issue `#3564`_.
+
+Monitoring & Telemetry
+----------------------
+Deis installations today use custom solutions for monitoring, alerting and operational visibility.
+Deis will standardize the monitoring interfaces and provide open source agent(s) that can be used to ship telemetry to arbitrary endpoints.
+
+ - [ ] Host Telemetry (cpu, memory, network, disk)
+ - [ ] Container Telemetry (cpu, memory, network, disk)
+ - [ ] Platform Telemetry (control plane, data plane)
+ - [ ] Controller Telemetry (app created, build created, containers scaled)
+
+This feature is tracked as GitHub issue `#3699`_.
+
+Production Hardening
+--------------------
+
+For users running Deis in large environments, support is lacking for things like separating the
+control plane and data plane (application and routing mesh), running etcd on only a fraction
+of the hosts, and other architectural design customizations. Specifically, work is in
+progress for:
+
+ - [ ] Better support for large-scale clusters (`#3635`_)
+ - [ ] Support for separating the data plane and control plane (`#3023`_)
+
+Stateless Logger
+----------------
+Users who have elected to run a Ceph-less cluster give up application logs since
+``deis-controller`` has nowhere to store them. To alleviate this, we plan to implement an in-memory ring buffer
+for the ``deis-logger`` component, so that a reasonable period of recent logs is stored and can be queried with
+``deis logs``.
+
+This feature is tracked as GitHub issue `#4000`_.
 
 Update Service
 --------------
@@ -74,28 +93,6 @@ To accomplish this, Deis plans to use the `Google Omaha Protocol`_ as implemente
 
 This feature is tracked as GitHub issue `#2106`_.
 
-Etcd 2
-------
-A CP database like etcd is central to Deis, which requires a distributed lock service and key/value store.
-As problems with etcd directly impact platform stability, Deis must move to the more stable etcd2.
-
- - [ ] Switch to etcd2
- - [ ] Migration strategy for etcd 0.4.x -> etcd2
-
-This feature is tracked as GitHub issue `#3564`_.
-
-User-defined Health Checks
---------------------------
-Today Deis relies on TCP port checks as evidence of container readiness during deploys.
-To facilitate a better zero-downtime deploy experience, Deis should allow user-defined
-health checks that are respected during the rolling deploy process and to verify that containers
-are healthy before publishing them to the routing mesh.
-
- - [ ] HealthCheck API and CLI
- - [ ] Publisher / HealthCheck integration
-
-This feature is tracked as GitHub issue `#3813`_.
-
 Deis Push
 ---------
 End-users should be able to push Docker-based applications into Deis from their local machine using ``deis push user/app``.
@@ -104,6 +101,17 @@ This works around a number of authentication issues with private registries and
  - [ ] `Docker Registry v2`_
  - [ ] `Deis Push`_
 
+Networking v2
+-------------
+To provide a better container networking experience, Deis must provide an overlay network
+that can facilitate SDN and improved service discovery.
+
+ - [ ] Overlay Network
+ - [ ] `Internal Service Discovery`_
+ - [ ] Migration Strategy
+
+This feature is tracked as GitHub issue `#3812`_.
+
 Service Broker
 --------------
 In Deis, connections to :ref:`concepts_backing_services` are meant to be explicit and modeled as a series of environment variables.
@@ -115,25 +123,14 @@ Deis believes the Cloud Foundry `Service Broker API`_ is the best embodiment of
 
 This feature is tracked as GitHub issue `#231`_.
 
-Monitoring & Telemetry
-----------------------
-Deis installations today use custom solutions for monitoring, alerting and operational visibility.
-Deis will standardize the monitoring interfaces and provide open source agent(s) that can be used to ship telemetry to arbitrary endpoints.
-
- - [ ] Host Telemetry (cpu, memory, network, disk)
- - [ ] Container Telemetry (cpu, memory, network, disk)
- - [ ] Platform Telemetry (control plane, data plane)
- - [ ] Controller Telemetry (app created, build created, containers scaled)
-
-This feature is tracked as GitHub issue `#3699`_.
-
 .. _`#231`: https://github.com/deis/deis/issues/231
 .. _`#2106`: https://github.com/deis/deis/issues/2106
-.. _`#2812`: https://github.com/deis/deis/issues/2812
+.. _`#3023`: https://github.com/deis/deis/issues/3023
 .. _`#3564`: https://github.com/deis/deis/issues/3564
+.. _`#3635`: https://github.com/deis/deis/issues/3635
 .. _`#3699`: https://github.com/deis/deis/issues/3699
 .. _`#3812`: https://github.com/deis/deis/issues/3812
-.. _`#3813`: https://github.com/deis/deis/issues/3813
+.. _`#4000`: https://github.com/deis/deis/issues/4000
 .. _`Automatic CoreOS upgrades`: https://github.com/deis/deis/issues/1043
 .. _`CoreUpdate`: https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/
 .. _`Deis Push`: https://github.com/deis/deis/issues/2680