Open mfateev opened 5 years ago
And default the CLI domain option to the default one to not require it initially.
Consider having a flag when starting Cadence to prohibit registering new domains to distinguish single domain deployments. This would make hiding domain feature easier in CLI and UI.
Is this feature on the roadmap?
Having a default domain for developer setup definitely sounds like a nice feature as it removes additional step of domain registration for someone new trying out Cadence. But I don't think having seamless domain registration for Production clusters is a good idea.
There is a lot of behavior tied to domain entity like retention, archival, replication, etc that hiding of all that would cause issues later down the road. It is much better for users to understand all those concepts before running production load.
I have two use cases for this feature:
In both cases there is a need to have a domain set up with predefined settings and it is achieved one way or another. IMHO it's not a "default" domain that's important, but the ability to automatically setup domains.
I would imagine this as a configuration setting which would require the user to enter certain information that in turn would presume that the user understands the domain concept.
I'm completely with you about 1. We need to make that easier and having domain created with default settings removes one friction point for someone new from trying out Cadence.
Cadence is more like database and creation of domain is like creating Cassandra keyspace. I have not seen any database setup where application specific entities are pre created as part of database setup. These entities are always created separately.
Do you expect your customers to directly use Cadence CLI? Or Cadence is completely hidden from them? I do see your point to expose a hook for single domain installations does makes things simple. The thing I'm worried about is supporting this feature for all possible use cases will make Cadence docker setup hard to maintain.
Or Cadence is completely hidden from them?
Yes it is.
The thing I'm worried about is supporting this feature for all possible use cases will make Cadence docker setup hard to maintain.
I'm not sure why. I imagine this feature would be exposed as an env var and mapped to configuration.
MySQL starts with a default test database, yet everyone knows that it's not recommended for production use.
The alternative is a Cadence bootstrap component (like the one linked above), but it has to wait for Cadence to be ready and waiting on resources is always a pain.
Setting up a domain is an additional concept which is not needed for the majority of the customers which are just starting with Cadence.
I would propose creating "default" domain automatically and change all samples to use it. I would also support domain creation as a docker image argument (or may be the schema setup argument?) even for single tenant production deployments.