feat(ws): add Workspace and WorkspaceKind CRD scaffolds

[jiridanek]

Followup on top of my:

• feat(ws): initial commit for controller #5

Compared to the previous PR, WorkspaceKind must be created as cluster-wide resource, so

kubebuilder create api --version v1beta1 --kind WorkspaceKind --namespaced=false

(it has to be --namespaced=false; --namespaced false is ignored, see kubernetes-sigs/kubebuilder#322 (comment))

Current CRD spec:

• Workspace
• WorkspaceKind

Todo's from meeting https://docs.google.com/document/d/1SiWLah-U07hAc47sSsoI8-NkbkLnHl1YVzxw193QUKE/edit#heading=h.naudedl8te2q

• Make image .... httpPort into a list of ports (to allow multiple services per image)
• Add a spec.spawner.deprecated: true/false
• Add a spec.spawner.deprecatedMessage: “xxxxx”

[thesuperzapper]

@jiridanek I have made a large number of suggestions.

But the most important thing you need to do is regenerate the WorkspaceKind resource as a Cluster-Scoped resource, its currently Namespace-scoped.

[thesuperzapper]

@jiridanek I pushed a commit with some changes, I would appreciate you taking a look to see if I messed anything up: 4dc0c16

Also, I just want to clarify, in what situations are you using pointers (*) in your type definitions, e.g. why are we using pointers for (I am forgetting when they are needed):

type WorkspaceKindActivityProbe struct {
	// a "shell" command to run in the Workspace, if the Workspace had activity in the last 60 seconds, this command
	//  should return status 0, otherwise it should return status 1
	Exec *WorkspaceKindActivityProbeExec `json:"exec,omitempty"`

	// a Jupyter-specific probe will poll the /api/status endpoint of the Jupyter API, and use the last_activity field
	//  Users need to be careful that their other probes don't trigger a "last_activity" update,
	//	e.g. they should only check the health of Jupyter using the /api/status endpoint
	Jupyter *WorkspaceKindActivityProbeJupyter `json:"jupyter,omitempty"`
}

[jiridanek]

Also, I just want to clarify, in what situations are you using pointers (*) in your type definitions, e.g. why are we using pointers for (I am forgetting when they are needed):

That's for the has(self.exec). Pointers have the meaning of optionals in Go, and nil means that value is not present. I understand it might be helpful not to need it (1B $$$ mistake and so on), but I did not manage to set up the XValidation without it.

The other occurrence of pointers in the PR is the same case, also XValidation.

[jiridanek]

@jiridanek I pushed a commit with some changes, I would appreciate you taking a look to see if I messed anything up: 4dc0c16

looks good to me, thanks!

[thesuperzapper]

@jiridanek I did some small updates in bb2ca34 (mostly adding a few fields to the Workspace status that are needed for the UI), but I also added some configs to make the kubectl get workspace and kubectl get workspacekind more useful.

I am going to merge this now, so we can start the reconciliation loop PR (we can make any further changes in that PR).

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thesuperzapper

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thesuperzapper]

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