Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Create Dependent Resource in Different Namespace#1917

Answeredbycsviri
coltmcnealy-lh asked this question inQ&A
Discussion options

How do I create a Dependent Resource in a different namespace than the Primary? The use-case is that I need to create a Certificate in theistio-ingress namespace so that it can be used by the Istio Ingressgateway, but I obviously don't want my Primary resource (and all of the other dependents) to be created in that namespace.

Currently, using the "Managed Dependent Resource" feature, if the namespace in thedesired() Certificate is different than the Primary namespace, the Certificate gets created and then immediately deleted because theownerRef points to the Primary Resource which is in a different namespace, so K8s cleans it up automatically.

You must be logged in to vote

Hi@coltmcnealy-lh , the key is not to implementGarbageCollected interface. So not useCRUDKubernetesDependentResource. owner reference if added only in that case.

Note that in this case the default behavior is to add annotations to handle the related behavior, deleting the resouce:
https://github.com/java-operator-sdk/java-operator-sdk/blob/5a8ae993b9b1cc3f56ce4c784f85b15910b1c9bb/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java#L204-L204

Replies: 1 comment 6 replies

Comment options

Hi@coltmcnealy-lh , the key is not to implementGarbageCollected interface. So not useCRUDKubernetesDependentResource. owner reference if added only in that case.

Note that in this case the default behavior is to add annotations to handle the related behavior, deleting the resouce:
https://github.com/java-operator-sdk/java-operator-sdk/blob/5a8ae993b9b1cc3f56ce4c784f85b15910b1c9bb/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java#L204-L204

You must be logged in to vote
6 replies
@csviri
Comment options

Ohh, no, that should work, will check if there is a related integration test missing. Could you pls create an issue? will fix this if it broken, and release a patch for that if that is the case.

@coltmcnealy-lh
Comment options

Before I raise a false alarm, let me do a bit more digging. It also has a ResourceDiscriminator which might be improperly implemented.

The Discriminator usesContext.eventSourceRetriever().getEventSourceFor(Certificate.class), which might not be designed to work across namespaces.

@csviri
Comment options

ahh, ok! thx! but anyways, I cannot find an integration test on first check (we have a huge amount now :) ), so will add one to verify

@coltmcnealy-lh
Comment options

Ah, it was working, my ResourceDiscriminator was improperly implemented.

Quick question, here is my DependentResource Class implementation.

Are both the SecondaryToPrimaryMapper and PrimaryToSecondaryMapper needed? Can I optimize it in any way to reduce the number of K8s API calls?

@KubernetesDependent(resourceDiscriminator = ServerCertificateDiscriminator.class)public class ServerCertificateDR    extends CRUDNoGCKubernetesDependentResource<Certificate, LHCluster>    implements        SecondaryToPrimaryMapper<Certificate>, PrimaryToSecondaryMapper<LHCluster> {    public ServerCertificateDR() {        super(Certificate.class);    }    @Override    protected Certificate desired(LHCluster lhc, Context<LHCluster> ctx) {        // returns Secret in istio-ingress namespace    }    @Override    public void delete(LHCluster lhc, Context<LHCluster> primary) {        Certificate cert = primary            .getClient()            .resources(Certificate.class)            .inNamespace(lhc.getSpec().getIngress().getIstioNamespace())            .withName(lhc.getServerCertificateName())            .get();        if (cert != null) {            primary.getClient().resource(cert).delete();            log.info(                "Deleted Server-Side Certificate for cluster {}.",                lhc.getClusterId()            );        }    }    @Override    public Set<ResourceID> toPrimaryResourceIDs(Certificate cert) {        String certType = cert            .getMetadata()            .getLabels()            .get("littlehorse.io/cert-type");        if (certType == null || !certType.equals("server")) {            return new HashSet<>();        }        String lhClusterId = cert            .getMetadata()            .getLabels()            .get("littlehorse.io/cluster");        String lhClusterNamespace = cert            .getMetadata()            .getLabels()            .get("littlehorse.io/owner-cluster-namespace");        return Set.of(new ResourceID(lhClusterId, lhClusterNamespace));    }    @Override    public Set<ResourceID> toSecondaryResourceIDs(LHCluster lhc) {        Certificate cert = getKubernetesClient()            .resources(Certificate.class)            .inNamespace(lhc.getSpec().getIngress().getIstioNamespace())            .withName(lhc.getServerCertificateName())            .get();        Set<ResourceID> out = new HashSet<>();        if (cert != null) out.add(ResourceID.fromResource(cert));        return out;    }}
@csviri
Comment options

https://javaoperatorsdk.io/docs/features#managing-relation-between-primary-and-secondary-resources
it should be described here, usually just the secondary to primary, but only if you have some non standard use case. The annotations are added by default, you don't need even that to handle. So from the example above mostly enough to just have the desired method and costructor. The delete is not needed either to be implemented.

Answer selected bycoltmcnealy-lh
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@coltmcnealy-lh@csviri
[8]ページ先頭
©2009-2025 Movatter.jp