Hi, I've been doing a lot of the work to replace the aging setup-ds.pl script with a python tool. I would like to discuss this direction in light of our desire to put ds in a container.
Fundamentally, containers are about a static application, that are completely bundled. There is no guarantee that rpm upgrade scripts or otherwise are run. This is very contrary to our current model of setup-ds.pl, and partially even our model of dscreate the new python tool. I'm wondering if we need to change our approach here. I think that perhaps it could be worth us saying "right, the python installer was fun, but it doesn't work in containers". Upgrades between DS versions is a big part of this equation. I think that instead, we should develop a C (or Rust ;) ) module inside of ns-slapd that does this for us. We have access to libini for C, or toml in rust that can parse the setup.inf, do our "templating", and create directories etc on first run. We can write in a config value like nsslapd-config-version: xxxx, and then on each upgrade we can update that value. We would provide all our upgrade and migration scripts as modules that run "just before" the socket listeners start and we start processing operations. This would reduce instance creation to: ns-slapd create -f setup.inf It would also mean that in containers on upgrade, we upgrade at startup - and the same is true of current deployments. I think that we should consider this as a better approach. Containers encourage tighter, integrated modules, and I think that we should follow this path if we want to be successfully integrated in this space. Comments and questions? If I don't hear back in say the next week, I'll just assume everyone is cool with this topic, and I'll start working on it. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
