Apply Opstella Core Configuration

Apply to Opstella Core with Management Admin Panel

1. Go to Opstella Management Admin Panel opstella-backend.${BASE_DOMAIN}/admin

2. Login with Opstella Core Credentials

   

3. Go to Workers > Configs

   

4. Add Config + (Top Right) and paste contents of opstella-backend-devopstool.yaml for devopstool kind and click Save in the buttom page

   

   

   

   

5. Add Config + (Top Right) and paste contents of opstella-backend-tag-on-premise.yaml for tag kind and click Save in the buttom page

   

   

   

   

Register Kubernetes Clusters Records to New Table

1. Connect to 🟢 Management Kubernetes Cluster ; i.e w/ Kubeconfig File

   Ensure you have defined and loaded your Global Shell Variables as described in Shell Variables.

   source $HOME/opstella-installation/shell-values/kubernetes/management_cluster.vars.sh

2. Use kubectl exec command to get into opstella-core-XXXXXXXXX-YYYYY container.

   Firstly, Get the name of Opstella Core (Back-end) Pod.

   kubectl get pods --namespace opstella-system

   Change opstella-core-XXXXXXXXX-YYYYY to be the one you get from getting pods list.

   kubectl exec -i -t --namespace opstella-system pod/opstella-core-XXXXXXXXX-YYYYY -- sh

   Note

   Your shell prompt will be changed to the container

   YOUR-SHELL $> kubectl exec -i -t --namespace devsecops-system pod/vault-0 -- sh
   / $

3. Run Command

   python manage.py migrate_opstella_v5

4. Go back to Opstella Management Admin Panel opstella-backend.${BASE_DOMAIN}/admin

5. Go to Workers > Kubernetes clusters, you will see a list of your Kubernetes Clusters configured to managed with Opstella.

   

6. Click EACH of the record and assign Cluster group and Cluster category accordingly.

   • 🟦 Non-Production DEV Workload Kubernetes Cluster
     • Cluster group: NON-PRODUCTION
     • Cluster category: WORKLOAD
   • 🟥 Production PRD Workload Kubernetes Cluster
     • Cluster group: PRODUCTION
     • Cluster category: WORKLOAD
   • 🟢 Management Kubernetes Cluster
     • Cluster group: NON-PRODUCTION
     • Cluster category: DEVOPS

   

   

   Click Save on EACH of them.

Add Keycloak to Tag Resource Manually

1. Go to Workers > Dev ops tool tags > Add dev ops tool tag + (Top Right)

   

2. Select/Specify the following

   • Devops tool: keycloak

   • Tag: on-premise

   • Env: ["DEV", "SIT", "UAT", "PREPRD", "PRD"] (In case where you have 5 Environments in Opstella)

     • This text will need to be change ONLY IF you will have different number of Environments managed by Opstella
     • For instance, you only have 3 Environments managed by Opstella (DEV, PRE, PRD)
       • This field will be ["DEV", "PREPRD", "PRD"]

   

3. Click Save on the bottom right

Opstella Company Synchronisation

1. Go to Tenant > Companys ; You should see a record of your organization name, having PROCESSING Status.

   

2. Tick ✅ on the record of your organization name.

   

3. The record of your organization name should soon have the Status of ACTIVE; Try refresh the page if it is not changing.

   

After applying the Config: publish the credentials to the state store

Applying the Config writes the DevOpsTool records, but the workers read each tool’s credentials from the Dapr state store, which is only written when a record is saved. Until then the state store has no core-credential-* keys and the first task each worker picks up fails.

Re-save every record once:

kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
  python manage.py shell -c "
from worker.models import DevOpsTool
for d in DevOpsTool.objects.all().order_by('id'):
    d.save()
print('re-saved', DevOpsTool.objects.count())
"

The Admin Panel reports success either way

ConfigAdmin.save_model wraps the whole apply in a try/except, so a failure inside it returns you to the list page exactly like a success. Confirm what landed instead of trusting the redirect:

kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
  python manage.py shell -c "
from worker.models import DevOpsTool
print([(d.name, d.status) for d in DevOpsTool.objects.all().order_by('id')])
"

Troubleshooting: the Company stays PROCESSING

Synchronisation is all-or-nothing. Task.manager.check_task_all_completed compares the number of completed tasks against DevOpsTool.objects.filter(status="COMPLETED").count(), and the batch is built from that same filter — so one tool the workers cannot reach keeps the Company in PROCESSING forever. There is no timeout and the Admin Panel shows no error.

Find which tool did not finish:

kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
  python manage.py shell -c "
from worker.models import Task, DevOpsTool
print('tools :', DevOpsTool.objects.filter(status='COMPLETED').count())
for t in Task.objects.order_by('-id')[:20]:
    print(t.id, t.method, t.status, t.request_slug)
"

Then either fix the connectivity to that tool and synchronise again, or take it out of the batch temporarily by setting its status to WAITING:

kubectl exec -i -t --namespace opstella-system deploy/opstella-core -- \
  python manage.py shell -c "
from worker.models import DevOpsTool
d = DevOpsTool.objects.get(name='CHANGEME'); d.status = 'WAITING'; d.save()
"

A tool left as WAITING is not managed by Opstella

Nothing will bring it back on its own. Set the status to COMPLETED and synchronise the Company again as soon as the tool is reachable, or that tool silently stops receiving every later task.

When the Opstella UI is not reachable yet

Every step on this page is written against the Admin Panel. If the Ingress, DNS or certificate for opstella-backend.${BASE_DOMAIN} is not in place yet, the same work can be done through manage.py shell as shown above.

A kubectl port-forward to the Admin Panel is not an equivalent: Django compares the request Origin against CSRF_TRUSTED_ORIGINS, which is derived from BASE_DOMAIN, so logging in over http://127.0.0.1:<port> fails CSRF validation.