crmin / rathole-operator

Hello, I'm Choro Min 👋

I am software engineer who works as backend developer and data engineer

• 🛠️ I am interested in a culture of development that boosts our productivity.
• ⌨️ I am very interested in programming that considers the user's experience rather than simply programming as "work".
• ⚙️ I like development that automates previously inconvenient processes and increases productivity.

💪 Skills

rathole-operator's Issues

The .spec.transport.noise field is required even though all fields in Noise transport are optional

Even though all child properties of transport.noise are optional, k8s resource requires the .spec.transport.noise property even for empty objects.

For example, in the case below, an error occurs with a message that the .spec.transport.noise field is required.

apiVersion: rathole.superclass.io/v1alpha1
kind: RatholeServer
metadata:
  name: rathole-server-1
  namespace: default
spec:
  configTarget:
    resourceType: configmap
    name: rathole-server-1
  bindAddr: 0.0.0.0:8000
  transport:
    type: noise

In the case below, it is created without a problem.

apiVersion: rathole.superclass.io/v1alpha1
kind: RatholeServer
metadata:
  name: rathole-server-1
  namespace: default
spec:
  configTarget:
    resourceType: configmap
    name: rathole-server-1
  bindAddr: 0.0.0.0:8000
  transport:
    type: noise
    noise: {}

Config changes in configTarget do not delete existing config

Even after modifying .spec.configTarget.resourceType from secret to configmap, the config remains in the existing secret.

Need to be modified so that local_private_key and remote_public_key of .transport.noise can be set directly.

The local_private_key and remote_public_key settings of .transport.noise can only be transmitted through configmap or secret key.
Since a method is provided to generate a base64 encoded key using the rathole command, modifications are needed to allow the field to be set directly for convenience.

Even if you change the spec, the connected resource does not change

Changing RatholeServer's .spec.serviceType should change the type property of the connected service, but there is no logic to handle this.

In addition to RatholeServer's .spec.serviceType, .spec.serviceAnnotations, .spec.deploymentAnnotations, and RatholeService's .spec.serviceType properties also have the same issue.

This properties only affects creation and cannot be modified.