razee-io/Razee

Razee agent install always fails because RemoteResource CRD is not created yet

thecheryl opened this issue · 9 comments

thecheryl commented

Describe the bug
When running the Razee agent install on a cluster (e.g. kubectl create -f "http://169.45.231.109:8081/api/install/cluster?orgKey=orgApiKey-75dd7435-4567-4d5f-a1c9-a9735c55b1b4") it fails because RemoteResource CRD is not created yet.

The error is unable to recognize "http://169.63.135.198:8081/api/install/cluster?orgKey=orgApiKey-8ab80ecc-9c55-488c-b84e-35ad87dc7745": no matches for kind "RemoteResource" in version "deploy.razee.io/v1alpha1"

To Reproduce
Steps to reproduce the behavior:

  1. Assuming Razee is set up run the "Razee Install Agent" command on a new ks cluster.

Expected behavior
Either one command that is successful or two separate commands if needed.

Kubernetes Version (kubectl version):

  • Client: 1.14.9_1543
  • Server: 1.14.9_1543
alewitt2 commented

Initial thought: we will create a kubernetes Job that will be a basic bootstrap script. It should be able to instal all pre-reqs in the proper order and wait for successful install of pre-reqs before moving on to next items. Also create a uninstall razee Job to remove everything to address #76 .

There should also be some configuration options (either as GUI in razeedash, or through query params) that allows user to specify which razee components that want installed (or excluded)

alewitt2 commented

the initial work is done for the install/remove jobs. will open another issue to get this integrated into razeedash/razeedash-api

https://github.com/razee-io/razeedeploy-delta/releases/download/0.3.2/job.yaml
where {{ COMMAND }} is either install or remove
and {{ ARGS_ARRAY }} is something like ["--rr", "--wk", "-a"]

see here for all install options and here for all remove options you can add to the ARGS_ARRAY

zachncst commented

Does the job require another namespace and clusterrole/rolebinding? The permissions are almost identical to the razee ones I wasn't sure if we should just pre-create those and use it for the job as well?

alewitt2 commented

ideally we wouldnt have to create all these extra things, but there is no guarantee what namespace the razee ones will end up in (we let you specify the namespace these get installed into). So the next best solution was to create these all new, let the job run, and have an easy cleanup strategy

basically:

  1. kubectl apply -f job.yaml
  2. let job run to completion
  3. kubectl delete -f job.yaml
zachncst commented

Where do you specify the namespace it gets installed in? If it's just the params to the job then you could just param it like {{ COMMAND }} right?

If I modified your job.yaml to replace the razee-job namespace with just razee and install it would the job error on trying to create the namespace, service.account and role bindings?

Guess I'm more asking is there anything stopping me.

alewitt2 commented

you could definitely modify the job.yaml to put it in a different namespace, and as long as you modify all the resources correctly (like updating the namespace of the service account inside the clusterrolebinding), it should work fine. The actual Job itself will create all the necessary components for the razeedeploy components to work. You can modify what namespace the Job creates by adding the -n razee arg to the jobs {{ ARGS_ARRAY }}

alewitt2 commented

although your question does give me an idea.. this PR should allow for reuse of the resources in common and puts the job in the same ns as the razeedeploy components (ie. remoteresource)

zachncst commented

Awesome! Thanks glad I could generate an idea.