[DRBD-user] Linstore: Renaming a resource possible?

Yanni M. gianni.milo22 at gmail.com
Thu May 20 18:45:25 CEST 2021


I'm not a developer, so I cannot comment on how difficult it is to
acomplish this. I'm sure that there must be good reasons behind it, so I
leave that to the experts. 😊

What I would personally would like to have is an option to "rename" or
"update" a resource while _not_ "InUse" (i.e while the resource is down
cluster wide). This "should" impose less risk in my opinion, as there may
be less chances for something to go terribly wrong.
As the OP already mentioned, I would like to avoid having to clone the
resource for something as simple (in my eyes) as renaming vm-101-disk-1 to
vm-101-disk-2 while preserving the original resource data/metadata.





On Thu, 20 May 2021 at 16:39, Dr. Volker Jaenisch <volker.jaenisch at inqbus.de>
wrote:

> Dear Andreas!
>
> @Volker the community will be very happy if you provide a consistent and
> reliable patch.
>
> Thank you for your confidence in me.
>
> But, sorry, I program in Python, Cython and VUE.JS, and not in Java. I
> fixed some things in drbdmanage (which was the Python predecessor of
> linstor) and the proxmox interface for our internal purpose but Java is
> definitively not my domain.
>
> On the other hand according to their GH post the problem is not the code
> only, but the DB structure and the overall design. Such things cannot be
> fixed by a simple patch from a user. Such bad weeds hat to be rooted out,
> deeply.
>
> I have never said that it will be easy to fix, I just stated, that it
> seems to be a mess if it is not easy to fix. I still cannot even grasp the
> reality that vm-X-disk-Y is in any way the primary identifier in linstor. I
> still hope that the GH statement was incorrect or misleading.
>
> Before any patch could be thought of the linstor developers should give
> the users at least a workaround how to fix this by hand. In the 10 year
> doing clusters with DRBD it is the first time that I have the need to
> rename a resource. It is truly a corner case but an IMHO important one.
> The positive resonance here shows that I am not the only one with this
> particular problem.
>
> Proxmox for instance also states that (swapping VM devices) this is a
> corner case, and that they do not have a Button for it. But in the same
> instant they point to a documented workaround where the problem can be
> solved by editing some config files. This is IMHO really enough to deal
> with a corner case.
>
> Even If I had to shut down my VM to fix the resource name it would be a
> doable workaround. If you take into account the time to do the alternative
> which is copying a terabyte of email storage from one resource to an other
> simply because you cannot change the resource name, even shutting down a VM
> to rename a resource by hand gets some appeal.
>
>
> I am quite disappointed by linbit in the last years. DRBD was and still is
> a top notch performance, a really good and reliable product, which I would
> miss tremendously if it would vanish. But after the dumping of
>
> drbdmanage, the DRBD-Proxmox struggle and the introduction of linstore,
> working with DRBD9 has become a real pain.
>
> I never thought I would, but I think I will have my eyes open in the
> future to look for alternatives.
>
>
> Cheers,
>
> Volker
>
> --
> =========================================================
>    inqbus Scientific Computing    Dr.  Volker Jaenisch
>    Hungerbichlweg 3 <https://www.google.com/maps/search/Hungerbichlweg+3?entry=gmail&source=g>               +49 (8860) 9222 7 92
>    86977 Burggen                     https://inqbus.de
> =========================================================
>
> _______________________________________________
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user at lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20210520/4f073f0a/attachment.htm>


More information about the drbd-user mailing list