Mailinglist Archive: yast-devel (59 mails)

< Previous Next >
Re: [yast-devel] storage-ng and cloud storage
On Tue, 30 May 2017 10:53:25 +0200
Stefan Hundhammer <shundhammer@xxxxxxx> wrote:

On 30.05.2017 09:00, Josef Reidinger wrote:
- Do you think it makes sense?


It is completely unrelated,

Why? Expert partitioner already have NFS, so could elaborate it a bit, why you
think it is unrelated?
From my POV it is storage, it make sense to mount it and I do not see too much
differences from NFS which is already there. So I probably miss your arguments.

nobody (in particular no product manager)
requested this,

The same is true for whole storage-ng, so if we think it can make sense, we can
discuss it with them, how they see it.

and it opens a new level of complexity

Can you a bit elaborate on it? I do not see difference to NFS. For initial
prototype it is basically one line in /etc/fstab . For providing more pleasure
user experience it will make sense to help with creating secret_file, but it is
not mandatory from beginning.

and a host of
potential problems (that are very likely to materialize very quickly).

With this approach we cannot touch any part of code.

We don't need to invent additional workload; it will be hard enough (and
enough work) as it is. Please do not introduce creeping featuritis (well,
actually not "creeping" but "gallopping") to add to the overall burden.

Please stop for a moment, deep breath and try to see it from user/customer
perspective. What currently storage-ng is from user perspective ( not talking
about quality of code, design anything ) is that you want them to select worse
software ( can do less ) that provide no benefits. I expect it can cause some
hate as early KDE4.

But as opposite to KDE4 we do not allow them to use both of them together. We
force to them only the new worse one.

To be honest I am also not so optimistic about passing this change over release
managers, especially opensuse tumbleweed. Because for bunch of openQA tests, we
have to say "not yet supported". And for question "so what is benefit" we have
nothing from user perspective. Answer like "it will allow multi-device btrfs,
partition-less disk, etc." is easy answer "so return when it have at least some
single benefit" ( and I am really not trying hard to be a devil advocate here
). So my attempt is to have at least something to answer to them.

- Does it make sense to add support for it also in libstorage-ng?
> And if so, how hard it will be?

Same answer as above.

We can at least try to have it as teoretical practice how hard it will be to
extend libstorage with something that was not initially designed.

- Does it make sense to also allow non-root access to partitioner via
> pam-mount configuration, so each user can mount his own google drive?

Aside from the security hazard aspects, why add yet another layer of
authentication complexity here? We have "sudo" and related. If there is the
need to award additional privileges to a user, IMHO that would be the the
first approach (if anybody actually nees that - which I still doubt).

This has the added benefit that *we* would not "roll our own" which is always
a bad thing in all security-related things. If we rely on a proven, existing
mechanism, it's not us who at some point in the future will have to fix
security problems (and backport them to who knows how many older releases).

Ok, fair point, so lets skip it for now. It is just idea that came to me mind
when we are discussing that "article" topic and how to make switch from windows
more smooth.

In general my estimation how fast I can do this feature without
> libstorage-ng and with augeas for fstab is one week of work.

See RFC 1925 paragraph 8, and as a corollary paragraph 3.

We estimate regularly in SCRUM and my general impression is that we are not so
bad with estimating. If you have different feeling, it is fine, but currently
we do not have anything better. Or you at least forgot to mention it.

Kind regards

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >