Skip to main content

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