Design

[wasabii]

Discussion for start of design.

[wasabii]

datalust/seq-tickets#2499 (reply in thread)

Naming is hard...I'd probably rename seq-operator as seq-config-operator to make its purpose clear and allow spawning seq-operator for full-fledged operator in future, without breaking the simpler one. Just a brainstorm.

It's going to do both. But it will do conf first

[wasabii]

So, my plan is to start with an Instance type (seqinstance), which starts out by requiring connection information to an existing instance. A URI and a reference to a secret. Then every other document type, such as, probably ApiKey, will have an instanceRef pointing to that primary Instance document. And those will drive out configuration.

Later, the Instance type can evolve that an existing hostname is optional, and instead, you can put the definition of a new instance in the Spec.

[wasabii]

spec:
  remote:
    endpoint: https://seq/
    login:
      secretRef:
        name: secretname

where the secret has username/password; or:

spec:
  remote:
    endpoint: https://seq/
    apikey:
      secretRef:
        name: secretname

where the secret has apikey

[mloskot]

Additionally, I'd consider accepting the Seq instance connection details in the form of the SeqCli.json config native to the official command client too, from K8s Secret (or Config map).

[wasabii]

That's not very k8s-like.

[mloskot]

That's not very k8s-like.

I'm not sure I understand what's not K8s-like in it? Storing JSON payload in a Secret?

It may be convenient to have Seq-native config file in Secret that can be mounted as volume by operator pod or seqcli pod.

[wasabii]

So, here's the design I've got.

All of the entities in Seq that are configurable have a string 'Id' property. So, there's a big inheritence hierarchy to keep it all clear. Each entity type (such as ApiKeys) will implement V1Alpha1InstanceEntity. There is a common V1Alpha1InstanceEntitySpec and V1Alpha1InstanceEntityStatus type. These are generic. Spec has standard properties of 'instanceRef' of type V1Alpha1InstanceReference, which is a pointer to a V1Alpha1Instance item, potentially cross namespace.

So, InstanceEntities known so far:

ApiKey
Alert
Signal

Each inherits from V1Alpha1InstanceEntity. This always required instanceRef.

V1Alpha1InstanceEntitySpec always provides two typed properties: init and conf. Both are a copy of a Conf type, which differs per entity type. These types represent the configuration to be applied to the entity. init represents that which is applied on Create. conf represents that which is reconcilled.

V1Alpha1InstanceEntityStatus is similar, and has a 'info' property. This represents the information to be pulled from Seq and exposed in K8s.

So, as example, for ApiKey:

apiVersion: k8s.seq.datalust.co/v1alpha1
kind: ApiKey
spec:
  instanceRef:
    name: seq-instance-1
    namespace: seq-ns
  init:
    title: Foo
  conf:
    title: Foo
status:
  id: APIKEYID
  info:
    title: TheTitle

init is optional. But provides a useful way to work around potential bugs where certain properties in the API cannot be set on Create, but only be set on Update.

So that's what the entities that are within a Seq instance look like. All will obey the same patterns.

The V1Alpha1Instance item specifies two things: how to connect to a Seq instance, or how to deploy a Seq instance.

apiVersion: k8s.seq.datalust.co/v1alpha1
kind: Instance
spec:
  connection:
    endpoint: https://seq:8443
    apikey:
      secretRef:
        name: the-secret
  conf:
    instanceLevelConfig: {}

The above is an example of an Instance that specifies a remote Seq to connect to.

apiVersion: k8s.seq.datalust.co/v1alpha1
kind: Instance
spec:
  deployment:
    Various Stuff
  conf:
    instanceLevelConfig: {}

The above is an Instance that specifies to deploy a new Seq instance in the cluster. Within deployment will be put the configuration related to creating a new instnace. For instance, pod information, PVC information, etc. The stuff actually required to run Seq.

[wasabii]

Sure. But again, I'm worrying about that part down the road. I want to get general configuration working first.

[wasabii]

(3) I have bootstrapping of FirstRun stuff working. The way it works is thus:

There is an initial secret, containing username, password, and OPTIONALLY firstRunPassword. Upon login, it attempts to use password. If that fails because it is invalid, and you have specified firstRunPassword, it tries that instead. Once authenticated with firstRunPassword it changes the password to password. The next time around it uses that instead.

[wasabii]

[wasabii]

And I have it pulling current settings into status.info.

[wasabii]

I think the way I'll have this work is that connection.login and connection.apikey can both be specified, where connection.apikey is attempted first. If that fails, then connection.login is used, as explained above (fallback to firstRun, and password change). After that, you can create an ApiKey entity, which will either take an existing secret for its token, or generate a secret for its token. And you can ALSO point connection.apikey at that secret, which may not exist at that point.

apiVersion: seq.k8s.datalust.co/v1alpha1
kind: Instance
metadata:
  name: seqinstance
  namespace: default
spec:
  connection:
    endpoint: http://localhost:5341
    login:
      secretRef:
        name: seqadmin
    apikey:
      secretRef:
        name: seqtoken
  conf:
    settings:
---

apiVersion: seq.k8s.datalust.co/v1alpha1
kind: ApiKey
metadata:
  name: seqinstance
  namespace: default
spec:
  instanceRef:
    name: seqinstance
  conf:
    token:
      secretRef:
        name: seqtoken

The full process would look like this:

1. The Instance first tries to reconcile.
2. It sees apikey. It tries to connect using apikey.
3. It cannot do so since the apikey secret does not exist at this point.
4. It moves onto login. It tries to connect using password.
5. It fails, since it is the incorrect password.
6. It moves onto firstRunPassword. It successfully connects.
7. It attempts to change the password of the user to password.
8. The Instance is now capable of connecting.
9. The ApiKey attempts to reconcile. It uses the instanceRef to resolve the instance, and create an API client.
10. This process follows the same process as above: Trying apikey (no secret or invalid auth), falling back to login, but this time password works, and firstRunPassword is never tried.
11. ApiKey reconciles. It tries to find an existing secret given token.secretRef. It either finds this secret or does not find this secret.
12. If it does not find the secret, it creates a new ApiKey as specified, and WRITES the new token to the secret (claiming GC ownership).
13. If it DOES fine the secret, it creates a new ApiKey using that secret.
14. The next time around, connection.apikey is tried first, as usual. Except this time the apikey secret exists and is valid, so it logs in with that.

[wasabii]

apiVersion: v1
kind: Secret
metadata:
  name: seqlogin
  namespace: default
type: Opaque
stringData:
  username: "admin"
  password: "newpassword"
  firstRunPassword: "1234"

---

apiVersion: seq.k8s.datalust.co/v1alpha1
kind: Instance
metadata:
  name: seqinstance
  namespace: default
spec:
  connections:
  - endpoint: http://localhost:5341
    token:
      secretRef:
        name: seqtoken
  - endpoint: http://localhost:5341
    login:
      secretRef:
        name: seqlogin
  conf:
    settings:
      
---


apiVersion: seq.k8s.datalust.co/v1alpha1
kind: ApiKey
metadata:
  name: seqtoken
  namespace: default
spec:
  policy: ["Create", "Update", "Delete"]
  instanceRef:
    name: seqinstance
  secretRef:
    name: seqtoken
  find:
    title: ManagementKey
  conf:
    title: ManagementKey
    permissions:
    - System
    - Project
    - Write
    - Organization
    - Read
---

This configuration works now.

First login happens as firstRunPassword.
That causes a change in the password to the normal password.
Second run runs as password.
ApiKey ends up being created, with proper permissions.
Third run runs using that ApiKey.

[wasabii]

@mloskot Try the operator when you get a chance. It's kinda usable for basic configuration now.

[wasabii]

Aded RetentionPolicy.

Took like 30 minutes.

So this is pretty easy from this point forward.

[mloskot]

@wasabii I'm back. I've just deployed it in my test cluster. I will be testing it over the weekend. Fantastic progress!

[wasabii]

Nice. I just pushed the code that actually does a deployment. It's early stages, and untested, but all the features we'd need are covered I think.

A SeqInstane without 'remote' connection specified will deploy a Secret for the login information, which it will create on its own if it isn't specified. firstRun and password are auto generated. It's supposed to change password to password after sucessful login with firstRun.

This is broken because I can't figure out how to hash the firstRun password properly.

Stateful set is used. This is because storage matters.

A default ApiKey named SeqOperatorApiKey is created as well.

Resulting endpoint is fetched off of the generated Service and put onto the Instance in status.deployment.endpoint.

I think that covers it.