Conversation
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff 11ba68c...02dd250.
|
Co-authored-by: Beyang Liu <beyang@sourcegraph.com>
Co-authored-by: Beyang Liu <beyang@sourcegraph.com>
davejrt
left a comment
There was a problem hiding this comment.
Overall looks good. It be worth looking into the possibility of using existing envvars that are present in kuberetes or compose to determine the deployment type, rather than having to explicitly define it. For example checking for the presence of one of these could safely determine that it's k8s or not.
/ $ env | grep KUBE
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.253.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=10.253.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP=tcp://10.253.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.253.0.1
|
Thanks for clarifying @rafax ! I’ve talked to Michael last week regarding this change and he helped me understand why service discovery is important in some use case (e.g standard k8s practice and cli automation etc). The idea to remove rbac resources from frontend by default is driven by the incidents where customers not having the ability to create them, led to long turnaround time. We have built a kustomize component that would update the env vars in frontend automatically when deploying using kustomize; however, if service discovery is preferred, the site admins / cluster admins do have the option to add service discovery to frontend anytime (using kustomize). This allows site admins to move forward with configuring their instance after initial deployment while cluster admins help with deploying RBAC resources collectively--do you think this helps addressing your team's use case here? |
If we have an option to support service discovery (and therefore, can scale deployments without reconfiguring clients / redeploying kustomize) we're good on Cloud side. |
|
@abeatrix I'll take a look tomorrow, but I noticed that there are a lot of conflicts. You probably wanna merge in origin/main or rebase onto it. |
|
adding @slimsag as a reviewer to make sure the new changes will also work with App as expected |
keegancsmith
left a comment
There was a problem hiding this comment.
Nice code!
One blocking comment inline, so requesting changes.
| // Detect 'go test' and setup default addresses in that case. | ||
| p, err := os.Executable() | ||
| if err == nil && strings.HasSuffix(p, ".test") { | ||
| return "gitserver:3178", nil | ||
| } |
There was a problem hiding this comment.
I am assuming this messes with your tests? You can't actually validate the default, but this fine we can read code instead :)
| return conns.Symbols | ||
| }) | ||
| }) | ||
| return symbolsURLs.String() |
There was a problem hiding this comment.
Blocker: This change is not safe. It will use a static configuration that won't change over the lifetime of the process. Additionally I worry about potential deadlocks if the conf package is not ready given this is called inside of LoadConfig.
There was a problem hiding this comment.
This required a bit more context to fix, so I went ahead and pushed a fix for this :)
| return conns.Symbols | ||
| }) | ||
| }) | ||
| return symbolsURLs.String() |
There was a problem hiding this comment.
This required a bit more context to fix, so I went ahead and pushed a fix for this :)
Co-authored-by: Keegan Carruthers-Smith <keegan.csmith@gmail.com>
RE: sourcegraph/deploy-sourcegraph#4213 & https://github.com/sourcegraph/sourcegraph/issues/45861
Summary
This feature is also backward-compatible, so existing setups and instances will not be affected by this change.
This PR adds the ability to accept replicas number for
Gitserver,Indexed-search,Searcher, andSymbolsvia existing env vars (SEARCHER_URL,SYMBOLS_URL,INDEXED_SEARCH_SERVERS,SRC_GIT_SERVERS), and then generate a new list of endpoints based on replicas number instead of listing out each replica endpoint manually.Background
Issue: Our current default setup only works in RBAC-enabled clusters.
RBAC for frontend is used for service discovery as it is essential for frontend to arrange communications between services; however, this default setup often leads to delays and frustrating deployment experiences for those without the ability to create RBAC resources. As this is a common deployment pain point and issue that has negative impacts on both the customers and our business, our team believes this is something we should address.
Proposed Solution
A new base cluster introduces in sourcegraph/deploy-sourcegraph#4215 provide an option for users to set up a working Sourcegraph k8s instance with or without RBAC enabled for frontend.
When RBAC resources are removed from frontend, Sourcegraph will not work properly unless a list of services endpoints is included in the frontend env var list using existing env vars that are also being used in our docker-compose deployment , which is a task that relies on users inputting the correct values manually.
The functions introduce in this PR aim to minimize the time our users/customers have to spend configuring their deployment (e.g. spending time inputting the endpoint addresses for each service manually) by generating the endpoints in frontend based on the replica number provided via env vars.
IMPORTANT The changes made in this PR should NOT break any existing setup or instances. No additional changes are required in existing manifests.
Expected Behavior
The current behavior is the same for all instances (both existing instances and new instances), which means:
endpoints URLsenv vars set are default to using Kubernetes service discoveryExamples:
Return endpoints generated with the replica number:
Test plan
sg.config.overwrite.yamlfile in the root of this directory:sg start enterpriseThe expected new endpoints using the file shared below should look like:
"gitserver-0.gitserver:3178", "gitserver-1.gitserver:3178", "gitserver-2.gitserver:3178", "gitserver-3.gitserver:3178", "gitserver-4.gitserver:3178""indexed-search-0.indexed-search:6070", "indexed-search-1.indexed-search:6070", "indexed-search-2.indexed-search:6070""http://symbols-0.symbols:3184", "http://symbols-1.symbols:3184", "http://symbols-2.symbols:3184""http://searcher-0.searcher:3181", "http://searcher-1.searcher:3181", "http://searcher-2.searcher:3181"sg.config.overwrite.yaml:Example output from running sg start: