Skip to main content
Solved

Exporting metadata fails - Invalid token reference error


  • Not a newbie anymore
  • 3 comments

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?

Best answer by jaiganeshjk

@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.

View original
Did this topic help you find an answer to your question?

5 comments

Chris.Childerhose
Forum|alt.badge.img+21

  • Author
  • Not a newbie anymore
  • 3 comments
  • March 23, 2023

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?


jaiganeshjk
Forum|alt.badge.img+2
  • Experienced User
  • 274 comments
  • Answer
  • March 24, 2023

@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.


  • Author
  • Not a newbie anymore
  • 3 comments
  • March 24, 2023

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.actions[].exportParameters

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


Comment