Skip to content

Yevhenii

My feedback

2 results found

  1. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We're planning an investigation into this in Q2 (May-July for us). It's something more than one customer has asked for and allowing an Atlas ID to be used rather than a reference for another K8s resource feels like a reasonable approach. 


    No commitments for now till we've investigated in a little more detail. 

    Yevhenii supported this idea  · 
  2. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    This is something we're considering for the future. 


    But the biggest problem we need to solve is that it's incredibly easy to create/delete/update databases within a deployment via many other interfaces. But if this happens, the Operator's source of truth (the custom resources) won't contain the changes, and the Operator would overwrite the changes using it's source of truth.

    An error occurred while saving the comment
    Yevhenii commented  · 

    "Operator would overwrite the changes using it's source of truth" - that's exactly what we are expecting to have. If you are following infrastructure-as-a-code style there should be only one source of truth - Operator CRD.

    You could take as example Kafka operator which allows to create a topic via CRD. The topic, like a Mongo DB could also be created/updated by many other interfaces, but if it is defined as a CRD - the operator is the source of truth and it will rollback any other external changes.

    Yevhenii shared this idea  · 

Feedback and Knowledge Base