Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to Kubernetes 1.8.5 #132

Merged
merged 5 commits into from
Dec 20, 2017
Merged

Upgrade to Kubernetes 1.8.5 #132

merged 5 commits into from
Dec 20, 2017

Conversation

BugRoger
Copy link
Contributor

This commit upgrades the helm chart and ignition template to use 1.8.5.

Currently, this assumes that klusters without version information in the
spec are on 1.7.5. All new klusters must provide a version.

With 1.8.5 the default behaviour of the Openstack LoadBalancer creation
changed. Instead of defaulting to an internal LoadBalancer it now
creates an external LB by default. This requires the external network to
be configured in the cloud-provider config.

Fixes #62

This commit upgrades the helm chart and ignition template to use 1.8.5.

Currently, this assumes that klusters without version information in the
spec are on 1.7.5. All new klusters must provide a version.

With 1.8.5 the default behaviour of the Openstack LoadBalancer creation
changed. Instead of defaulting to an internal LoadBalancer it now
creates an external LB by default. This requires the external network to
be configured in the cloud-provider config.

Fixes #62
@BugRoger
Copy link
Contributor Author

Before anyone asks - the Gurkenwurst hack is still required for foreseeable time.

https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack.go#L212

That anyone runs this outside of a VM seems to blow a few assumptions.

@@ -0,0 +1,378 @@
/* vim: set filetype=yaml : */
Copy link
Contributor

Choose a reason for hiding this comment

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

The node 1.7 and 1.8 template look very similar is it currently possible to extract the common stuff and merge in the kubernetes version?
Changes to the common coreos setup would apply to all kubernetes versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I thought about that too. I'd do it in a separate PR.

Copy link
Member

@databus23 databus23 left a comment

Choose a reason for hiding this comment

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

Thumbs up from my side.

@@ -13,6 +13,7 @@ region = {{ .Values.openstack.region }}
[LoadBalancer]
lb-version=v2
subnet-id= {{ required "missing openstack.lbSubnetID" .Values.openstack.lbSubnetID }}
floating-network-id= {{ required "missing openstack.lbFloatingNetworkID" .Values.openstack.lbFloatingNetworkID }}
Copy link
Member

Choose a reason for hiding this comment

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

for 1.7 this is not strictly required. But maybe we collect it any case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't want to litter too many ifs throughout the code. De facto 1.7 won't be used anymore anyway...

@@ -107,9 +107,14 @@ spec:
- --authorization-mode=Node,RBAC
- --cloud-config=/etc/kubernetes/cloudprovider/openstack.config
- --cloud-provider=openstack
{{- if hasPrefix .Values.version.kubernetes "v1.8" }}
Copy link
Member

@databus23 databus23 Dec 20, 2017

Choose a reason for hiding this comment

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

I don't see a point in having the v prefix in our values for the kubernetes version and would find it clearer to just have the version number for comparison.


version:
# kubernikus:
kubernetes: v1.8.5
Copy link
Member

Choose a reason for hiding this comment

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

As said above I would go without the v for this field

@BugRoger
Copy link
Contributor Author

BugRoger commented Dec 20, 2017

@databus23 My thought about the versions were to just use a git ref. For Kubernikus we use the Git commit and in Kubernetes the releases are tagged including v

image

image

image

Also the images include the v too:

image

Though I don't have a super strong opinion either way.

@databus23
Copy link
Member

databus23 commented Dec 20, 2017

OK, I get that. I still like it more if the version field in the Spec (or Status) would just contain the version without prefix or suffix but its not that important to argue about. I'm fine with it either way.

@BugRoger
Copy link
Contributor Author

Removed the v and added poor-man's CoreOS versioning scheme generator

@BugRoger BugRoger merged commit 142d149 into master Dec 20, 2017
@BugRoger BugRoger deleted the v1.8 branch December 20, 2017 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants