Cloud provider conf

[flaper87]

In order to start OpenShift with the OpenStack provider enabled, there ought to be a config file in the server. The Openshift deployment on OpenStack is currently failing because such file is not present.

This patch, combined with openshift/installer#611 aims to create the config file in the destination node using the cloud provided by the operator during the dpeloyment.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: flaper87
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: wking

If they are not already assigned, you can assign the PR to them by writing /assign @wking in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[flaper87]

/cc @tomassedovic @hardys

[ashcrow]

Looks like "github.com/gophercloud/utils/openstack/clientconfig" hasn't been vendored. The golang tool dep is used for this project.

vendor/github.com/openshift/installer/pkg/types/installconfig.go:6:2: cannot find package "github.com/gophercloud/utils/openstack/clientconfig" in any of:
	/go/src/github.com/openshift/machine-config-operator/vendor/github.com/gophercloud/utils/openstack/clientconfig (vendor tree)
	/usr/local/go/src/github.com/gophercloud/utils/openstack/clientconfig (from $GOROOT)
	/go/src/github.com/gophercloud/utils/openstack/clientconfig (from $GOPATH)

[kikisdeliveryservice]

Should there be a default in this switch statement?

[abhinavdahiya]

you can return error

[abhinavdahiya]

@flaper87 the cloud provider config is usually a list of options.
I am open to MCO / MCC understanding a configmap source for getting the cloud provider config contents rather than the marshal/unmarshal in this PR.

[sjenning]

i just hit this issue just this morning trying to do an install. glad to see someone is already on it 👍

[flaper87]

Thakn y'all for the review!

@abhinavdahiya a config map should also work. Should the config map be created by the installer or by MCO directly? One problem we have on the openstack provider side is that this file has to exist in the filesystem (at least until I manage to remove this constraint).

Would it be ok for us to start with this approach and iterate towards using configmaps?

[flaper87]

This won't work until openshift/installer#611 lands but I'd like to get some consensus on this one before merging the installer patch.

/hold

[abhinavdahiya]

Thakn y'all for the review!

@abhinavdahiya a config map should also work. Should the config map be created by the installer or by MCO directly? One problem we have on the openstack provider side is that this file has to exist in the filesystem (at least until I manage to remove this constraint).

Would it be ok for us to start with this approach and iterate towards using configmaps?

I am pretty sure all clouds will eventually have need for a cloud config file, like azure...
So I think config map approach is going to be the best way forward. I'll try to work something up today to see how much effort that will be.

[flaper87]

@abhinavdahiya awesome, Thanks!

So, lemme recap and see if I understood correctly. The installer will create a configmap that MCO will use and from which (at least in this case) we'll be able to create the required file on the node FS. correct?

[abhinavdahiya]

installer has https://github.com/openshift/installer/blob/master/data/data/manifests/bootkube/kube-cloud-config.yaml which is empty right now. i think we should populate that config map and then teach MC* to use it.

[flaper87]

@abhinavdahiya sounds good to me, I'll give it a go!

[derekwaynecarr]

The config map should be editable by end users on bring your own infra environments as noted for azure, gce, and vsphere. We do need this PR to update so kubelet is passed the flag once the final source is available.

[flaper87]

@abhinavdahiya @derekwaynecarr @sjenning hey folks, I'd really like to move this PR forward as we're kinda blocked on not being able to start the kubelet due to the missing cloud operator config. What can I do to help move this forward? Any indication on what I should do next?

[sjenning]

need to rebase and run go test ./pkg/controller/template/... -u to update the test_data (why the ci/prow/unit job is failing)

[sjenning]

If it can be made to pass e2e-aws, then it seems fine to me. I'll see if I can test in on my Openstack cluster soon.

[flaper87]

@sjenning done! Thanks for the feedback :)

[derekwaynecarr]

will this make the username and pw generally visible from a machineconfig?

if so, this seems like a problem since the ignition configs are not generally protected.

we need to determine a way to deliver secret data to nodes securely.

[rphillips]

Looks like a number of these files need a gofmt.

[openshift-ci-robot]

@flaper87: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[frobware]

/cc @frobware

[kikisdeliveryservice]

how does #591 affect this PR?

[openshift-ci-robot]

@flaper87: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/prow/e2e-aws	cd9da15	link	/test e2e-aws
ci/prow/images	cd9da15	link	/test images
ci/prow/rhel-images	cd9da15	link	/test rhel-images
ci/prow/e2e-aws-op	cd9da15	link	/test e2e-aws-op
ci/prow/verify	cd9da15	link	/test verify
ci/prow/e2e-aws-upgrade	cd9da15	link	/test e2e-aws-upgrade

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.