On 01/10/13 17:03, Tim Foster wrote:
On 01/11/13 06:09 AM, Dave Miner wrote:
On 01/09/13 16:38, Tim Foster wrote:
The only downside I can think of against using off-BE storage, is if we
were to rev the repository format incompatibly, we could have different
BEs potentially being unable to read the repository contents, but this
seems unlikely.
I think that does seem unlikely, and the upside of keeping this out of
BE's is pretty large.
Right.
Did you consider making this a separate dataset, rather than just a
directory? Or do we want to discourage the idea of replicating further
using zfs send/recv?
It would be nice to have a separate dataset, but the mechanics involved
in getting one are complex today. (I wonder do we need self-assembly for
zfs datasets, though actually in this case, having packaged software
decide when to create/destroy datasets in a non-packaged location is
almost certainly the wrong answer)
I'd need to deliver a separate service[1] to check for, or create these
datasets:
rpool/VARSHARE/pkg
rpool/VARSHARE/pkg/repositories
then delegate administration of the 'repositories' dataset to 'pkg5srv'.
I'd then need code in the svc-pkg-mirror method script to create
datasets _if_ the 'config/repositories' SMF property pointed at a
directory that happened to be at the top level of a container dataset in
which we have permissions to create child datasets.
.. which all seems pretty messy because it won't be obvious if we
haven't been able to create a separate dataset for the repository
because of a misconfiguration, or because the user intentionally doesn't
want a separate dataset for the repository.
Understood; I see David suggests a way around part of this, perhaps.
The one odd part of /var/share is that sharing the repo over NFS is
reasonable and that would slightly argue for something under /export
instead, but in principle I can't come up with a reason to discourage
sharing of things under /var/share.
Does anything require an rpool/export dataset today, or ensure that it's
always present? I'm nervous that a customer may have their own specific
setup for "/export" such that we shouldn't be making assumptions on what
filesystem is actually mounted on that mountpoint.
I can't say it's required, but highly encouraged. The interactive
installers will create rpool/export, and it's specified in the standard
AI manifest (along with rpool/export/home) but can be deleted if the
user doesn't want it.
We're slightly safer with rpool/VARSHARE, in that we guarantee it's
available with /lib/svc/method/fs-local. I agree that it'd be better
not so share everything under /var/share though.
In short, yes we could do this, but it's tricky - I'm happy to take
recommendations, but I think creating a directory in
/var/share/pkg/repositories is enough, letting the user decide whether
they'd like that directory to be its own dataset.
I wouldn't say I feel strongly about this, but I would probably
recommend to users to create separate datasets as a best practice and
that's been a guiding principle in many of our decisions, so that's why
I raise it.
Dave
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
