I'll try to accomodate as much feedback as possible, aiming for 1.4.2 to be out first
fully supported release. Sounds okay?
On 29 Aug 2019, at 12:55, William Brown
<william(a)blackhats.net.au> wrote:
Hi all,
I've been wanting this for a long time and I think we're almost there - I'd
like us to start offering docker images of 389 Directory Server as part of our upstream
release process.
I have discussed this with Mark already and we both think we are reasonably happy with
the idea and the state we're in.
-- The Technical Process and Details:
As there is significant interest within SUSE for containerised 389, as well as open
tooling as part of
build.opensuse.org, the current proposed process is:
Source Release -> OBS:network:ldap -> OBS:389-ds-container -> docker hub
Because this pipeline is automated between source to the container, and this is already
part of my responsibility as the SUSE package manager, it's a small amount of effort
to then mirror the container to docker hub.
I have already established an organisation on docker hub, and will be giving Mark access
to be able to manage this as well.
https://cloud.docker.com/u/389ds/repository/list
Initially we'll name the image as:
389ds/dirsrv:1.4.rc
Once we are happy with the process, and have received some community feedback we'll
move to:
389ds/dirsrv:1.4.1
389ds/dirsrv:1.4.2
389ds/dirsrv:1.4 # points to latest 1.4.X
389ds/dirsrv:latest # points to newest version
We would of course encourage people to use the "latest" tag.
-- Support
During the rc phase we would announce that the container support is "best
effort" and we'll obviously work to resolve issues, but it's not suitable for
production work loads.
Once we are happy with this for a few releases, we'll move to the same support levels
as our normal releases - best effort community, and patch backporting as we normally do.
For official support, contact a vendor like SUSE or Red Hat.
-- Future / Downstreams
The design of the container integration is such that we should be able to easily swap the
suse/fedora/rhel as the base image, so downstreams should be able to easily adopt the
dscontainer tool and have customers pivot from the upstream image to their vendor image
quite easily.
A future container option is to supply a tools container that has a shell + ds* tools, so
that you can have a work flow such as:
docker run -v 389ds:/data 389ds/dirsrv:latest
docker run -i -t -v 389ds:/data 389ds/tools:latest
# shell inside of the tools container
# dsconf ....
-- Testing today:
To test the image as it exists today:
docker pull
registry.opensuse.org/home/firstyear/containers/389-ds-container:latest
Thoughts and feedback?
If there are no objects, I'll push the rc to docker hub early next week (2nd or 3rd
of Sep)
--
Sincerely,
William
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproje...