Replaced _ with - for folder.

6 files changed, 236 insertions, 0 deletions

diff --git a/community/developer-summit-2016/KubDevSummitVoting.md b/community/developer-summit-2016/KubDevSummitVoting.md
new file mode 100644
index 00000000..daa4c5e3
--- /dev/null
+++ b/community/developer-summit-2016/KubDevSummitVoting.md
@@ -0,0 +1,33 @@
+## #Kubernetes Developer's Summit Discussion Topics Voting

+###

+A voting poll for discussion topic proposals has been created, and the link to the poll can be found [here][poll]. 

+

+The poll will close on 10/07/16 at 23:59:59 PDT. 

+

+#### How Does it Work?

+####

+The voting uses the Condorcet method, which relies on relative rankings to pick winners. You can read more about the Condorcet method and the voting service we're using on the [CIVS website][civs].

+

+There are 27 topics to choose from, and you will rank them from 1 (favorite) to 27 (least favorite). You can also mark "no opinion" on topics that you don't wish to include in the ranking. 

+

+The poll on CIVS has just the topic titles for ease of viewing. For topic descriptions, please see this [spreadsheet][topics]. The topic order on the voting service should mirror the order on the spreadsheet. 

+

+You will note the message saying "*Only the 15 favorite choices will win the poll*". CIVS requires a number be selected for winners, and we have arbitrarily chosen 15. The final schedule may include more or less than 15 of the submitted topics. 

+

+##### A Small Request 

+#####

+

+In order to make the poll accessible via URL, it has to be made "public". This means than any unique IP address can vote, which can be easily exploited for multiple votes. 

+

+We fully expect the community to behave with sportsmanship and only vote once, and as such we almost didn't bring this concern up to begin with. However, we have chosen to explicitly address it, in order to reiterate the importance of everyone's voice receiving equal weight in a community-driven event.

+

+#### After the Poll

+####

+A schedule will be made from the winning topics with

+some editorial license, and the schedule will be announced to the group

+at least a week before the event.

+

+[//]: # (Reference Links)

+   [civs]: <http://civs.cs.cornell.edu/>

+   [poll]: <http://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_9ef4ac5e58c4cab1&akey=7cc2652f9715b525>

+   [topics]: <https://docs.google.com/spreadsheets/d/1bmp6uLG8H32MVz02-zsieeKKZDZITw-8B6UjOaNTXOA/edit?usp=sharing>
\ No newline at end of file
diff --git a/community/developer-summit-2016/Kubernetes_Dev_Summit.md b/community/developer-summit-2016/Kubernetes_Dev_Summit.md
new file mode 100644
index 00000000..f66df508
--- /dev/null
+++ b/community/developer-summit-2016/Kubernetes_Dev_Summit.md
@@ -0,0 +1,96 @@
+# Kubernetes Dev Summit
+# 
+
+## Edit - Event Location
+##
+The event is on the 4th Floor of the *Union Street Tower* of the Sheraton Seattle Hotel. 
+
+# About the Event
+#
+The Kubernetes Developers' Summit provides an avenue for Kubernetes
+developers  to connect face to face and mindshare about future community
+development and community governance endeavors.
+
+In some sense, the summit is a real-life extension of the community
+meetings and SIG meetings.
+
+## Event Format
+## 
+The Dev Summit is a "loosely-structured [unconference][uncf]". Rather
+than speakers and presentations, we will have moderators/facilitators
+and discussion topics, alongside all-day completely unstructured
+hacking.
+
+The discussion sessions will be in an open fishbowl format &mdash; rings of
+chairs, with inner rings driving the discussion &mdash; where anyone can
+contribute. The various sessions will be proposed and voted on by the
+community in the weeks leading up to the event. This allows the
+community to motivate the events of the day without dedicating precious
+day-of time to choosing the sessions and making a schedule.
+
+There will be 3 rooms dedicated to these sessions running in parallel
+all day. Each session should last between 45 minutes and an hour.
+
+Then, there will be 2 smaller rooms for hacking / unstructured
+discussion all day.
+
+#### Who Should Go?
+#### 
+The target audience is the Kubernetes developer community. The group
+will be relatively small (~120-150 attendees), to improve communication
+and facilitate easier decision-making. The majority of the attendees
+will be selected from key company team and SIG leaders, power-users, and
+the most active contributors. An additional pool of tickets will be
+awarded via lottery. **Any interested party** should enter the lottery via
+[this form][lotfrm]. Invitees will receive an invitation on or before October 12th. 
+RSVP information will be available in the invitation email.  Tickets are
+not transferrable.
+
+Please note that this Summit is not the right environment for people to
+*start* learning about the Kubernetes project. There are plenty of
+[meetups][mtp] organized by global user groups where one can get
+involved initially.
+
+#### Call for Proposals
+#### 
+Proposals for discussion topics can be submitted through [this
+form][propfrm] by September 30, 23:59 PT. If you propose a session topic,
+please be prepared to attend and facilitate the session if it gets
+chosen. Other members will help with moderating, either as volunteer
+co-facilitators or as members of the larger discussion group.
+
+Suggestions for session topic themes:
+
+* Hashing out technical issues 
+* Long term component / SIG planning
+
+In early October, proposal topics will be posted to the kubernetes-dev
+mailing list and voted on via [CIVS][civs], the Condorcet Internet
+Voting Service. A schedule will be made from the winning topics with
+some editorial license, and the schedule will be announced to the group
+at least a week before the event.
+
+## When & Where?
+## 
+The Dev Summit will follow [Kubecon][kbc] on November 10th, 2016.
+Fortunately for those who attend Kubecon, the Dev Summit will be at the
+same venue, [the Sheraton Seattle Hotel][sher]. As of now, the day's
+activities should run from breakfast being served at 8 AM to closing
+remarks ending around 3:30 PM, with an external happy hour to follow.
+
+## Desired outcomes
+## 
+* Generate notes from the sessions to feed the project's documentation
+and knowledge base, and also to keep non-attendees plugged in 
+* Make (and document) recommendations and decisions for the near-term and
+mid-term future of the project 
+* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss
+
+[//]: # (Reference Links)
+   [uncf]: <https://en.wikipedia.org/wiki/Unconference>
+   [mtp]: <http://www.meetup.com/topics/kubernetes/all/>
+   [lotfrm]: <https://docs.google.com/forms/d/e/1FAIpQLSe8t6pvRjh1OeF6xrXKbXmzHGMhQ4c-MbZ6QUr9APJNjpgAzA/viewform>
+   [propfrm]: <https://docs.google.com/forms/d/e/1FAIpQLSf30x18OGCv_Und7qah4y5Zs3Z-0YoBCo964ZsmhtbxBjMzxA/viewform>
+   [civs]: <http://civs.cs.cornell.edu/>
+   [kbc]: <http://events.linuxfoundation.org/events/kubecon>
+   [sher]: <http://www.sheratonseattle.com/>
diff --git a/community/developer-summit-2016/application_service_definition_notes.md b/community/developer-summit-2016/application_service_definition_notes.md
new file mode 100644
index 00000000..54b13192
--- /dev/null
+++ b/community/developer-summit-2016/application_service_definition_notes.md
@@ -0,0 +1,48 @@
+# Service/Application Definition
+
+We think we need to help out the developers in how do we organize our services and how do I define them nicely and deploy on our orchestrator of choice.  Writing the Kube files is a steep learning curve.  So can we have something which is a little bit easier?
+
+Helm solves one purpose for this.  
+
+Helm contrib: one of the things folks as us is they start from a dockerfile, and they want to have a workflow where they go from dockerfile-->imagebuild-->registry-->resource def.
+
+There are different ways to package applications.  There's the potential for a lot of fragmentation in multi-pod application definitions.  Can we create standards here?
+
+We want to build and generate manifests with one tool.  We want "fun in five" that is have it up and running in five minutes or less.
+
+Another issue is testing mode; currently production-quality Helm charts don't really work on minikube,.  There's some issues around this which we know about.  We need dummy PVCs, LoadBalancer, etc.   Also DNS and Ingress.
+
+We need the 80% case, Fabric8 is a good example of this.  We need a good set of boundary conditions so that the new definition doesn't get bigger than the Kube implementation. Affinity/placement is a good example of "other 20%".  
+
+We also need to look at how to get developer feedback on this so that we're building what they need.  Pradeepto did a comparison of Kompose vs. Docker Compose for simplicity/usability.
+
+One of the things we're discussing the Kompose API.  We want to get rid of this and supply something which people can use directly with kuberntes.  A bunch of shops only have developers.  Someone asked though what's so complicated with Kube definitions.  Have we identified what gives people trouble with this?  We push too many concepts on developers too quickly.  We want some high-level abstract types which represent the 95% use case.  Then we could decompose these to the real types.
+
+What's the gap between compose files and the goal?  As an example, say you want to run a webserver pod.  You have to deal with ingress, and service, and replication controller, and a bunch of other things.  What's the equivalent of "docker run" which is easy to get. The critical thing is how fast you can learn it.
+
+We also need to have reversability so that if you use compose you don't have to edit the kube config after deployment, you can still use the simple concepts.  The context of the chart needs to not be lost.
+
+There was discussion of templating applications.  Person argued that it's really a type system.  Erin suggested that it's more like a personal template, like the car seat configuration.  
+
+There's a need to let developers work on "their machine" using the same spec.  Looking through docker-compose, it's about what developers want, not what kubernetes wants.  This needs to focus on what developers know, not the kube objects.
+
+Someone argued that if we use deployments it's really not that complex.  We probably use too much complexity in our examples.  But if we want to do better than docker-compose, what does it look like?  Having difficulty imagining what that is.  
+
+Maybe the best approach is to create a list of what we need for "what is my app" and compare it with current deployment files.  
+
+There was a lot of discussion of what this looks like.
+
+Is this different from what the PAASes already do?  It's not that different, we want something to work with core kubernetes, and also PAASes are opinionated in different ways.
+
+Being able to view an application as a single unifying concept is a major desire.   Want to click "my app" and see all of the objects associated with it.  It would be an overlay on top of Kubernetes, not something in core.
+
+One pending feature is that you can't look up different types of controllers in the API, that's going to be fixed.  Another one is that we can't trace the depenences; helm doesn't label all of the components deployed with the app.
+
+Need to identify things which are missing in core kubernetes, if there are any.
+
+## Action Items:
+
+* Reduce the verbosity of injecting configmaps.  We want to simplify the main kubernetes API.  For example, there should be a way to map all variables to ENV as one statement.
+* Document where things are hard to understand with deployments.
+* Document where things don't work with minikube and deployments.
+* Document what's the path from minecraft.jar to running it on a kubernetes cluster?
diff --git a/community/developer-summit-2016/cluster_federation_notes.md b/community/developer-summit-2016/cluster_federation_notes.md
new file mode 100644
index 00000000..81af586d
--- /dev/null
+++ b/community/developer-summit-2016/cluster_federation_notes.md
@@ -0,0 +1,21 @@
+# Cluster Federation
+
+There's a whole bunch of reasons why federation is interesting.  There's HA, there's geographic locality, there's just managing very large clusters.  Use cases:
+
+* HA
+* Hybrid Cloud
+* Geo/latency
+* Scalability (many large clusters instead of one gigantic one)
+* visibility of multiple clusters
+
+You don't actually need federation for geo-location now, but it helps.  The mental model for this is kind of like Amazon AZ or Google zones.  Sometimes we don't care where a resource is but sometimes we do. Sometimes you want specific policy control, like regulatory constraints about what can run where.
+
+From the enterprise point of view, central IT is in control and knowledge of where stuff gets deployed.  Bob thinks it would be a very bad idea for us to try to solve complex policy ideas and enable them, it's a tar pit.  We should just have the primitives of having different regions and be able to say what goes where.
+
+Currently, you either do node labelling which ends up being complex and dependant on discipline.  Or you have different clusters and you don't have common namespaces.  Some discussion of Intel proposal for cluster metadata.  
+
+Bob's mental model is AWS regions and AZs.  For example, if we're building a big cassandra cluster, and you want to make sure that nodes aren't all in the same zone.
+
+Quinton went over a WIP implementation for applying policies, with a tool which applies policy before resource requests go to the scheduler.  It uses an open-source policy language, and labels on the request.
+
+Notes interrupted here, hopefully other members will fill in.
diff --git a/community/developer-summit-2016/k8sDevSummitSchedule.pdf b/community/developer-summit-2016/k8sDevSummitSchedule.pdf
new file mode 100644
index 00000000..6cd8d01b
--- /dev/null
+++ b/community/developer-summit-2016/k8sDevSummitSchedule.pdf
diff --git a/community/developer-summit-2016/statefulset_notes.md b/community/developer-summit-2016/statefulset_notes.md
new file mode 100644
index 00000000..d019d256
--- /dev/null
+++ b/community/developer-summit-2016/statefulset_notes.md
@@ -0,0 +1,38 @@
+# StatefulSets Session
+
+Topics to talk about:
+* local volumes
+* requests for the storage sig
+* reclaim policies
+* Filtering APIs for scheduler
+* Data locality
+* State of the StateFulSet
+* Portable IPs
+* Sticky Regions
+* Renaming Pods
+
+## State of the StatefulSet
+
+1.5 will come out soon, we'll go beta for StatefulSets in that one.  One of the questions is what are the next steps for Statefulsets?  One thing is a long beta, so that we know we can trust statefulsets and they're safe.
+
+Missed some discussion here about force deletion.
+
+The pod isn't done until the kubelet says it's done.  The issue is what happens when we have a netsplit, because the master doesn't know what's happening with the pods.  In the future we'll maybe add some kind of fencer to make sure that they can't rejoin.  Fencing is probably a topic for the Bare-Metal Sig.
+
+Are we going to sacrifice availability for consistency?  We won't explicitly take actions which aren't safe automatically.  Question: should the kubelet delete automatically if it can't contact the master?  No, because it can't contact the master to say it did it.
+
+When are we going to finish the rename from PetSet to StatefulSet?  The PR is merged for renaming, but the documentation changes aren't.  
+
+Storage provisioning?  The assumption is that you will be able to preallocate a lot of storage for dynamic storage so that you can stamp out PVCs.  If dynamic volumes aren't simple to use this is a lot more annoying.  
+
+Building initial quorums issue?
+
+It would be great to have a developer storage class which ties back to a fake NFS.  For testing and dev.  The idea behind local volumes is that it should be easy to create throwaway storage on local disk.  So that you can write things which run on every kube cluster.
+
+Will there be a API for the application?  To communicate members joining and leaving.  Answer today is that's what the KubeAPI is for.
+
+The hard problem is configchange.  You can't do config change unless you bootstrap it correctly.  If kube is changing things under me I can't maintant quorum (as an app).  This happens when expanding the set of nodes.  You need to figure out who's in and who's out.  
+
+Where does the glue software which relates the statefulset to the application?  But different applications handle things like consensus and quorum very differently.  What about notifying the service that you're available for traffic.  Example for this with etcd with readiness vs. membership service.  You can have two states, one where the node is ready, and one where the application is ready.  Readiness vs. liveness check could differentiate?
+
+Is rapid spin-up a real issue?  Nobody thinks so,