feature(appliance): UI installs Sourcegraph again#63996
Conversation
| currentTasks, progress := calculateProgress(installTasks()) | ||
|
|
||
| installProgress := struct { |
There was a problem hiding this comment.
This is here so we don't get a null pointer ref in the frontend for now. Ultimately this needs to be generated/updated on every call.
There was a problem hiding this comment.
Is this basically stubbing the progress bar, as a stepping stone? If so let's leave a comment saying that's what it does. I am totally on board with getting the steel thread working and punting a more-accurate progress bar into follow-on backlog issues.
There was a problem hiding this comment.
Yeah just a stub for now. Based on the meeting yesterday we can either fully mock this or hopefully tie it in to work in a follow up.
| //TODO(jdpleiness) check form for value if this should be set or not | ||
| a.sourcegraph.SetLocalDevMode() |
There was a problem hiding this comment.
We need to read in our db connection strings and other info like localDevMode here
There was a problem hiding this comment.
In yesterday's team meeting, IIRC we punted remote DBs past the very first release. Let's create a follow-on issue for that.
re: Dev mode, IMO this code makes it too easy to accidentally never configure resources for real users. What if we conditionalize this line behind an env var check (e.g. APPLIANCE_DEV_MODE), and create a follow on issue to restore the dev-mode form field?
| dep.Spec.Strategy.RollingUpdate = &appsv1.RollingUpdateDeployment{ | ||
| MaxSurge: pointers.Ptr(intstr.FromInt(2)), | ||
| MaxUnavailable: pointers.Ptr(intstr.FromInt(0)), | ||
| MaxSurge: pointers.Ptr(intstr.FromInt32(2)), |
There was a problem hiding this comment.
Just sneaking in some quick fixes for deprecation warnings here
| r.Handle("/api/v1/appliance/status", a.getStatusJSONHandler()).Methods("GET") | ||
| r.Handle("/api/v1/appliance/status", a.postStatusJSONHandler()).Methods("POST") | ||
| r.Handle("/api/v1/appliance/install/progress", a.getInstallProgressJSONHandler()).Methods("GET") | ||
| r.Handle("/api/v1/appliance/maintenance/status", a.getMaintenanceStatusHandler()).Methods("GET") |
There was a problem hiding this comment.
Updated URIs to look a little cleaner
|
|
||
| // IsObjectReady checks if a k8s object is ready, with the definition of ready depending on the object type. | ||
| // Supported resource types are StatefulSets, Deployments, and PersistentVolumeClaims. | ||
| func IsObjectReady(obj client.Object) (bool, error) { |
There was a problem hiding this comment.
We can use this to get a good idea if our services are ready in order to update the progress bar in the UI. Still need to write up the loops to iterate over our services though
craigfurman
left a comment
There was a problem hiding this comment.
Amazing to see the installation going again! When I ran this locally, I could get it to install all resources, which eventually converged to healthy, but the progress bar never left 0% 🤔
Not sure if just my local environment or a real bug, let's pair on this later. Maybe, the desired end state is that success page we talked about, with a big "I'm ready" button that causes the ingress to flip for the first time? Presumably this would be backed by a new status to represent "first install done, waiting for admin acknowledgement" (maybe "awaiting-admin-post-first-install")? I think something to that effect was proposed yesterday.
| currentTasks, progress := calculateProgress(installTasks()) | ||
|
|
||
| installProgress := struct { |
There was a problem hiding this comment.
Is this basically stubbing the progress bar, as a stepping stone? If so let's leave a comment saying that's what it does. I am totally on board with getting the steel thread working and punting a more-accurate progress bar into follow-on backlog issues.
| //TODO(jdpleiness) check form for value if this should be set or not | ||
| a.sourcegraph.SetLocalDevMode() |
There was a problem hiding this comment.
In yesterday's team meeting, IIRC we punted remote DBs past the very first release. Let's create a follow-on issue for that.
re: Dev mode, IMO this code makes it too easy to accidentally never configure resources for real users. What if we conditionalize this line behind an env var check (e.g. APPLIANCE_DEV_MODE), and create a follow on issue to restore the dev-mode form field?
craigfurman
left a comment
There was a problem hiding this comment.
We split the step after the progress bar into a follow-on: https://linear.app/sourcegraph/issue/REL-291/wait-for-admin-ui-integrates-with-backend
🚀
Great work!
<!-- PR description tips: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e --> The appliance UI creates a `configMap` that triggers our reconciler to install Sourcegraph. - Refactored React app to remove "demo" code where possible - Added `status` functionality to get the status of deployments, statefulsets, or persistent volume claims. - Fix small code issue where `FromInt` was deprecated - Add reconciliation loop for the appliance backing `configMap` Install: ```shell ❯ k get pods NAME READY STATUS RESTARTS AGE blobstore-568d57d477-k5vrh 1/1 Running 0 15m codeinsights-db-0 2/2 Running 0 15m codeintel-db-0 2/2 Running 0 15m gitserver-0 1/1 Running 1 (14m ago) 14m grafana-0 1/1 Running 0 15m indexed-search-0 2/2 Running 0 15m pgsql-0 2/2 Running 0 15m precise-code-intel-worker-6fd4d6c8d5-4rjbc 1/1 Running 1 (14m ago) 15m precise-code-intel-worker-6fd4d6c8d5-6fjdw 1/1 Running 1 (14m ago) 15m prometheus-6cd94d7485-4cx7n 1/1 Running 0 15m redis-cache-f4dc7d6b8-2tp5v 2/2 Running 0 15m redis-store-5d6fcc9c84-7sj8v 2/2 Running 0 15m repo-updater-9f695b7d5-r28t7 1/1 Running 5 (14m ago) 15m searcher-0 1/1 Running 0 15m sourcegraph-frontend-64cc4458cd-4vdwq 1/1 Running 0 15m sourcegraph-frontend-64cc4458cd-gd7bf 1/1 Running 0 15m symbols-0 1/1 Running 0 13m syntect-server-6d5d55fb4f-tgbsc 1/1 Running 0 15m worker-66b4cd79b5-zw844 1/1 Running 1 (13m ago) 15m ``` ## Test plan Unit tests where applicable and tested locally via UI and local cluster <!-- REQUIRED; info at https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog <!-- OPTIONAL; info at https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c -->
The appliance UI creates a
configMapthat triggers our reconciler to install Sourcegraph.statusfunctionality to get the status of deployments, statefulsets, or persistent volume claims.FromIntwas deprecatedconfigMapInstall:
Test plan
Unit tests where applicable and tested locally via UI and local cluster
Changelog