[csw-maintainers] Define supported use cases and work from there

[Philip Brown]

Sorry for the late reply...



On Sat, Jun 26, 2010 at 8:57 AM, Peter Bonivart <bonivart at opencsw.org> wrote:
> On Sat, Jun 26, 2010 at 5:53 PM, Philip Brown <phil at bolthole.com> wrote:
>> On Saturday, June 26, 2010, Peter Bonivart <bonivart at opencsw.org> wrote:
>> ....
>>> I suggest that we define which use cases we should support and in
>>> which priority.
>>
>> You make it sound as though this was not previously defined. But it
>> has already been defined, and documented, for over 4 years,
>> approximately....
> Is this documentet? Where? Should we support client utilities only or
> full server daemons?

The following references existed on the old website for a long time,
so please ignore the apparent "newness" of the urls:

http://www.opencsw.org/use-it/
   "For the most part, they are suitable for deployment both locally,
and on an NFS-shared filesystem. Packages usually install their
software under /opt/csw"

http://www.opencsw.org/use-it/sharing-optcsw/

   "The comments on this page are targetted towards sharing /opt/csw
read-only between multiple  machines, or between zones."

There are more. I trust I dont have to dig up more documentation
references for you though?



>
> Maybe someone else than you should come forward for those "big
> enterprises" using NFS since I can only remember you promoting them.
> I've never seen any active maintainer other than you be interested in
> this use case.

There was one other maintainer who was, for quite a while, using a
deployment strategy essentially identical to "shared read-only NFS".
His site was using replication across thousands of machines.
Dont remember his name though.

As a matter of principle, though, it shouldnt matter that it is "only
one maintainer" concerned about an issue. Doesnt matter if it's me, or
someone else. If "one maintainer" is concerned about an issue that
impacts his site, and I personaly dont care about it, i still try to
look for solutions to it.
Just like in the field of QA and bug reporting, where 1 bug report
represents 100 silent users with the same problem; 1 maintainer
potentially represents 100 other sysadmins in the same situation.

> However, it's about more cases than the dreaded NFS.

yes, quite. as I just mentioned above. it also covers replication, and
cross zone deployment strategies of, "mount this, but I dont want to
deal with the overhead of pkg-inherit garbage for 10 zones".

To use one of our competitors as an example:

Someone may choose to share a /usr/local read-only, populated via
sunfreeware packages.
They may share it via nfs, or replication, or zone machine as mentioned above.
THEIR packages will not suffer degredation via this method. (any more
than they already are, anyway ;-)
I'd like to ensure our packages can do just as well in that sort of situation.

I'll also point out that in the non-NFS cases, the argument about "you
shouldnt run demons from NFS anyway" does not apply.

The http://www.opencsw.org/use-it/sharing-optcsw/ mentioned above,
explicitly attempts to remind both users and maintainers, of issues
relating to this sort of deployment.
If you have suggestions to make this stuff better visible to
maintainers, please speak up.