-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log Service Setup #1721
Log Service Setup #1721
Conversation
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
Cmd.Flags().StringVar(&conf.Username, "username", "root", "MetaTable username") | ||
Cmd.Flags().StringVar(&conf.Password, "password", "", "MetaTable password") | ||
Cmd.Flags().StringVar(&conf.Address, "db-address", "127.0.0.1", "MetaTable db address") | ||
Cmd.Flags().StringVar(&conf.SystemCatalogProvider, "system-catalog-provider", "database", "System catalog provider") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we sure want to change the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes because memory is not Postgres and I want to have local end to end set up to include postgres
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, can we add some tooling to clear/nuke postgres in that case as a follow up? its useful while debugging to be able to easily clear the sysdb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3 parts of this:
- unit tests: should clean up the state - add setup and teardown (I can add this, very easy)
- local tests: scripts to nuke, for now the easiest thing is to just drop and re-create the db
- docker end to end test: there is a refresh button in tilt UI, one click should do the work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker restart should not remove state. We should use volumes correctly and have a script provided for People to reset the db
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not use volume for the local docker setup as of now. can go add that later if we want persistence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use volumes. Lets do the right thing from the get go please!
@@ -21,7 +21,7 @@ func (s *segmentMetadataDb) DeleteBySegmentID(segmentID string) error { | |||
func (s *segmentMetadataDb) DeleteBySegmentIDAndKeys(segmentID string, keys []string) error { | |||
return s.db. | |||
Where("segment_id = ?", segmentID). | |||
Where("`key` IN ?", keys). | |||
Where("key IN ?", keys). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reason for change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because unit tests were using sqlite and this throws an error when I change them to postgres
@@ -0,0 +1,39 @@ | |||
apiVersion: apps/v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: probably not wanted in dev/. dev/ is meant for deployments we only use while developing (like the postgres service)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should rename it, but the /dev is use by tilt only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woops! my bad - i confused this for test/ - I didn't realize we added dev/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add these to deployments/ too then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think yet we decided how to do sql migration EDIT: my comment was not related to the right file.
Yes, we should also add it in deployment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry I was confused? This is already in dev and we don't want to add this to deployment because we probably will do this differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/chroma-core/chroma/blob/main/k8s/deployment/kubernetes.yaml we should add the deployment for the log service in that file too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I see, this is what is used for minikube and kube apply. ok I can add that. Can we make them into one version later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense. Please try to break up larger PRs in the future. There are several logically separate changes in this PR. I ask that we make sure @Ishiihara Has a chance to look at this before we merge, given that he's done the bulk of our Go work to date.
Also the coordinator tests are segfaulting.
https://github.com/chroma-core/chroma/actions/runs/7909839228/job/21591525871?pr=1721 |
yea this is because we don't have postgres in our github setups. I will post to the team channel about this |
He is out until next week. Are you ok with me merging but ask him to review and make changes in separate PR next week? |
Yeah that is fine - this was before he sent his OOO :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding correctly this seems like two separate changes to me:
- Initialize logservice code and stand up log service.
- Move coordinator off sqlite for testing.
Could we split these into two PRs? If I'm mistaken or there's a strict requirement for these to be 1 PR please tell me.
@@ -188,7 +258,7 @@ spec: | |||
spec: | |||
containers: | |||
- command: | |||
- "chroma" | |||
- "coordinator" | |||
- "coordinator" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I feel a little weird about these commands being coordinator coordinator
and logservice logservice
. Could we make them coordinator run
and logservice run
or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea sounds good to me I will open a follow up pr for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the logservice living in go/coordinator
. Could we move it to go/logservice
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan is to have:
- coordinator (we can rename this to sth else later)
- logservice
- sysdb
- cluster manager
does that sounds good to you?
Yes they don't have to come in one PR. The logservice shares the same code connecting to Postgres so I made the change in one PR. Will separate them next time! |
## Description of changes https://linear.app/trychroma/issue/CHR-241/stand-up-log-service - Stand up Log Service in Dev - stand up postgres DB - stand up migration: atlas - depend on postgres - stand up logservice - depend on migration - stand up coordinator - depend on migration - database migration - change env name - change database name - add definition for reccord log (we can test perf for this later, not hard to change) - log service: go - entry point: main with Cmd - grpc service: with proto change - coordinator - connect to docker postgres - reorganize packages to accommodate with logservice - rename bin to coordinator instead of chroma - tests connect to local postgres instead of sqlite - fix a bug from segment delete - system_test fix will be in a separate PR
Description of changes
https://linear.app/trychroma/issue/CHR-241/stand-up-log-service
Test plan
How are these changes tested?
Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?