3scale-labs / porta-dev-tools

CLI tool to play with 3scale/porta locally and on OpenShift
3 stars 7 forks source link

Fix Zync dependency on PostgreSQL #17

Open jlledom opened 1 year ago

jlledom commented 1 year ago

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

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

mayorova commented 1 year ago

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

akostadinov commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jlledom commented 1 year ago

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 commented 1 year ago

start, stop, and reset sound good to me too

jlledom commented 1 year ago

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.