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

Fix Zync dependency on PostgreSQL #17

Open
jlledom opened this issue Dec 1, 2022 · 9 comments
Open

Fix Zync dependency on PostgreSQL #17

jlledom opened this issue Dec 1, 2022 · 9 comments

Comments

@jlledom
Copy link
Collaborator

jlledom commented Dec 1, 2022

Zync needs a postgres instance available in the host, otherwise porta deps won't work. That forces the host to either:

  • Have a Postgres server installed and always running in the host
    • Not desirable, since it takes resources and it's not used often
  • Have a postgres server installed and start it manually before running porta deps
    • Not optimal, because the need to run a command manually makes porta-dev-tools less convenient
  • Launch a postgres container manually before running porta deps
    • Same problem as avobe

I suggest to launch the postgres container automatically before zync, so porta deps just works without any previous required step.

@mayorova
Copy link
Collaborator

mayorova commented Dec 1, 2022

It makes sense to add a zync-postgres container to porta deps, IMO.

@akostadinov
Copy link
Collaborator

idk, this is part of Zync Quickstart guide:

https://github.com/3scale/zync/blob/master/doc/Quickstart.md#run-postgresql-as-a-container-with-docker-or-podman

I have this container and use it for porta database when I want porta on postgres.

The situation is very similar with MySQL and porta. Why run MySQL separately and not controlled by porta-dev-tools?

Why run Redis separately and not as part of porta-dev-tools?

The 3 databases historically are manual to control.

I think we better have a strategy to all of them, not single out postgres especially because it is useful as a porta database too.

@jlledom
Copy link
Collaborator Author

jlledom commented Dec 2, 2022

Yeah that makes sense, so what if we decide to use mysql for our development environment, we configure zync to connect to mysql and launch both mysql and redis from porta-dev-tools?

What's the point of controlling the DBs manually?, to have the ability to switch between them? If that's the case I think we can handle that using porta-dev-tools as well, since we can configure the DBs through environment variables

@akostadinov
Copy link
Collaborator

Here some thoughts on your questions.

I think people prefer different ways to install DBs. But a more important reason to control manually is that I want DB running all the time. When I run tests locally from IDE or console, they still use the same DB.

Another important requirement for me is that databases be not wiped out on restart. Presently porta-dev-tools managed containers are created and destroyed, which resets them completely.

Also you can't use zync with MySQL. But you can use porta with Postgres.

Also we shouldn't enforce using same database for both. And we should allow running porta with any of the supported DBs.

In the case of Oracle, restarting the DB is slow. So starting and stopping all the time is suboptimal and more importantly - unreliable (we don't have a clear indication of when it becomes ready).

In summary, it seems to be a complicated thing. It's nice if porta-dev-tools can help with the databases. Existing use cases should be considered carefully though.

btw presently I use all DBs in a podman container. So if you come up with an approach to create and control them from porta (but not automatically wipe them out), that could be useful.

@jlledom
Copy link
Collaborator Author

jlledom commented Dec 5, 2022

Then, what if we create a new porta command to launch DBs containers? mysql, postgres and redis. To avoid data being wiped out, the only thing we need is to attach a volume to the containers.

$ porta db

Besides, the current porta reset and porta data could be parameters to porta db. So:

porta db # Launches the containers, it first creates the volumes if they don't exist
porta db --down # Stops the containers
porta db --reset # Resets the DBs
porta db --data # Generates fake data

@akostadinov
Copy link
Collaborator

Attaching a volume was a problem for oracle. Easiest is start/stop containers with their loal volumes. They get cleaned of container is removed. I would suggest commands

  • create
  • stop
  • start
  • remove

@jlledom
Copy link
Collaborator Author

jlledom commented Dec 5, 2022

Attaching a volume was a problem for oracle. Easiest is start/stop containers with their loal volumes. They get cleaned of container is removed.

OK, as long as a volume is used the data persists.

I would suggest commands

* create
* stop
* start
* remove

Are there other examples in porta-dev-tools where there's a command to remove the containers or where create is a different command than start? I think is better to manage the containers and volumes automatically and transparently, like in porta deps, so we keep a coherence with the other commands.

@akostadinov
Copy link
Collaborator

start, stop, and reset sound good to me too

@jlledom
Copy link
Collaborator Author

jlledom commented Jun 26, 2023

I forgot about this. I'd do it this way, to match porta deps options:

porta db -> start mysql
porta db --down -> stop mysql
porta db --reset -> same as current porta reset, which would be removed

Also --oracle and --psql versions

porta db --reset --oracle wouldn't work because of that password expiring problem. Which we should address at some moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants