search

cloudfoundry-incubator / kubo-release

Kubernetes BOSH release
https://www.cloudfoundry.org/container-runtime/
Apache License 2.0
161 stars 76 forks source link

job: cloud-provider should never exists. #167

Closed ChaosEternal closed 6 years ago

ChaosEternal commented 6 years ago

cloud-provider's functionality should be merged into bosh's cpi, not a separate job in a bosh release.

cf-gitbot commented 6 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/154713538

The labels on this github issue will be updated when the story is started.

glestaris commented 6 years ago

@ChaosEternal I absolutely agree. We haven't starting the effort of doing so but I hope we will start coordinating with the BOSH team soon.

liangboyi commented 6 years ago

Give some recommendation about the issue of ChaosEternal. 1.I had saw the code : <% if link('cloud-provider').p('cloud-provider.type') == 'vsphere' %> in kubo-release/jobs/kubernetes-system-specs/templates/config/rbac_policy.yml.erb May be there have any other place use the cloud-provider.

  1. I wanna deploy kubo in my bosh-lite , failed with the error of cloud-provider.type fix: change the version to 0.12.0, works well.
shinji62 commented 6 years ago

@glestaris I think they are separate concern, like I deploy on this openstack and I want to use the cloud provider on another tenant and so on.

Bosh should be software agnostic, starting adding some specific k8s things is "I" think not a good idea.

ChaosEternal commented 6 years ago

@shinji62 That's a different story, under that scenario, the feature of accessing cloud-provider should be made totally optional, not the way currently works -- the cloud provider is mandatory and restricted to only 4 cloud providers. Furthermore, is that requirement really valid? if upper software wants to use some IaaS facilities, shouldn't CPI know that? Bosh-releases should be cloud agnostic, this fact is more important than making bosh software agnostic, this is the value of why bosh exists. And it is valuable to make bosh do the cloud provider related jobs, they are actually IaaS things.

liangboyi commented 6 years ago

@shinji62 I absolutely not agree.. The release means the work you wanna do , you should and never consider which cloud you will run on. Which cloud will be use just use bosh to cover ... Release is release , just do the work you need and do not consider where I should go to work.

shinji62 commented 6 years ago

@shinji62 That's a different story, under that scenario, the feature of accessing cloud-provider should be made totally optional, not the way currently works -- the cloud provider is mandatory and restricted to only 4 cloud providers.

I am agree for this one, cloud-provider should be optional and I think you can just choose something else that the 4 provided and no cloud-provider is going to be use.

https://github.com/cloudfoundry-incubator/kubo-release/blob/master/jobs/cloud-provider/templates/bin/cloud-provider_utils.erb#L5

but I didn't test it.

Bosh-releases should be cloud agnostic, this fact is more important than making bosh software agnostic, this is the value of why bosh exists. And it is valuable to make bosh do the cloud provider related jobs, they are actually IaaS things.

That's true that cloud-provider are related to the jobs not the way you deploy the bosh release. I am not sure to would like to couple cloud-provider and my kubernetes cluster. Let's say I deploy my cluster on Openstack but I would like to use Vcenter for Persistent volume and so on ???

Release is release , just do the work you need and do not consider where I should go to work.

Agree, again I can install my kubernetes release on Openstack but I can if I want configure the data-storage on Vsphere.

The release means the work you wanna do , you should and never consider which cloud you will run on.

Yes so I want to install my release on Openstack and I want my release to use Vpshere

shinji62 commented 6 years ago

@glestaris Would like to invite more people into this debates. I think that's interesting discussion.

poblin-orange commented 6 years ago

some thoughts:

side note: just tested setting a random iaas-type and it disables cloud-provider, kube-apiserver starts but kube-controller-manager is KO

glestaris commented 6 years ago

This work is now considered as being outside the scope of this project.

We recently made an attempt to incept a track of work in a different Pivotal team but we decided to not move forward at this time due to the complexity.