Conversation
This structure will handle all the database operations and turn that into the right models. Note that for provider endpoints we already have a way of setting these via configuration, so this is taken into account to output some sample objects that users can leverage. We probably need to set some hardcoded IDs sometime in the near future so we can reference these. But for now, IDs for these are optional. I also added a `source` field which allows us to tell where these providers came from. Signed-off-by: Juan Antonio Osorio <ozz@stacklok.com>
e6e34fe to
62d9aae
Compare
| config = "config" | ||
| db = "db" |
There was a problem hiding this comment.
Probably for a future PR but I think it's worth it to persist the provider information from config in DB. That way we can have a single source of truth
There was a problem hiding this comment.
this is an excellent point for discussion. Are we planning to keep the provider configs? what do we do when a user changes the API endpoint from the config?
There was a problem hiding this comment.
I think from now on for muxing we should keep the provider configs
what do we do when a user changes the API endpoint from the config?
I don't know how common it is to change the API endpoint of an LLM provider. Right now, a user would need to stop CodeGate and start it again with new config in order to change the API endpoint.
Keeping the provider configs in DB and be able to change them without stopping the server gives a better UX IMO
This structure will handle all the database operations and turn that
into the right models.
Note that for provider endpoints we already have a way of setting these
via configuration, so this is taken into account to output some sample
objects that users can leverage. We probably need to set some hardcoded
IDs sometime in the near future so we can reference these. But for now,
IDs for these are optional.
I also added a
sourcefield which allows us to tell where theseproviders came from.
Signed-off-by: Juan Antonio Osorio ozz@stacklok.com