Repository navigation
Conversation
…tion Two changes to how the operator talks about what it touches. Secret references. The four bare secretName fields become a secretRef struct, the shape the Kubernetes API conventions recommend for a single-kind object reference, so a qualifier can be added later without breaking a stored object: - awsCredentials.secretName -> awsCredentials.secretRef.name - tls.bolt.secretName -> tls.bolt.secretRef.name - tls.intraCluster.secretName -> tls.intraCluster.secretRef.name - monitoring.vmagentRemote.remoteWrite.basicAuth.secretName and monitoring.vectorRemote.auth.secretName -> ....secretRef.name The struct carries name only. The Secret must still live in the cluster's namespace, because every one of them reaches the pods as a mount or an env reference, and a pod can only read Secrets of its own namespace; a namespace field would need the operator to copy the Secret. The secrets license block keeps the HA chart's name/licenseKey/organizationKey shape, already a struct. Events. The operator recorded what it did only in its own log, and the Bolt commands it sends to Memgraph are invisible to the Kubernetes audit log. It now records an events.k8s.io/v1 Event on the MemgraphCluster for every action, one reason per action, with the touched pod, claim or StatefulSet as the related object: CoordinatorAdded, InstanceRegistered, MainPromoted, MainPromotionRefused, MainDemoted, InstanceUnregistered, CoordinatorRemoved, LeadershipYielded, BoltServerUpdated, RegistrationFailed, SettingApplied, SettingRejected, CoordinatorSettingApplied, PodRestarted, StatefulSetShrunk, VolumeExpansionRequested and StatefulSetOrphaned. Registration Events come from a decorator over the leader's client, so they record what Memgraph accepted or refused rather than what the plan intended: a promotion tries its candidates inside one command, and only the client sees which one won. Values read from a Secret never reach an Event. Waiting records nothing; that is what the conditions report. The manager gains create and patch on events.k8s.io events. docs/events.md lists every reason. BREAKING CHANGE: the secretName fields are gone from the schema, so the API server prunes them. A cluster using awsCredentials, tls, or the monitoring basic-auth blocks must be rewritten to secretRef.name before the CRD is upgraded; tls.intraCluster in particular cannot be dropped and re-added on a live cluster, so stop the operator, upgrade the CRD, rewrite those clusters, then start the new operator.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Secret references. The Kubernetes API conventions recommend a struct for an object reference (
secretRef: {name}) over a baresecretNamestring, so a qualifier such asnamespacecan be added later without a breaking change. Onv1alpha1the rename is cheap now; afterv1it would be a breaking change.Events. The operator recorded what it did only in its own log, and the operator emitted no Kubernetes Events at all. The Kubernetes audit log covers every write the operator makes to the API server, but nothing it sends to Memgraph over Bolt (
REGISTER INSTANCE, promoting a MAIN,DEMOTE INSTANCE,UNREGISTER INSTANCE,REMOVE COORDINATOR,SET DATABASE SETTING). I surveyed 13 operators' source: every one that reports in-database actions (CloudNativePG, Zalando, cass-operator, Strimzi, RabbitMQ, Percona XtraDB, ClickHouse) records Events on its custom resource, and none keeps an audit log of its own.What
secretRefawsCredentials.secretNameawsCredentials.secretRef.nametls.bolt.secretNametls.bolt.secretRef.nametls.intraCluster.secretNametls.intraCluster.secretRef.namemonitoring.vmagentRemote.remoteWrite.basicAuth.secretName…basicAuth.secretRef.namemonitoring.vectorRemote.auth.secretName…auth.secretRef.nameSecretReferencewithnameonly; the name validation moved onto it. There is nonamespacefield yet: every one of these Secrets reaches the pods as a mount or an env reference, and a pod can only read Secrets of its own namespace. Supporting another namespace would mean the operator copying Secrets.secretslicense block keeps the HA chart'sname/licenseKey/organizationKeyshape. It's already a struct, so anamespacecan be added besidenamelater.Events
events.k8s.io/v1Event on theMemgraphClusterper action, with one reason per action. The touched pod, claim or StatefulSet is the Event'srelatedobject.CoordinatorAdded,InstanceRegistered,MainPromoted,MainPromotionRefused,MainDemoted,InstanceUnregistered,CoordinatorRemoved,LeadershipYielded,BoltServerUpdated,RegistrationFailed.SettingApplied,SettingRejected,CoordinatorSettingApplied.PodRestarted,StatefulSetShrunk,VolumeExpansionRequested,StatefulSetOrphaned.recordingClient, a wrapper around the leader'smemgraph.Client(internal/controller/events.go). They record what Memgraph accepted or refused, not what the plan intended. A promotion tries its candidates inside one command, and only the client sees which one won: a refused candidate getsMainPromotionRefused, and the instance that really became MAIN getsMainPromoted.applySettingswith the same description the conditions use, so values read from a Secret (license, organization, AWS) never reach an Event.create;patchonevents.k8s.ioevents, generated from the marker intoconfig/rbac/role.yamland the chart. The recorder ismgr.GetEventRecorder("memgraph-operator").docs/events.mdlists every reason and when it fires; the README links to it.Also
secretRefstructs, and the Events design.version1.0.1-rc.3 → 1.0.1-rc.4 for the CRD and RBAC changes.Breaking change
The
secretNamefields are gone from the schema, so the API server prunes them. A cluster usingawsCredentials,tlsor the monitoring basic-auth blocks must be rewritten tosecretRef.namearound the CRD upgrade: stop the operator, upgrade the CRD, rewrite those clusters, then start the new operator.Testing
internal/controller/events_test.go) keeps Events in order. Existing specs now also assert the Events of:secretRef: the validation specs expect the new…secretRef.namepaths.make test,make lint,make chart-verify,make helm-lint,make chart-version-checkandgo vet -tags e2e ./test/e2e/all pass. I didn't run the e2e suite. Its manifests and patches use the new field names, but Events haven't yet been seen on a real cluster.