Skip to content
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.

Kubernetes flavor #551

Merged
merged 5 commits into from
May 23, 2017
Merged

Kubernetes flavor #551

merged 5 commits into from
May 23, 2017

Conversation

YujiOshima
Copy link
Contributor

To support Kubernetes.
This flavor based on kubeadm.

Limitation (Next step)

  • Currently you should log in to master node for check the cluster status. We should get cluster status with Health func.
  • You can't create multi manager. It is limited with kubeadm.

Signed-off-by: YujiOshima [email protected]

@YujiOshima YujiOshima changed the title Add kubernetes flavor [WIP] Kubernetes flavor May 18, 2017
@codecov
Copy link

codecov bot commented May 18, 2017

Codecov Report

Merging #551 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #551   +/-   ##
=======================================
  Coverage   56.66%   56.66%           
=======================================
  Files          57       57           
  Lines        3969     3969           
=======================================
  Hits         2249     2249           
  Misses       1432     1432           
  Partials      288      288

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a3b92e9...733399c. Read the comment docs.

@@ -0,0 +1,120 @@
InfraKit Flavor Plugin - Swarm
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OMG! 😱
I will fix immediately.

@GordonTheTurtle
Copy link

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "k8s" [email protected]:YujiOshima/infrakit.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353535280
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

var pfPath string
switch c.flavorSpec.KubeNWAddOn {
case "flannel":
pfPath = "https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can move these hard coded strings to the flavor's Properties so that we can specify something like

    "KubeNWAddOn" : {
           "Name" : "calico",
           "Path" : "http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml"
     }

This will allow us to avoid hard coding, and all the configurations can be inside the same JSON which makes it easy to see how system is configured.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! That's sounds good!
I would like to make it a property of the kubernetes addon without limiting to network add-ons.

"KubeAddOn" : {
           "Name" : "calico",
	   "Type" : "network",
           "Path" : "http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml"
     }

If you do not set network add-on only, cluster does not become ready status, so if you do not set network add-on, I will display a warning.

@chungers chungers changed the title [WIP] Kubernetes flavor Kubernetes flavor May 21, 2017
{
Name: "NETWORK_ADDON",
Description: []string{"Returns the kube network addon"},
Func: func() (interface{}, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making this a function that takes the addon type as a parameter? Then we can name the function ADDON and its signature is func(addonType string) (interface{}, error) and we only need to search the list of addons and return the path of the first one with the matching type.

},
},
{
Name: "VISUALISE_ADDON",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above... if the function above takes a parameter then we won't need this function here.

@chungers
Copy link
Contributor

@YujiOshima - sorry a small comment / change to consider before we merge. Also can you sign the commits...

@YujiOshima
Copy link
Contributor Author

@chungers Thank you for the review! I updated it and cleaned up commits. I rebased with latest master. PTAL

YujiOshima and others added 2 commits May 22, 2017 05:31
Copy link
Contributor

@chungers chungers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great. I am so excited! Thank you!

@chungers chungers merged commit 4808abd into docker-archive:master May 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants