phpMyAdmin service implementation

[hardyjohnson]

This is a discussion of adding the phpMyAdmin application as a service in Warden and how that might best be implemented.

There is a current implementation which was merged into the main branch #801, where I posted some questions and it was suggested to discuss here. This implementation is done as a global service which can configure multiple environments to use a single phpMyAdmin instance? (@monteshot?)

Discussion points regarding the current implementation:

1. Should this be a global service?
2. How to best manage configuration data and overrides for this service?
3. Should phpMyAdmin be an opt-in or opt-out service if done globally?

Thank you to @monteshot for the feature.

[bap14]

I don't have an issue with this being a global service; however, I prefer to opt-in to services as needed. In my opinion we should only spin up what is minimally needed for Warden to function (traefik, ssh, mailpit, DNSMasq). Everything else should be opt-in. This keeps Warden "light" on services while offering flexibility to start them automatically via ~/.warden/.env customization.

With regards to configuration I think it would be best to keep a config.user.inc.php file in ~/.warden/phpmyadmin/. When someone calls warden svc up, and the database is enabled, it would have to update the configuration to add the credentials. When warden svc down is called the database is removed. This may end up being kind of a 2-step process to first keep the credentials in a JSON format, then output that JSON object as an associative array. (see: https://docs.phpmyadmin.net/en/latest/setup.html#customizing-configuration ).

[hardyjohnson]

I agree that we should keep svc to what is minimally useful and everything else should be opt-in.

This seems like an edge case scenario, a phpMyAdmin service to access all running environments' databases simultaneously.

Why wouldn't we follow the set pattern of the other environments in the Warden project where configuration via environment variable is used at the project level (esp. as it looks like PMA supports Docker configuration via environment variables without needing to manage the config.user.inc.php file at all...).

This would not stop someone from doing this at the global level via ~/.warden/warden-env.yml and it would make it possible to easily extend projects on a one off basis which wanted to add the PMA partial or via project level .warden/warden-env.yml.

[navarr]

Here are my thoughts as they come to me. So I apologize for how confusing this post might be :)

I am constantly on the fence between a lean and mean Warden and a Warden that tries to make things as simple and as easy as possible for everyone. The merge of phpMyAdmin as a default enabled global service was part of the latter camp. I approached it with a "well, someone put work into it. It shouldn't be too difficult to maintain. It will improve some developers lives - why not".

On that line of thinking, I would like to retain it as a global service that is by default enabled, but can very easily be turned off. Likewise, the desired state of it would be to not cause problems anywhere else.

You also previously mentioned on the ticket that it was causing problems by adding content to stdout where you might expect a specific type of formatting.¹ I think that is in fact a problem, and one that seems easily fixable to me. If we believe the output contains value, we should migrate it from stdout to stderr. This is not something I've ever put a lot of thought into before you raised these issues, but there does seem to be consensus behind diagnostics/notices being part of stderr instead of stdout when stdout should contain a program output especially. ²

I like the idea of using environment variables instead of a mounted configuration file, and I think it's worth investing some time into investigating if we can do it well.

[hardyjohnson]

First, thank you and @bap14 for shepherding this project forward! I know it can seem a thankless task being an open source maintainer.

I think we all value stability in APIs and software releases, my goal is to help Warden be a little more consistent with the patterns it uses. This will help long term maintainability and allow others to learn and follow the code base without running into unexpected behavior.

I would love your input on the following and hoping we all are in agreement for these things moving forward:

1. An agreement with the maintainers that global service changes should be considered a breaking change. This should include the addition of new default on services.
2. New global services can be accepted into a non breaking change release, but MUST be default off until the next full release.
3. Changes to global services SHOULD be considered breaking, but MAY be merged into a point release at maintainer's discretion.
4. Warden as a project SHOULD adopt a definition of done for PRs which should include removing old functionality if functionality is replaced or deprecated, documenting changes with language describing the intent of change and how the change can be used in the user visible documentation repo.

[bap14]

@navarr My only reason for suggesting a file for configuration was efficiency. If we use a file and you start a new project, you add on to the existing array of servers in the file and write it, a small and fast task. If we use environment variables and start a new project, we now have to know what instances of Warden projects are running, and get the configuration for each one.

The other issue I see with using an environment variable is as we rebuild the server list we will either need to parse out the DB credentials from each environment, run the source command like we do for other commands and then re-run it for the current project (to reset the values to the current project), or we just leave credentials out and list the database instead.

I'm 100% onboard with @hardyjohnson 's thoughts on moving forward.

[navarr]

@hardyjohnson I appreciate your input a lot. There are going to be some points I disagree on, but I appreciate that you're bringing them up and the place they come from. It means a lot to me!

I disagree with point 1. I don't consider a new default on service to be a breaking change to in any way shape or form. I would like to uphold SemVer as much as possible - and in reality, my goal is that there are as few breaking changes in Warden as possible. Preferably none though that's not always possible. Points 2 and 3 really kind of roll with that one, but I don't consider that the move forward. Warden's goal is to be a tool for local development. It is not a CI/CD tool, nor is it a production tool and I'd rather not limit it's usefulness to the confines that being such a tool would bring. My goal as the maintainer for Warden is to try to ensure it is always a practical and simple tool for a developer to bring up a reliable environment to work in with tools to make their job easier. So I disagree with big waits on bringing in new services (especially with how slow I already am to make releases).

That said, if you have further arguments in support of point 1 that you think I'm missing, I am incredibly open to hearing them and changing my mind! I could be overlooking something, and I do appreciate your viewpoints here! I cannot emphasize that enough. Thank you for bringing it to the table.

I completely agree with Point 4. We do need a better definition of DONE for PRs. We've been very loosey-goosey because my own speed with the project is already pretty demoralizing to potential contributors.