Cluster-api: 0.1.0 release

[luxas]

Hi, as discussed in yesterday's meeting, I think it'd be beneficial to release a first "stable" alpha version of this repo in time for v1.13. Optionally do some good timing with implementations to also release roughly at the same time.

Why? Because kubeadm is going GA, and as k8s v1.13 is released we're gonna have a kubeadm GA blog post which also highlights our SIG's work. And when mentioning the different layers of our SIG's work, it'd be super nice to be able to say, and yeah, by the way, this cluster API thing we started a year ago has released its v1alpha1 spec, please go and try it out! I know that technically there's not a lot of difference to just grab a random commit and base your impl on that in this state, but it'd be a good thing to do for visibility I think, and eventually to get into the flow of releasing.

Note: I'm not saying the cluster API should release at the same time as core k8s. I'm saying that this specific time it'd be worth a shot to "colocate" with the GA of kubeadm.
WDYT?

[luxas]

@roberthbailey @timothysc @justinsb ^

[roberthbailey]

Can you remind us of the target date for this?

We'd need to decide what we mean by "alpha" in this context. If you look at the alpha-implementation milestone (which is admittedly has not been triaged for a while) there are enough open issues that I don't think we'd be able to faithfully make it in time.

The stable api milestone, on the other hand, is much closer to being complete and may be sufficient for the announcement you are proposing.

[luxas]

Can you remind us of the target date for this?

3rd of Dec, ref: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.13

Yes, this is _mostly_ about the API spec. IMO like, is it good enough to build an initial, alpha implementation on top of?

[justinsb]

I'm sending some PRs to get the cluster-api-provider-gcp back up to speed post the CRD-ification. To be frank, we're still making some relatively significant changes in cluster-api and my vote would be that we're not ready for end-users yet on the GCP side. The folk working on the AWS reference implementation may have a different opinion.

I have particular concerns about courting end-users while we're tied to minikube - trying to support minikube feels like it would take all our time.

My understanding is that this is primarily a PR statement to support kubeadm GA - could we say something like "The cluster-api project is working to bring the declarative kubernetes approach to infrastructure management, with GA expected in 2019." (I'm guessing that once the first implementation ships that we won't be able to make so many changes to the API itself, which is why I'm guessing 2019!)

[davidewatson]

From a Cluster API perspective, there are at least two issues which I expect will cause some providers to have to change:

• Establish a stronger link between Machine and Cluster or alternatively, Remove cluster assumption from actuators

• Cluster Controller Should Update Cluster APIEndpoints

[davidewatson]

From a Provider API perspective, are there any providers ready to commit to supporting long lived clusters? From the k8s API versioning summary, alpha means:

The software is recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.

Has anyone done sufficient upgrade testing?

/cc @detiber @hardikdr

[roberthbailey]

We will be tracking the first release via the v1alpha1 milestone.