Skip to main content
  • EN

K10 5.5.4 on K3s (stable). All K10 deployments running, all pods also running, all PVCs bound.

 

I was able to create a policy and use it (snapshot, export). Then I deleted that policy.

 

Now no matter what policy settings I choose, “Create policy” button is dimmed and can’t be clicked on to apply.

I tried different options including the ones I had before (simple snapshot + export). I also tried creating a policy for different applications - no change, the button is always dimmed.

 

How to troubleshoot this?

@thatman Thank you for posting your question.

Does the useraccount you use to login to the UI, have permissions to create profile in kasten-io namespace ?

kubectl auth can-i create policies.config.kio.kasten.io -n kasten-io --as=<username>

#if you are using serviceAccount token, then use the below command

kubectl auth can-i create policies.config.kio.kasten.io -n mysql --as=system:serviceaccount:<namespaceName:serviceaccountName>

 

I haven’t even left the same browser tab between tasks.

 

Meanwhile I tried a workaround - not really a workaround but more of a log gathering exercise - to create a policy from the CLI. Interestingly, that worked. Then I went back to the UI and was able to execute the (re)created policy.

 

I think it may have been something related to the accounts, but I can’t say what exactly, because during this 1-2 hours of troubleshooting I did see a new prompt to accept the license (which I did when I started using the Kasten 3-4 hours ago). So maybe you are right, maybe my session somehow expired (I suspect connection forwarding may have intermittently dropped and caused this “reset”). Further indication of this theory is that later I was able to create new policies from the Web UI.

 

So, although I haven’t used the commands from your answer, I think it is in the right direction - people should refresh their browser or try your commands.

 

Thanks!

@thatman Thanks for your detailed explanation with the timelines.

I think I may know what happened with you. When you install K10 for the first time, you get a pop-up to accept EULA with your email and company name.

This is stored as a configMap named k10-eula-info in K10 namespace.

Without accepting the EULA, most of the actions in UI will be disabled.

Since you mentioned you accepted that earlier, I am assuming this ConfigMap is somehow deleted from your kasten-io namespace, forcing you to accept it again.

Since you accepted the second time, it might have started working for you again.

Just an FYI, It could be useful for someone who comes across this post at a later point.

 

If you think some external gitops controller could be responsible for the deletion of this configMap because of the declarative state, You could use the below helm values to set the EULA info declaratively.

eula.accept

Whether to enable accept EULA before installation

false

eula.company

Company name. Required field if EULA is accepted

None

eula.email

Contact email. Required field if EULA is accepted

None

Hmm, okay, I’ll look in to this if I see the same problem again.

I did the entire test in one sit, with no interruptions and working on clean test cluster, but now that you mention this it could be (although I find that unlikely) that the cluster ran out of resources so maybe some of K10 pods were restarting or something like that.

Comment


Terms & Conditions