Charm needed: phpmyadmin

[Ahmed Kamal]

Formula needed phpmyadmin. This is to provide a management webUI for a mysql instance

[koolhead17 (koolhead17)]

i would like to work and come up with formula for this!!

[Dave Walker (davewalker)]

koolhead17 reported that this is blocked on bug 807038.. advise and suggestions welcome :)

[Mark Mims (mark-mims)]

you might grab bug #894157 when working on this

[Marco Ceppi (marcoceppi)]

Uploaded first draft for this charm, need to finish the relation-changed hook still

[Marco Ceppi (marcoceppi)]

The charm I've written is ready for review. It requires the linked mysql charm (unless that merge has been approved). Currently, you have to set a password for htaccess with via juju set phpmyadmin password= or you won't be able to access the exposed service.

[Mark Mims (mark-mims)]

Review:

Things to change:

- prefer the phpmyadmin package unless it's broken (please file bug if that's the case).

- Do you really mean to use 'chown -R www-data:www-data /var/www' for startup? If startup's a no-op, I'd recommend leaving it as a no-op. At the very least, please comment this to explain... it's unexpected. I'm thinking of somebody maintaining the charm in the future... don't make them hunt for what's going on.

Discussion/Recommendations:

- side note on CharmHelper... maybe move the templating into CH? I'd sure love for the process of: copy tpl, then sed vars
to be wrapped into a single apply_template() or something similar. Perhaps just use cheetah from the CLI? we'll discuss on #juju.

- no biggy at all, but maybe env/common could be lib/common.sh? That would make it clearer to me what it's for without having to read code.

- perhaps implement db-shared relation to provide phpmyadmin access to a single db? as per #juju

- perhaps a read-only config flag? as per #juju

cool man... thanks!

[Marco Ceppi (marcoceppi)]

Hi Mark,

I've taken care of the first two points. The first by implementing a use_upstream config switched (defaults to false), when switched to true a clean up will take place and upstream will installed - vice versa. The second item was just me scratching around when troubleshooting.

---

We talked about what do to for templating and nothing solid came out of the discussion. The current EOF methods work for now, anything bigger than this and a light weight engine will probably be required. I attempted to write one in bash and fell just a few inches short when I found out I couldn't pass assoc arrays!

Renamed, env is now used for environment (upstream/package) specific switching

I still need to look into this, as of right now it works fine but I'll open a bug against the package to look into this as long as it's not a blocker.

It doesn't appear that's something readily available in PMA.

Thanks!

[Mark Mims (mark-mims)]

# things to change:

- readme... please document the config settings... especially the ones that're critical for running. Heck, put a link to the youtube screencast. I think that's a great trend to start!

- db-admin-relation-changed, some confusion between the literal database name "phpmyadmin" and the database that the relation sets.

# discussion/recommendations:

- `parse_upstream` is pretty sensitive to changes in upstream naming. At least log any problems this has during `install_from_upstream()`

- upgrade? linking to install hook is usually the practice, but if you do that it looks like the `install_from_apt` method will bypass calling apt-get again to upgrade the package.

- templating's complicated enough to be a charm-helper IMO

- env/xxx seems a little complex... couldn't these just be locals to functions or just functions themselves in common.sh? I like the idea of building things into general tools (and _great_ job with charm-helpers BTW!), but not sure it's worth it here.

- stupid nit-pick, but in your public api (config.yaml)... some config setting names use `-` and some `_`

- let's investigate if the upstream/apt optional install tools should be part of charm-tools... I think it should, but I'm not sold on using it all the time... only in special circumstances like when the currently packaged version really sucks or something.

- It looks like you're re-`build_cfg()`ing every time a config-change happens... do you need to bounce apache for that? don't know.

---

Nice job on the charm... this handles a lot of complexity with the upstream options, but still looks pretty robust and maintainable.

Thanks!

[Marco Ceppi (marcoceppi)]

Hey Mark,

Thanks again for the indepth feedback and helping me get this charm in shape!

- Documented, with the link to the video :)

- This will now track the _right_ database to use

- I agree, parse_upstream will now jump ship and exit if there's any problem during processing

- I've created an upgrade hook which will do a proper upgrade when needed

- I agree, I've started working on file.sh for charm-helper-sh

- I was on crack

- It's an interesting idea, and it would be pretty easy to build a set of standard tools for this. Discussion should take place about how much is too much

- Nope, it's all php configs so it's interpreted on each page load

[Mark Mims (mark-mims)]

Looks great!

Please promulgate and mark this fix-released.

One other thought:
A user looking at this for the first time doesn't know which login to use or which path to use to get to phpmyadmin in the browser... maybe we should add these into the readme?