Skip to main content
  • EN

Hi,

 

After deploying and configuring Kasten 5.5.6 with an Azure location profile I created a basic policy and ran it: all is fine until the very last step which is failing.

 

During the “exporting metadata” step the following exception is raised

- cause:
    cause:
      cause:
        file: kasten.io/k10/kio/exec/phases/phase/migrate.go:796
        function: kasten.io/k10/kio/exec/phases/phase.getMigrationString
        linenumber: 796
        message: Invalid token reference
      file: kasten.io/k10/kio/exec/phases/phase/migrate.go:772
      function: kasten.io/k10/kio/exec/phases/phase.getMigrationData
      linenumber: 772
      message: Failed to get migration string
    file: kasten.io/k10/kio/exec/phases/phase/migrate.go:100
    function: kasten.io/k10/kio/exec/phases/phase.(*migrateSendPhase).Run
    linenumber: 100
    message: Failed to get migration data
  message: Job failed to be executed

 

Which direction should I be looking into?

@jaiganeshjk 

Hi, I just found out what was wrong:

  • I’m using a GitOps approach to declare the location and policy
  • I did not see that Kasten modifies the provided yaml on the fly (adding lines such as receiveString) …
  • and of course my GitOps controller - argocd - reverts those changes

Now the question becomes: is there a best practice to declare k10 policies and locations using ArgoCD?

@stephw Thank you for posting your question.

You are right. Policy controller adds the recieveString and migrationToken to the policy spec.

We started supporting creating policies using gitops approach sometime back.

Even if the argocd syncs the resources and reverts the changes, We ensured that it doesn’t affect the policy runs in k10. 

Not sure where the issue might be, We will take a look at this.

For the time-being, I would request you to ignore syncing the policy resources with argoCD until we have a solution for this.

Yes, this is what I did for the time being (ignore syncing the policy resources).

Looking forward for the results of your investigation.

 

btw, on the usage of Kasten in GitOps paradigms I found the demo from Michael Cade very helpful: https://www.kasten.io/kubernetes/resources/videos/continuous-data-protection-with-kasten-k10-and-argocd (a topic to probably integrate in the Kasten k10 main documentation at some point?)

You can add the following settings to your Argo application’s .spec to ignore changes to the migrationtoken and receiveString:

        ignoreDifferences:
        - group: "config.kio.kasten.io"
          kind: "Policy"
          jqPathExpressions:
          - .spec.actionsn].exportParameters

@Developers: I would suggest to move the tokens away from .spec to .status - that would be the cleanest solution 😉

Comment


Terms & Conditions