Help wanted: Preference Pane (no ZFS coding needed)

[Bjoern Kahl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Dear all,

to enhance user experience, I'd like to have System Preferences
integration of MacZFS (both, old and new port).

For now, I'd like to have a System Preferences Pane which
(1) reports the installed version
(2) offers an uninstall option
(3) offers an update check to look for new releases
(4) maybe offers launchd integration to schedule regular task like
scrubbing every week or running auto-snapshot etc.
(5) allow setting some options like visibility of snapshots.
(6) allow to create and destroy read-only or read/write clones from
snapshots
(7) tune some runtime / boot-time parameters (long-term goal, since
this requires to first define these parameters in the kext and
make them configurable)
(x) ... your ideas here ...

To support all this, we need a GUI design for the preferences pane and
code that interfaces with the standard zfs command line tools to do the
actual work. So the code in the preference pane would mostly run the
zfs and zpool binaries and parse their output for nice display on one
side, and on the other side call zfs, zpool, launchctl and friends to
alter setting.

If you are interested, please indicate on the mailing list. We can
then discuss how to best organize the work, document the main ideas
(and who is working on it) in our wiki / issue tracker ad get things
running.

Note that this Preference Pane should be written with the old MacZFS
74.x / 78.x as current target platform, but compatible with the new
experimental ZFS-OSX. Since it basically calls the zfs and zpool
utilities, this compatibility should not be an problem.


Best

Björn

- --
| Bjoern Kahl +++ Siegburg +++ Germany |
| "googlelogin@-my-domain-" +++ www.bjoern-kahl.de |
| Languages: German, English, Ancient Latin (a bit :-)) |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAgUBUVtQKVsDv2ib9OLFAQI5wAP/fvMnbisUgQkZuUaktRR3JVOBxSzfAw7T
CrQNdsg4bvxOnDiHk0qWMKv9J6mPT/hJ5Im5DJ5SUNKaaPxN11o2Y0e3P3bvVUy7
qCkaN81BR0DcVk0go5pTJ6roheZN3STTkIIdpCFcFJCyzFmQmqD8Or1x9T64lbIv
q5wzG800knc=
=FZAt
-----END PGP SIGNATURE-----

[Roddi]

I could offer some help there. To make the task easy someone should write up some details about where the installed files are and how to set those tunables on the command line.

Roddi

--

---

You received this message because you are subscribed to the Google Groups "zfs-macos" group.

To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Lucien Pullen]

Count me in. The rest of the email is some brainstorming that should be
delayed until we're ready to start but that I wanted to write down.



Also sprach Bjoern Kahl at 4/2/13 4:39 PM:

> (2) offers an uninstall option

For consistency with Apple's products that use installers (namely
iTunes[1]), I think that full uninstall should be a terminal thing.
We've already got fairly decent instructions that can be found by a
search engine easily.

> (3) offers an update check to look for new releases

I think this is a bit dangerous. With something as critical as a
filesystem, updating shouldn't be something as casual as updating your
text editor. ZFS /should/ be trivial to update, but only when the user
is ready, not because the version checker is nagging them.

Something I would like to know about this is the update policy. How do
you ensure to the user that the release being nagged about is truly
stable enough? Is this a scanner for whatever is "Featured"? or is it a
blessed version?

When the port is ready, I recall you saying we were going to abandon the
upstream numbers (or maybe I'm misremembering). As a one-time thing,
how will the update check cope with a different numbering scheme? Not
as important, but how do we convince users that "Y is more recent than
X" even if the number is lower?

> (4) maybe offers launchd integration to schedule regular task like
> scrubbing every week or running auto-snapshot etc.

Apple is deprecating cron in favor of launchd, but I still find cron
jobs to be much simpler to use and modify than launchd scripts
(especially for simple stuff).

How would you tune what day and time to run the scrub on? How would you
cope with different pools that have different needs? Can you set a
filesystem tree to not be included in (___) snapshots through the
interface? or is that something for a home-grown cron job?

> (5) allow setting some options like visibility of snapshots.

Why just some of the options? If just some options, how do we determine
what those are?

> (6) allow to create and destroy read-only or read/write clones from
> snapshots

> <snip>

> (x) ... your ideas here ...

Not so much an idea as more of a possible issue.

Is the preference pane written for the administrator? the user of a
system? or both?

Let's take a hypothetical user like my mom. She knows I've set the
system up in such a way that if she were to clobber a document, she can
make a clone in the pane, restore the file, then delete the clone in
much the same way. She doesn't know how the snapshots work, and if
there is any hint she does (like how to choose which snapshot to use
more complicated than "The most recent snapshot first."), I'll be
getting a phone call. Can she restore a file on her own through the
preference pane?


^1 I have not updated iTunes to the most recent version, so I don't know
if removing all its components is as involved any more.

[Roddi]

Am Mittwoch, 3. April 2013 um 14:50 schrieb Lucien Pullen:

For consistency with Apple's products that use installers (namely

iTunes[1]), I think that full uninstall should be a terminal thing.

We've already got fairly decent instructions that can be found by a

search engine easily.

Are you saying, that a user who wants to uninstall should do so by hand?

 

I think this is a bit dangerous. With something as critical as a

filesystem, updating shouldn't be something as casual as updating your

text editor. ZFS /should/ be trivial to update, but only when the user

is ready, not because the version checker is nagging them.

I wouldn't nag. Just display there is an update and a button to update.

 

Something I would like to know about this is the update policy. How do

you ensure to the user that the release being nagged about is truly

stable enough? Is this a scanner for whatever is "Featured"? or is it a

blessed version?

This is IMHO a philosophical question. But I think the normal user should see the stable releases, while the tester/thrill-seeker should be able to update to less well-tested versions, together with a big red warning sign of course.

 

When the port is ready, I recall you saying we were going to abandon the

upstream numbers (or maybe I'm misremembering). As a one-time thing,

how will the update check cope with a different numbering scheme? Not

as important, but how do we convince users that "Y is more recent than

X" even if the number is lower?

Is there something as a bundle version to check against? 

 

How would you tune what day and time to run the scrub on? How would you

cope with different pools that have different needs? Can you set a

filesystem tree to not be included in (___) snapshots through the

interface? or is that something for a home-grown cron job?

I wouldn't hard-code the "zpool scrub …" into the launchd script but rather write a background deamon that sleeps till it is ready to kick off whatever needs to be done. 

 

Why just some of the options? If just some options, how do we determine

what those are?

By popular demand? I wouldn't throw everything in right away.

 

(x) ... your ideas here ...

Not so much an idea as more of a possible issue.

Is the preference pane written for the administrator? the user of a

system? or both?

I would say admin. Your "my mom"-scenario is pretty much what I would expect from my own mum.

Roddi

[Lucien Pullen]

Also sprach Roddi at 4/3/13 8:08 AM:

> Am Mittwoch, 3. April 2013 um 14:50 schrieb Lucien Pullen:
>> For consistency with Apple's products that use installers (namely
>> iTunes[1]), I think that full uninstall should be a terminal thing.
>> We've already got fairly decent instructions that can be found by a
>> search engine easily.
> Are you saying, that a user who wants to uninstall should do so by hand?

As far as what I said, I didn't proofread, and I made my point poorly.
I mean we should offer something like an uninstall.command file separate
from the preference pane. For those that don't use that, there are
decent instructions.

The point I failed at making was that a configuration option that
removes the software seems out of place at that level.

>> I think this is a bit dangerous. With something as critical as a
>> filesystem, updating shouldn't be something as casual as updating your
>> text editor. ZFS /should/ be trivial to update, but only when the user
>> is ready, not because the version checker is nagging them.
> I wouldn't nag. Just display there is an update and a button to update.

Since this is a tool oriented at administrators, that should be fine. I
was thinking if users were going to use this [where a casual user may
not know if there was a good reason to not upgrade, and bug the admin].

>> Something I would like to know about this is the update policy. How do
>> you ensure to the user that the release being nagged about is truly
>> stable enough? Is this a scanner for whatever is "Featured"? or is it a
>> blessed version?
> This is IMHO a philosophical question. But I think the normal user should see the stable releases, while the tester/thrill-seeker should be able to update to less well-tested versions, together with a big red warning sign of course.

Sounds reasonable.

>> When the port is ready, I recall you saying we were going to abandon the
>> upstream numbers (or maybe I'm misremembering). As a one-time thing,
>> how will the update check cope with a different numbering scheme? Not
>> as important, but how do we convince users that "Y is more recent than
>> X" even if the number is lower?
> Is there something as a bundle version to check against?

The ZFS kext has the version in its Info.plist. I'm not sure what
you're asking about. There's also the central registry that Software
Update uses, that we currently don't use.

>> How would you tune what day and time to run the scrub on? How would you
>> cope with different pools that have different needs? Can you set a
>> filesystem tree to not be included in (___) snapshots through the
>> interface? or is that something for a home-grown cron job?

> I wouldn't hard-code the "zpool scrub �" into the launchd script but rather write a background deamon that sleeps till it is ready to kick off whatever needs to be done.

Hard coding the commands into the launchd script would be a bit silly.
I was wondering how we would save what the user wanted to do, and to pass
it on to the actual worker. Also implementation details.

[Michael Newbery]

On 4/04/2013, at 3:34 AM, Lucien Pullen <drur...@gmail.com> wrote:

> Also sprach Roddi at 4/3/13 8:08 AM:
>

>

>>> How would you tune what day and time to run the scrub on? How would you
>>> cope with different pools that have different needs? Can you set a
>>> filesystem tree to not be included in (___) snapshots through the
>>> interface? or is that something for a home-grown cron job?

>> I wouldn't hard-code the "zpool scrub …" into the launchd script but rather write a background deamon that sleeps till it is ready to kick off whatever needs to be done.

>
> Hard coding the commands into the launchd script would be a bit silly.
> I was wondering how we would save what the user wanted to do, and to pass
> it on to the actual worker. Also implementation details.

Until MacZFS fixes the bug where a snapshot interrupts and restarts a scrub, I would not even begin to contemplate scrub as a control panel.

I'm also not sure that a control panel off System Preferences is the right place to do much of this. That's good for simple things, and preferences focusing on zfs itself are appropriate for a control panel: version, presence of update, button to install update, ...?

For more complicated stuff I would rather see a separate app that lets you see pools, file systems, etc.. The sort of thing the FreeNAS console provides.

Personally, apart from the XML configuration which is not as human friendly as YAML (for instance), I don't have a problem with launchd. Once you get into anything even slightly complicated I prefer it to cron/crontab, and why bother with a background daemon when launchd is one already?

[Daniel Bethe]

Let's please take this discussion to the maczfs-devel list!

>>> I think this is a bit dangerous. With something as critical as a
>>> filesystem, updating shouldn't be something as casual as updating
> your
>>> text editor. ZFS /should/ be trivial to update, but only when the user
>>> is ready, not because the version checker is nagging them.

That's precisely how casual and easy any stable release must be, or else it wouldn't be a stable release.  It just periodically checks for the latest stable release via a simple URL and/or XML metadata, which in turn was issued to the web site against our existing, coherent release policy.  Just like every other updating app in the world.  By default, it would show the 'zpool status' data and could start a scrub, and it would have an 'advanced' button which is protected by the standard 'lock' icon, like any other preferences pane has.  But, there is no magical development release listed in a default control panel nor any nagging; no free software does that, nor would there ever be any reason and I don't know where anyone got that idea.  Your concerns are far too drastic, my friend!

>>> Something I would like to know about this is the update policy. How do
>>> you ensure to the user that the release being nagged about is truly
>>> stable enough? Is this a scanner for whatever is "Featured"?
> or is it a
>>> blessed version?
>> This is IMHO a philosophical question. But I think the normal user should
> see the stable releases, while the tester/thrill-seeker should be able to update
> to less well-tested versions, together with a big red warning sign of course.

There's nothing philosophical to it, just basic logic like every other piece of software.  It's just stable (release) or unstable (prerelease/development).  It's just metadata like I said.

>>> upstream numbers (or maybe I'm misremembering). As a one-time
> thing,
>>> how will the update check cope with a different numbering scheme? Not

>>> as important, but how do we convince users that "Y is more recent
> than
>>> X" even if the number is lower?

Coherent metadata would be issued against our existing, coherent release policy, as an every-time check.  There is no guessing or worrying or marketing or brainwashing or ..... whatever the rest of this is all about.  ;)

> script but rather write a background deamon that sleeps till it is ready to kick
> off whatever needs to be done.

Yes, to my limited knowledge, this is the silly and unreliable kludge that launchd requires of every arbitrary execution schedule.  And then you hope that process didn't crash, that the system never ran out of memory and killed it, or that anything else unexpectedly happened.  If I understand it correctly, I don't know how Apple thought this could possibly replace even 'cron'.  I hope I'm mistaken.

See ya on the maczfs-devel list, hopefully.

[Daniel Bethe]

https://groups.google.com/forum/?fromgroups#!forum/maczfs-devel

This is the URL to the maczfs-devel list again, just in case that helps to find it.  The easiest way I find it, is I surf to http://maczfs.org/ and click it on the bottom left.

[Daniel Becker]

On Apr 3, 2013, at 12:54 PM, Daniel Bethe <d...@smuckola.org> wrote:

> Yes, to my limited knowledge, this is the silly and unreliable kludge that launchd requires of every arbitrary execution schedule. And then you hope that process didn't crash, that the system never ran out of memory and killed it, or that anything else unexpectedly happened. If I understand it correctly, I don't know how Apple thought this could possibly replace even 'cron'. I hope I'm mistaken.

Launchd can actually automatically relaunch the process if it died for some reason (see the KeepAlive property). It also supports launching jobs at fixed intervals (StartInterval) or date/time patterns like cron (StartCalendarInterval).

[Bjoern Kahl]

Am 03.04.13 20:32, schrieb Michael Newbery:

>
> On 4/04/2013, at 3:34 AM, Lucien Pullen <drur...@gmail.com> wrote:
>
>> Also sprach Roddi at 4/3/13 8:08 AM:
>>
>>>> How would you tune what day and time to run the scrub on? How would you
>>>> cope with different pools that have different needs? Can you set a
>>>> filesystem tree to not be included in (___) snapshots through the
>>>> interface? or is that something for a home-grown cron job?
>>> I wouldn't hard-code the "zpool scrub …" into the launchd script but rather write a background deamon that sleeps till it is ready to kick off whatever needs to be done.
>>
>> Hard coding the commands into the launchd script would be a bit silly.
>> I was wondering how we would save what the user wanted to do, and to pass
>> it on to the actual worker. Also implementation details.
>
> Until MacZFS fixes the bug where a snapshot interrupts and restarts a scrub, I would not even begin to contemplate scrub as a control panel.

That bug should be fixed at latest when the new experimental ZFS-OSX
reaches its first beta. However, that will take several months to
happen. Unfortunately, it is not a MacZFS specific bug, as far as I
remember, but a defect in the upstream version.

> I'm also not sure that a control panel off System Preferences is the right place to do much of this. That's good for simple things, and preferences focusing on zfs itself are appropriate for a control panel: version, presence of update, button to install update, ...?
>
> For more complicated stuff I would rather see a separate app that lets you see pools, file systems, etc.. The sort of thing the FreeNAS console provides.

My intention was to keep these things simple. Especially, I had no
intention to create or support any fancy scheduling service. I
thought more of something like "scrub pool X every Y days / every Y
day-of week / every Y day-of-month."

> Personally, apart from the XML configuration which is not as human friendly as YAML (for instance), I don't have a problem with launchd. Once you get into anything even slightly complicated I prefer it to cron/crontab, and why bother with a background daemon when launchd is one already?

I think launchd is more future-proof then cron. Apart from that, I
also prefer cron for its simplicity.


Best regards

Björn

[Graham Perrin]

On Wednesday, 3 April 2013 20:54:44 UTC+1, Daniel Bethe wrote:

Let's please take this discussion to the maczfs-devel list!

Done: <https://groups.google.com/d/msg/maczfs-devel/HBurtudl_QQ/8O6_mJzjtkMJ>