[yast-devel] storage-ng and cloud storage
Hi, yesterday we are discussing a bit plans about merge storage-ng, new partitioner and such stuff into SLE15 and according to Factory first rule also to tumbleweed and it looks like we like to integrate it as early as possible to get some feedback, which is good. On other hand, from user perspective it will look like that we reduce number of working features and do not provide anything new for them, so new storage would be regression for them. So I get idea that it would be great if we can add at least one new "free-cool-in" feature that make sense for SLE and also opensuse users. That is widely used and also easy to implement ( as we are already quite busy with development ) and after some googling I think that allowing to easy mount cloud storage in expert partitioner can be exactly that feature. For SLE we should support ceph ( so easy integration with SUSE storage ) and for opensuse it make sense to support at least one public cloud storage provider ( like google drive, AWS, Azure blob, rackspace, etc. which is the easiest to implement ). I think it is trending enough feature, it should not be hard to implement ( basically entry in fstab ), it has UI ( so easy to demonstrate ) and everybody knows it. So here is few my questions: - Do you think it makes sense? - Does it make sense to add support for it also in libstorage-ng? And if so, how hard it will be? - 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? In general my estimation how fast I can do this feature without libstorage-ng and with augeas for fstab is one week of work. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 30 May 2017 09:00:02 +0200
Josef Reidinger
Hi,
yesterday we are discussing a bit plans about merge storage-ng, new partitioner and such stuff into SLE15 and according to Factory first rule also to tumbleweed and it looks like we like to integrate it as early as possible to get some feedback, which is good.
On other hand, from user perspective it will look like that we reduce number of working features and do not provide anything new for them, so new storage would be regression for them. So I get idea that it would be great if we can add at least one new "free-cool-in" feature that make sense for SLE and also opensuse users. That is widely used and also easy to implement ( as we are already quite busy with development ) and after some googling I think that allowing to easy mount cloud storage in expert partitioner can be exactly that feature. For SLE we should support ceph ( so easy integration with SUSE storage ) and for opensuse it make sense to support at least one public cloud storage provider ( like google drive, AWS, Azure blob, rackspace, etc. which is the easiest to implement ). I think it is trending enough feature, it should not be hard to implement ( basically entry in fstab ), it has UI ( so easy to demonstrate ) and everybody knows it.
So here is few my questions:
- Do you think it makes sense?
- Does it make sense to add support for it also in libstorage-ng? And if so, how hard it will be?
- 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?
I forgot one question. If we do not adapt libstorage-ng. Will libstorage-ng survive if fstab contain lines like these? 10.10.10.10:6789:/ /mnt/ceph ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2 or gdfuse#default /mnt/gdrive fuse allow_other 0 0
In general my estimation how fast I can do this feature without libstorage-ng and with augeas for fstab is one week of work.
Josef
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 30.05.2017 09:00, Josef Reidinger wrote:
- Do you think it makes sense?
No. It is completely unrelated, nobody (in particular no product manager) requested this, and it opens a new level of complexity and a host of potential problems (that are very likely to materialize very quickly). 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.
- 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.
- 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).
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.
Kind regards
--
Stefan Hundhammer
On Tue, 30 May 2017 10:53:25 +0200
Stefan Hundhammer
On 30.05.2017 09:00, Josef Reidinger wrote:
- Do you think it makes sense?
No.
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
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, May 30, 2017 at 09:00:02AM +0200, Josef Reidinger wrote:
Hi,
yesterday we are discussing a bit plans about merge storage-ng, new partitioner and such stuff into SLE15 and according to Factory first rule also to tumbleweed and it looks like we like to integrate it as early as possible to get some feedback, which is good.
On other hand, from user perspective it will look like that we reduce number of working features and do not provide anything new for them, so new storage would be regression for them. So I get idea that it would be great if we can add at least one new "free-cool-in" feature that make sense for SLE and also opensuse users. That is widely used and also easy to implement ( as we are already quite busy with development ) and after some googling I think that allowing to easy mount cloud storage in expert partitioner can be exactly that feature. For SLE we should support ceph ( so easy integration with SUSE storage ) and for opensuse it make sense to support at least one public cloud storage provider ( like google drive, AWS, Azure blob, rackspace, etc. which is the easiest to implement ). I think it is trending enough feature, it should not be hard to implement ( basically entry in fstab ), it has UI ( so easy to demonstrate ) and everybody knows it.
Why not provide features actually requested? E.g.
- root filesystem encryption without LVM
This almost works, just grub fails to install.
- bcache support
Probing is already implemented.
ciao Arvin
--
Arvin Schnell,
On Tue, 30 May 2017 12:38:38 +0200
Arvin Schnell
On Tue, May 30, 2017 at 09:00:02AM +0200, Josef Reidinger wrote:
Hi,
yesterday we are discussing a bit plans about merge storage-ng, new partitioner and such stuff into SLE15 and according to Factory first rule also to tumbleweed and it looks like we like to integrate it as early as possible to get some feedback, which is good.
On other hand, from user perspective it will look like that we reduce number of working features and do not provide anything new for them, so new storage would be regression for them. So I get idea that it would be great if we can add at least one new "free-cool-in" feature that make sense for SLE and also opensuse users. That is widely used and also easy to implement ( as we are already quite busy with development ) and after some googling I think that allowing to easy mount cloud storage in expert partitioner can be exactly that feature. For SLE we should support ceph ( so easy integration with SUSE storage ) and for opensuse it make sense to support at least one public cloud storage provider ( like google drive, AWS, Azure blob, rackspace, etc. which is the easiest to implement ). I think it is trending enough feature, it should not be hard to implement ( basically entry in fstab ), it has UI ( so easy to demonstrate ) and everybody knows it.
Why not provide features actually requested? E.g.
- root filesystem encryption without LVM
This almost works, just grub fails to install.
- bcache support
Probing is already implemented.
Very good points. Well, reasons why I get the idea is that rest of stack is already there and basically it is one entry in /etc/fstab ( no probing, kernel driver for cephfs is already in ), so it can be done without libstorage ( to not disrupt work there ). There are not much dependencies on rest of storage ( probably just collision of mount points with snapshots ), so quite isolated stuff, that do not need a lot of work and on other hand can be nice selling point as it is widely known technology, have UI and can also promote SUSE storage, so we can get some plus points from product managers. But as I write it was just idea, something that can be discussed and as I see mostly resistance and not much interested in it, I do not plan to investigate it any further. But thanks for constructive feedback. BTW bcache also sound interesting, we just probably need to involve designers team when adding it to expert partitioner to show it reasonable for multiple spin and ssd disks. Josef
ciao Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05/30/2017 12:38 PM, Arvin Schnell wrote:
On Tue, May 30, 2017 at 09:00:02AM +0200, Josef Reidinger wrote:
Hi,
yesterday we are discussing a bit plans about merge storage-ng, new partitioner and such stuff into SLE15 and according to Factory first rule also to tumbleweed and it looks like we like to integrate it as early as possible to get some feedback, which is good.
On other hand, from user perspective it will look like that we reduce number of working features and do not provide anything new for them, so new storage would be regression for them. So I get idea that it would be great if we can add at least one new "free-cool-in" feature that make sense for SLE and also opensuse users. That is widely used and also easy to implement ( as we are already quite busy with development ) and after some googling I think that allowing to easy mount cloud storage in expert partitioner can be exactly that feature. For SLE we should support ceph ( so easy integration with SUSE storage ) and for opensuse it make sense to support at least one public cloud storage provider ( like google drive, AWS, Azure blob, rackspace, etc. which is the easiest to implement ). I think it is trending enough feature, it should not be hard to implement ( basically entry in fstab ), it has UI ( so easy to demonstrate ) and everybody knows it.
Why not provide features actually requested? E.g.
- root filesystem encryption without LVM
This almost works, just grub fails to install> - bcache support
Probing is already implemented.
Yes, the current guided setup is way more powerful than the old proposal settings. As Arvin said, root encryption has been requested many times and now it will be possible. A pretty good selling point. The so-called level 2 of the AutoYaST is also a completely new feature that could be very useful for many customers. There are also another improvements related with the proposal that we will be able to implement with very little work, like integrating the proposal with the expert partitioner, so you manually create/select your root partition and then let the proposal calculate the rest while respecting your hand-made decisions. Let's call it the hybrid mode ;-) Or maybe an advanced checkbox in the guided setup so you can "pretend" you are using UEFI even when is not true in the very same moment you are running the installation (yes, we also have reports from people that install in legacy mode to then switch to UEFI after installation). So there are some features we can trade in exchange for the missing ones (whatever they are). :-) Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 30.05.2017 14:22, Ancor Gonzalez Sosa wrote:
So there are some features we can trade in exchange for the missing ones (whatever they are). :-)
But first at all we should deliver a good replacement for the storage stack.
In the ideal case, it would be a drop-in replacement; but most likely we
might be missing some (probably more exotic) features the old one had.
But being reasonably feature-complete, and, more importantly, robust, should
be our main goal. We should focus on that and not introduce all kinds of new
things that nobody asked for. We don't exactly feel bored with the amount of
things that are still left to do.
Kind regards
--
Stefan Hundhammer
On Tue, 30 May 2017 15:51:32 +0200
Stefan Hundhammer
On 30.05.2017 14:22, Ancor Gonzalez Sosa wrote:
So there are some features we can trade in exchange for the missing ones (whatever they are). :-)
But first at all we should deliver a good replacement for the storage stack. In the ideal case, it would be a drop-in replacement; but most likely we might be missing some (probably more exotic) features the old one had. But being reasonably feature-complete, and, more importantly, robust, should be our main goal. We should focus on that and not introduce all kinds of new things that nobody asked for. We don't exactly feel bored with the amount of things that are still left to do.
Feature complete and robust is important parts, but not for user. He is interested if features that he needs or already uses is there ( no matter how exotic it is ). And also if previous storage stack worked for them, then robust is for him too abstract term. Plus do not forget that users is usually a bit conservative, so they love old bugs that they already know how to workaround them. That is reason why many users do not update/upgrade so often. In this situation consider starting mood like zero. Every feature that user use and is missing send mood to negative numbers. Every new bug also send adds negative numbers. So only chance to balance it, is something new that sends customer mood to positive numbers. And feature complete or robust is not really the ones that can do it. It is something that find user useful like ones that mention Ancor, bcache for nicer experience with combination of ssd and spin disk Arvin mentions, any improved usability ( so user who knows old stack can say, wow, it is really better ) or something similar. And we should really start more intensively promote this new features, so it is more publicly aware what good it will provide for them and it can make easier for early adopters to find it and try it. Josef
Kind regards
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 30.05.2017 16:22, Josef Reidinger wrote:
Feature complete and robust is important parts, but not for user.
I completely disagree. For most users this is the ONLY important part.
I for example tend to think "oh no, what have they introduced now" when I get
bombarded with ever-changing stuff. Basically, that's why it took me a long
time to make the transition from KDE3 to KDE4, and why I abandoned KDE
altogether when they dumped KDE 5 Plasma upon me.
Users value stability more than anything else. Don't forget that all those
supposedly little changes add up, and every time a part of the know-how about
those things get wasted because they change all the time.
Only a handful of geeks welcome change for the sake of changing. Any you are
probably familiar with the old statement that 80% of all users never get
beyond using 20% of all the features (which might be slightly different 20%
from one user to the next, however). Adding even more stuff is just
additional stuff to get lost in.
Kind regards
--
Stefan Hundhammer
On Tue, 30 May 2017 17:02:41 +0200
Stefan Hundhammer
On 30.05.2017 16:22, Josef Reidinger wrote:
Feature complete and robust is important parts, but not for user.
I completely disagree. For most users this is the ONLY important part.
Ok, let me a bit rephrase second part of my sentence: " but not good reason for user to get/use new major version."
I for example tend to think "oh no, what have they introduced now" when I get bombarded with ever-changing stuff. Basically, that's why it took me a long time to make the transition from KDE3 to KDE4, and why I abandoned KDE altogether when they dumped KDE 5 Plasma upon me.
Users value stability more than anything else. Don't forget that all those supposedly little changes add up, and every time a part of the know-how about those things get wasted because they change all the time.
Sorry, I get totally lost. Here you trying to convince us to use old libstorage? For me it looks like you trying to say that doing complete redesign satisfy users that want stability? Or I miss something? If I use your example you say that you will switch from KDE3 to KDE4 because KDE4 have same stability like KDE3 and it is somehow more robust then KDE3?
Only a handful of geeks welcome change for the sake of changing. Any you are probably familiar with the old statement that 80% of all users never get beyond using 20% of all the features (which might be slightly different 20% from one user to the next, however). Adding even more stuff is just additional stuff to get lost in.
Here against it looks like you are trying to convince anyone just to not use libstorage-ng. If it is same, they will upgrade just for "sake of changing". What I am trying to say, is to convince exactly this type of users that by nature do not want to upgrade with something that is not just change for the change, but that really provide them some value like already mentioned nicer integration with modern hardware ( ssd and spin disk combination ), better guided setup, better UX, etc.
Kind regards
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Ancor Gonzalez Sosa
-
Arvin Schnell
-
Josef Reidinger
-
Stefan Hundhammer