I just want to state that we are in the same situation like Konstantin,
running a big cluster with Cinder storage (564 disks). This has worked
perfectly for us in the past. I didn't upgrade to 4.4 yet, but reading
now about Cinder deprecation makes me very sad. Why did you address bugs
like
and then
suddenly stop working on this? I know that Open Stack block storage
(Cinder) always had Technology Preview status in oVirt so complaining
about breaking "production" clusters might be futile from a "legal"
point of view, but I want to confirm once again that is has been
successfully used in large scale. Are there ways to lobby for keeping
Cinder support in oVirt 4.4? Would it be possible to sponsor this feature?
I know about and already tested cinderlib and I'm not unwilling to use
it (like Konstantin). My objections at the present time are the same as
Konstantin's and I'm at least expecting proper documentation (which is
on it's way) and ideally a migration guide.
Anyway, thanks a lot for great work so far. I hope I will remain a happy
user.
Matthias
Am 22.12.20 um 17:31 schrieb Konstantin Shalygin:
Sandro, FYI we are not against cinderlib integration, more than we
are
upgrade 4.3 to 4.4 due movement to cinderlib.
But (!) current Managed Storage Block realization support only krbd
(kernel RBD) driver - it's also not a option, because kernel client is
always lagging behind librbd, and every update\bugfix we should *reboot
whole host* instead simple migration of all VMs and then migrate it
back. Also with krbd host will be use kernel page cache, and will not be
unmounted if VM will crash (qemu with librbd is one userland process).
So for me current situation look like this:
1. We update deprecated OpenStack code? Why, Its for delete?..
Nevermind, just update this code...
2. Hmm... auth tests doesn't work, to pass test just disable any
OpenStack project_id related things... and... Done...
3. I don't care how current cinder + qemu code works, just write new one
for linux kernel, it's optimal to use userland apps, just add wrappers
(no, it's not);
4. Current Cinder integration require zero configuration on oVirt hosts.
It's lazy, why oVirt administrator do nothing? just write manual how-to
install packages - oVirt administrators love anything except "reinstall"
from engine (no, it's not);
5. We broke old code. New features is "Cinderlib is a Technology Preview
feature only. Technology Preview features are not supported with Red Hat
production service level agreements (SLAs), might not be functionally
complete, and Red Hat does not recommend to use them for production".
6. Oh, we broke old code. Let's deprecate them and close PRODUCTION
issues (we didn't see anything).
And again, we are not hate new cinderlib integration. We just want that
new technology don't break all PRODUCTION clustes. Almost two years ago
I write on this issue
https://bugzilla.redhat.com/show_bug.cgi?id=1539837#c6 about "before
deprecate, let's help to migrate". For now I see that oVirt totally will
disable QEMU RBD support and want to use kernel RBD module + python
os-brick + userland mappers + shell wrappers.
Thanks, I hope I am writing this for a reason and it will help build
bridges between the community and the developers. We have been with
oVirt for almost 10 years and now it is a crossroads towards a different
virtualization manager.
k
So I see only regressions for now, hope we'll found some code owner who
can catch this oVirt 4.4 only bugs.
On 22.12.2020 12:01, Sandro Bonazzola wrote:
>
>
> Il giorno lun 21 dic 2020 alle ore 18:33 Konstantin Shalygin
> <k0ste(a)k0ste.ru <mailto:k0ste@k0ste.ru>> ha scritto:
>
> Sandro, after my mention my two bugs was closed as deprecated
> feature of "old Cinder integration". But actually no one oVirt 4.4
> doc mentioned about deprecations/cautions/warnings.
>
>
> Indeed, documentation is not aligned with +Eyal Shenitzky
> <mailto:eshenitz@redhat.com> 's comments on the bugs.
> A proper deprecation bug should have been opened and documentation
> should have been properly updated to clearly mark the feature as
> deprecated.
> Also the new implementation of cinderlib is not properly documented in
> oVirt Install Guide, I'll try to get it updated today.
>
> How do you think, as manager of project, it's okay to just broke
> working code due loose tests and then deprecate it just by wave a
> hand?🤷♂️
>
>
> I'll let storage team lead to reply to this specific question. I can
> only agree this has not been properly handled.
>
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ULTVTH5CLQP...
--
Matthias Leopold
IT Systems & Communications
Medizinische Universität Wien
Spitalgasse 23 / BT 88 /Ebene 00
A-1090 Wien
Tel: +43 1 40160-21241
Fax: +43 1 40160-921200