ownCloud gives you universal access to your files through a web interface or
WebDAV. It also provides a platform to easily view & sync your contacts,
calendars and bookmarks across all your devices and enables basic editing right
on the web. ownCloud is extendable via a simple but powerful API for
applications and plugins.
This is a container that utilises httpd and mod_ssl, it can be used standalone with the embedded sqlite database but it's suggested in production use to be connected to a postgresql or mariadb database by whichever method the admin prefers.
Volumes are provided for the httpd config (so that ssl certs can trivially be added by an admin), owncloud config and owncloud data locations.
To test the container:
docker build -t owncloud .
docker run -d P --name owncloud owncloud
docker port owncloud
Open browser to https://localhost:<exposed-port>/owncloud/ and follow the prompts to add an admin user and point to a database (or just use the built in sqlite for testing).
Fedora Account System Username: jhogarth
In addition to the other issues mentioned, this is a terrible container. Owncloud is a multi-component platform, which should be broken into 3 or more separate containers, not lumped together in one container like porting a VM. Official Fedora containers need to be examples of good containerized application design.
This container should be sent back and broken into several services.
This is just to sort of talk I'm hoping to engage with given the early developments of the container review process.
In case you are not aware I am the owncloud maintainer in fedora/epel so am intimately aware of what it involves.
This container is explicitly httpd+mod_php+mod_ssl as a minimal base, which is the predominant deployment I've found.
This explicitly does not include a database (other than a test sqlite instance) but directs the admin to have a database served out of another host/container and that's an exercise for them.
This is just one component - though the one most people expect - and is similar to the way it's packaged as a container upstream (not identical as it tries to take advantage of Fedora features and infrastructure).
> Official Fedora containers need to be examples of good containerized application design.
> This container should be sent back and broken into several services.
I'd appreciate some constructive feedback (which is the point of reviews after all) on where you think a better split or an improved Dockerfile would worked out - particularly given the lack of guidelines at present.
I care about these packages for some bizarre reason and I care about those who consume my packages.
It was a crying shame when I had to retire owncloud from EPEL6 and point users elsewhere, when the time soon comes to retire from EPEL7 I'd really like to be able to point them to our containers to migrate to.
Ah, I misunderstood the test SQLite instance as the real database.
So the other obvious part is the file storage for WebDAV documents. When I was looking at contianerizing OwnCloud myself I identified a couple other components; let me find the writeup and I'll post it here.
There's also Fedora's limitation to unsupported PHP, which is going to be a problem here ...
Discussed structure of container on IRC. Additional components *are* separated. This more points to the need for additional metadata in dockerfiles for the build service. Will be following up with suggestions.
Just to clear up in the PHP bit ... these are the owncloud packages we support on Fedora and that we support on the PHP shipped with Fedora - nothing special.
It's best not to get wrapped up in that as if there were issues we'd be dealing with them in Fedora anyway (eg we will have PHP71 in F26 but that needs some maintainer love to backport a patch from upstream, which I already do and support, since they don't intend to support PHP71 until owncloud 10 themselves).
Ignore PHP versions here ... that's up to our talented package maintainers in fedora ;)
Small note this has been updated to owncloud 9.1.4 now that it has hit the stable repos.
The key questions I feel need to be answered in the guidelines to progress this review are now in the Cloud SIG pagure instance for discussion.
After a check on #fedora-cloud these needed to be in the atomic-wg not the cloud-sig one.
Following the output of the discussions on Friday about the description/help labelling, systemd handling and volumes this dockerfile has been updated and the README added alongside it
Getting worked up to test fully. I hope this works, because I'll be running it for my own use ...
There's going to be one final version of this once owncloud-9.1.4-4.fc25 hits stable.
This is going to enable the owncloud-cron.timer systemd unit and configure background jobs to use that, rather than webcron, as a much better way of handling that maintenance stuff required.
Once that is in place, and any final cleanup to bring it inline with all the guidelines coming out of the VFAD, we should be good for the final review :)
OK. Let me know when. In the meantime, I'm giving it a practical test.
This is an automatic check from review-stats script.
This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.
This is an automatic action taken by review-stats script.
The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.