@Didi
All right, I take your point.
So when I've got everything working I'll do a write up and submit it as
a "bug", as you suggested - but you *are* going to rue the day you
suggested it, because I'm now going to be "darkening your email"
(darkening your door) like you won't believe, requesting help and
running ideas past you - so you *have* been warned! <WEG>
Cheers
Dulux-Oz
(aka Matthew J Black)
On 13/09/2022 20:26, Yedidyah Bar David wrote:
Hi Matthew,
On Tue, Sep 13, 2022 at 12:26 PM Matthew J Black
<matthew(a)peregrineit.net> wrote:
> Well, if I can put my $0.02 worth in...
>
> What I've been trying to do is set up an oVirt cluster (v4.5.X) to use a Ceph
(Quincey) cluster as the back-end via iSCSI. One thing I found was that up-to-date,
relevant information from both the Ceph-side *and* the oVirt side on how to do this was...
hard to find, not explained very well, and often out of date (like this relevant Blog
post, if it is now out of date, and based on the posts of this thread that is what it
appears to be) - this also applies to pre-installing / not pre-installing OpenVSwitch (see
my other thread from today).
I agree.
And, let me take back my previous reply, about updating the blog post.
A blog post is, by definition, out-of-date, very soon after it's
published. It's inside a blog, right? A kind of diary. You don't
update your paper diary after you wrote some entry in it, right?
Project/product Documentation, OTOH, is supposed/expected to be kept
up-to-date over time.
If a doc/guide is out-of-date, you'd naturally consider this a bug.
Not so for a blog post.
In oVirt, it's basically the same.
Blog posts, here, are mainly POCs - demonstrations that something is doable.
The fact that you do not find oVirt-on-Ceph in the main documentation
is not a mistake - it's simply not considered (yet? See below)
stable/supportable enough to enter that space.
> So I've been experimenting in a test environment (using Rocky Linux - initially
v9 but now v8.6), tearing down and re-building (physical) boxes, and making notes for
myself as I go. And, as may be implied from this and my other thread from today, the types
of problems and issues I'm encountering are relatively trivial and easily answered
**once I can get on to someone who knows** (those issues that aren't
"self-inflicted", of course).
>
> And for what it is worth, I am extremely grateful for the help I've received
today - thank you all!
>
> So if people are talking about doco, etc, then this might be worth considering as
well (ie, how to go about doing what I've been doing).
>
> I'm reluctant to write this up myself for a number of reasons, including (but not
limited to) the issue of maintainability, the fact that I'm not experienced enough
with oVirt to hold myself out as an "expert", and because of an incident in the
past where I ended up taking a lot of flack that wasn't really my fault (the old
"once bitten, twice shy").
I understand very well.
The fact is, that no-one else did, right? If no-one does, it will never happen.
What you can do:
- Create a ticket/bug/issue for tracking this. Despite what perhaps
some people might think, this isn't useless, even if you are not going
to handle it yourself, nor know about anyone that is.
- Include there what you already know and had to do. This most
definitely does not put you in any position of authority - I think
no-one will expect you to keep a comment in an issue up-to-date. It's
less authoritative than a blog post, right? Just a comment. But it's
extremely helpful, for both people that want to do what you want to
do, those that want to actually handle the issue (by writing docs),
and those wanting to review the eventual doc patches.
- It also makes it much easier to find, link, etc., so will likely get
more traction than a thread like current.
I'd like to use this opportunity to add some more thoughts,
at-most-tangentially related to the current thread.
Speaking only for myself, not for Red Hat.
Red Hat already decided that the future lies in containers, and people
that still need VMs for their legacy stuff (as considered by Red Hat)
should handle that inside OpenShift using CNV. See also e.g. [1] for
what might eventually, when it matures enough, be a more-or-less
replacement for oVirt's functionality, although definitely not for
oVirt's behavior. This means, in particular, that if Red Hat decides
to support so-called Hyper Converged Infrastructure (HCI) setups (or
it might already have done, no idea), it will be based on
OpenShift/CNV + Ceph, not RHV. AFAIU, IMHO, etc. But this does not
mean that oVirt-on-Ceph HCI is impossible - it means that for this to
happen, someone else should do most of the work. We (as in, Red Hat
employees working on oVirt) will definitely be able to help if/where
needed, but can't be expected to do the bulk of the work.
I personally still think that oVirt is most probably the best
small-/medium-scale Open Source clustered virtualization system. But
to keep it thriving, more people should help. Including those that
think that they are not experienced enough :-)
> "Anyway, it's just a thought - you all have a good day." - Beau Of The
Fifth Column
Thanks for your message. I think it was helpful.
[1]
https://okd-virtualization.github.io/
Best regards,
--
This email has been checked for viruses by Avast antivirus software.