Skip to content
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

Create default domain for development docker image #2343

Open
mfateev opened this issue Aug 5, 2019 · 9 comments
Open

Create default domain for development docker image #2343

mfateev opened this issue Aug 5, 2019 · 9 comments
Labels
good first issue Up for grab as first issue to contribute to Cadence project serviceability Improvements to servicing of Cadence Server up-for-grabs Issues that are good entry points for those new to Cadence that want to contribute wishlist

Comments

@mfateev
Copy link
Contributor

mfateev commented Aug 5, 2019

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.

@mfateev
Copy link
Contributor Author

mfateev commented Aug 5, 2019

And default the CLI domain option to the default one to not require it initially.

@mfateev
Copy link
Contributor Author

mfateev commented Aug 13, 2019

@mfateev
Copy link
Contributor Author

mfateev commented Aug 13, 2019

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.

@sagikazarmark
Copy link
Contributor

Is this feature on the roadmap?

@samarabbas
Copy link
Contributor

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.

@sagikazarmark
Copy link
Contributor

I have two use cases for this feature:

  1. In a development environment I want to avoid every extra setup steps as possible. Currently we do that by creating a default domain in the app (which is arguably worse. In this sense a Cadence domain is similar to a database. Just don't create it from your app)
  2. We ship cadence with our platform. We use a single domain with predefined configuration. Unfortunately, we are once again forced to create the domain from within the application.

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.

@samarabbas
Copy link
Contributor

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.

@sagikazarmark
Copy link
Contributor

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.

@meiliang86 meiliang86 added stability Server stability issues serviceability Improvements to servicing of Cadence Server wishlist up-for-grabs Issues that are good entry points for those new to Cadence that want to contribute and removed stability Server stability issues labels Mar 1, 2020
@demirkayaender demirkayaender added the good first issue Up for grab as first issue to contribute to Cadence project label Nov 1, 2024
@taylanisikdemir
Copy link
Member

There are 2 flavors of docker image Cadence releases. One is for production use (TARGET=server) and the other is for local development (TARGET=auto-setup).
The startup script invoked in "auto-setup" mode sets up DB schema and it can also register a test domain so there's one less command to run for users each time they start a fresh cluster locally or in CI/CD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Up for grab as first issue to contribute to Cadence project serviceability Improvements to servicing of Cadence Server up-for-grabs Issues that are good entry points for those new to Cadence that want to contribute wishlist
Projects
None yet
Development

No branches or pull requests

6 participants