kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2133 from AdamDang/patch-7 

Typo fix: Kuberntes->Kubernetes
This commit is contained in:
k8s-ci-robot 2018-05-29 13:08:34 -07:00 committed by GitHub
parent e841239661 e2a23c323c
commit c68bc2dfae
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contributors/design-proposals/storage/grow-volume-size.md
View File

@ -198,7 +198,7 @@ we have considered following options:
Cons:
* I don't know if there is a pattern that exists in kube today for shipping shell scripts that are called out from code in Kubernetes. Flex is
different because, none of the flex scripts are shipped with Kuberntes.
different because, none of the flex scripts are shipped with Kubernetes.
3. Ship resizing tools in a container.

2
events/2016/developer-summit-2016/application_service_definition_notes.md
View File

@ -16,7 +16,7 @@ We need the 80% case, Fabric8 is a good example of this. We need a good set of
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.
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 kubernetes. 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.