This bumps both the version of the operator and the default host version
in the example to 1.0. Also updates the README to use the released wadm
chart
Signed-off-by: Taylor Thomas <taylor@cosmonic.com>
wasmCloud 1.0 fully converts over to using components among other large
changes, so we need to rework the operator to account for it. 1.0 is
still in the works, so this updates the operator to depend on wasmCloud
1.0 libraries along with refactoring the service creation code to use
the updated application manifest format.
Once this is in we will likely cut a 0.2.0 pre-release and wait for an
actual release until wasmCloud 1.0.0 and wadm 0.11 are out.
This also adds a new field to the CRD so that you can specify the full
image reference instead of just the version. The `image` parameter takes
precedence.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
Also add support for setting the number of stream replicas when creating
the stream mirror for the operator.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
One advantage of wasmCloud applications is that we always know what
components make up an application and therefore can intelligently make
decisions based on what interfaces we're using. This makes it much
easier for software like the operator to take particular actions based
on the contents of an application manifest.
This change adds an additional set of reconciliations we can perform on
a per-lattice basis to automatically create Kubernetes Services for
applications that deploy a httpserver component. The operator uses a
NATS consumer that watches for manifest deploy and undeploy events and
triggers a reconciliation on a managed Service. Right now this is
restricted only to `daemonscalers`, since we do not have to do any
bookeeping on where components are deployed if they are running on all
of the hosts in a lattice or in a subset identified by label. We will
add support for `spreadscalers` in a future PR.
This allows for some interesting deployment scenarios, such as wasmCloud
applications that span multiple Kubernetes deployments in the same
namespace, or potentially in _multiple namespaces_ if we decide to
implement support for them. Initially the operator is only creating
endpoints that route traffic from a service to pods in the same
namespace, but we may add an option to relax that assumption.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
This refactors the WasmCloudHostConfig CRD so that it has a single field
(`schedulingOptions`) for configuring how the underlying Pods are
scheduled in Kubernetes. This includes:
* Relocating the `daemonset` option to this new field
* Relocating the `resources` option to this new field
* Adding a new `pod_template_additions` field that allows you to set any
valid option in a `PodSpec`
Doing so allows cluster operators to do things like set node affinity
and node selector rules, along with any other valid PodSpec option. The
only thing that cannot be done is adding additional containers to the
pod, since that is all handled by the controller. We could look at
exposing that option if users want to be able to add additional
sidecars.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
In wasmCloud 0.81.0 we deprecated the old `OCI_REGISTRY` variables in
favor of prefixing them with `WASMCLOUD`. 0.82.0 fully removed those
variables, so this updates the controller to use the new variables with
an eye towards wasmCloud 1.0 compatibility.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
Add documentation on how to use the `registryCredentialsSecret` to
enable wasmCloud hosts to pull from a private registry.
Also add comments to each of the CRD fields outlining what each field
does.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
Add a `daemonset` option for managing hosts as a DaemonSet instead of
just a Deployment.
Signed-off-by: Dan Norris <protochron@users.noreply.github.com>
Joonas Bergius