[ovirt-users] Local storage & shared in same cluster
Sebastian Greco
sgreco at essiprojects.com
Mon Oct 31 08:55:38 UTC 2016
Thx for the advice Barak!
I was looking for a roadmap to follow, like the "trello" one used for the
openshift project https://trello.com/b/nlLwlKoz/atomicopenshift-roadmap but
I was not able to find one. I love to hear things like the "SPM was planned
to be removed" as it gives me a better understanding of the direction the
project has. Any good resource to follow this and other things to come?
Thanks again for the help!
Sebastián Greco
IT Consultant
Cloud Computing - Red Hat - VMware - Zimbra
www.essiprojects.com
*www.essiprojects.co.uk <http://www.essiprojects.co.uk>*
Pl. Prim, 4-5 Pral 2a · T:+34 977 221 182 · M: +34 619 985 161 F: +34 977
230 170 · 43001 Tarragona Spain
120 Pall Mall · T:+44 207 101 0778 · F: +44 843 538 3112 · SW1Y 5ED *London*
UK
On Mon, Oct 31, 2016 at 9:36 AM, Barak Korren <bkorren at redhat.com> wrote:
> On 31 October 2016 at 09:28, Sebastian Greco <sgreco at essiprojects.com>
> wrote:
> >
> > On Sun, Oct 30, 2016 at 10:42 AM, Barak Korren <bkorren at redhat.com>
> wrote:
> >>
> >> VMs are not
> >> very interesting as a use case for RHV customers. When y
> >
> >
> > Thx for the answsers. I see that it's the second time that someone from
> RH
> > points out that customers are not interested in this feature. While I
> can't
> > argue with that, what I do can say is that "non-customers" (most of
> > companies out there using vsphere or hyper-v) feel dissapointed towards
> this
> > solution for things like this one (for this case, 2 of my customers are
> > missing this, we are deploying RHV to one of them this week).
>
> Please don't take my statement as being official in any way. Despite
> writing from a @redhat.com address, I'm writing my personal thoughts.
>
> I have stated that I've no data to back what I've said. This is all
> just a guess based on what I know of oVirt/RHV development processes.
> I'm most certainly not someone who makes decisions about any of theses
> things.
>
> > I don't see how this lack of flexibility is something good, and so far
> from
> > my experience with customers which I'm trying to convince to start using
> > RHV, when they finally do agree to start with one or two servers
> (following
> > the RHCI roadmap evolution to the hybrid cloud), they see things like
> this
> > and dismiss this solution sooner than later.
>
> Please do not take my statement as indicating of any conscious design
> decision. I was just trying to gauge where oVirt/RHV development might
> head given that RedHat typically puts its resources where its current
> and potential customers tell it do. Case to point:
>
> 1. Ephemeral local state VMs are supported with the scrathcpad hook because
> its been shown to be useful for Build/Test/CI systems.
> 2. Singular host with local storage and non-migrating VMs is supported for
> cases where one simply wants resource convergence.
>
> The 3rd case we're discussing here where the same host can run both
> local persistent VMs and migrating ones had not been supported so far.
> I'm __guessing__ that this is because demand seen so far did not
> outweigh
> the technical difficulty to achieve this (Just to indicate the difficulty,
> the SPM was planned to be removed in 4.0, it did not make it).
>
> > Anyways, question has been answer "yes, is technically possible but by
> > design it is not going to happen", and I wouldn't like to convert this
> > thread or abuse your kindness deviating the subject :)
>
> This is definitely not the bottom line, I way trying to guess and
> explain why this __did_not__ happen __so_far__. I never meant to say
> it will not.
>
> If you are a RHV reseller or integrator, your input is very valuable
> for RedHat. While this list is one way to reach some RedHat
> developers, you should certainly make an effort to use other channels
> available to you to make your input known.
>
>
> --
> Barak Korren
> bkorren at redhat.com
> RHEV-CI Team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20161031/d1128d1f/attachment-0001.html>
More information about the Users
mailing list