Bug 1523608 - [RFE] - HE should support Gluster replica 1 or 3.
Summary: [RFE] - HE should support Gluster replica 1 or 3.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: rhhi
Version: rhhi-1.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: RHHI-V 1.5
Assignee: Sahina Bose
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 1472757 1479714 1493085 1583462 1583464
Blocks: 1520833 1548985
TreeView+ depends on / blocked
 
Reported: 2017-12-08 11:40 UTC by Sahina Bose
Modified: 2019-04-28 09:46 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Deployment of RHHI for Virtualization on a single node is now supported.
Clone Of: 1479714
Environment:
Last Closed: 2018-11-08 05:37:25 UTC
Target Upstream Version:


Attachments (Terms of Use)
dalton-gdeploy.conf (2.53 KB, text/plain)
2018-02-09 12:29 UTC, Sahina Bose
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:3523 None None None 2018-11-08 05:38:50 UTC

Description Sahina Bose 2017-12-08 11:40:19 UTC
+++ This bug was initially created as a clone of Bug #1479714 +++

Description of problem:

Currently HE setup is allowed on a gluster volume with replica count =3. To support a single node hyperconverged setup, we need to be able to configure the engine on a single brick gluster volume as well.
The replica count check could be configured as a supported replica count check (similar to how vdsm handles it)

Version-Release number of selected component (if applicable):
4.1.4

How reproducible:
Always

Steps to Reproduce:
1. Create a single brick gluster volume and use that as the volume for HE setup

Actual results:
Error is thrown

Expected results:
Should be allowed

Additional info:

--- Additional comment from Sahina Bose on 2017-08-09 05:19:37 EDT ---

Yaniv, should this be targeted for 4.1.x version?

--- Additional comment from Yaniv Lavi on 2017-08-09 09:57:24 EDT ---

(In reply to Sahina Bose from comment #1)
> Yaniv, should this be targeted for 4.1.x version?

This is only important from RHHI ROBO single node all in one. For now, I'll this to 4.2 and let me know when you want to support this 1.x stream.

--- Additional comment from Sahina Bose on 2017-08-16 08:26:07 EDT ---

4.2 target is fine - I misunderstood the requirement

--- Additional comment from Sahina Bose on 2017-09-22 01:08:13 EDT ---

Retargeting again, with requirement for single node RHHI heating up

--- Additional comment from Sandro Bonazzola on 2017-09-22 07:36:54 EDT ---

(In reply to Sahina Bose from comment #0)
> Description of problem:
> 
> Currently HE setup is allowed on a gluster volume with replica count =3. To
> support a single node hyperconverged setup, we need to be able to configure
> the engine on a single brick gluster volume as well.

Please note that a hosted engine deployment with a single host doesn't work.
You won't never be able to put the host in maintenance since you won't be able to migrate hosted engine VM to another host.

So, I may be fine with having an external glusterfs with replica 1 as external storage (even if I think that NFS or iSCSI will perfom better) but I think that an hyperconverged hosted engine with a single host doesn't make sense.

Martin, please correct me if I'm wrong here.

--- Additional comment from Sahina Bose on 2017-09-23 00:01:44 EDT ---

(In reply to Sandro Bonazzola from comment #5)
> (In reply to Sahina Bose from comment #0)
> > Description of problem:
> > 
> > Currently HE setup is allowed on a gluster volume with replica count =3. To
> > support a single node hyperconverged setup, we need to be able to configure
> > the engine on a single brick gluster volume as well.
> 
> Please note that a hosted engine deployment with a single host doesn't work.
> You won't never be able to put the host in maintenance since you won't be
> able to migrate hosted engine VM to another host.
> 
> So, I may be fine with having an external glusterfs with replica 1 as
> external storage (even if I think that NFS or iSCSI will perfom better) but
> I think that an hyperconverged hosted engine with a single host doesn't make
> sense.
> 
> Martin, please correct me if I'm wrong here.

With single node deployment, there's no expectation that the VMs (including engine VM) will always be available. Is it possible to do host upgrade from command line in this case...that is, 
i) move hosted-engine to global maintenance
ii) upgrade engine VM
iii) shutdown VMs
iv) upgrade hosts

Or a similar procedure?

--- Additional comment from Martin Sivák on 2017-09-25 04:54:07 EDT ---

Hosted engine itself is not the issue, you can put it into maintenance (global / local) from command line.

But the infra host upgrade flow might be an issue. It won't be able to do anything unless the host is in maintenance and you can't put the host to maintenance with hosted engine on it. And well.. you can't trigger maintenance with no engine running either.

--- Additional comment from Oved Ourfali on 2017-09-25 05:02:58 EDT ---

Will allowing to put a host to maintenance in the condition that there is only one VM running on it, which is the hosted engine, help?
Does it make sense to do that?

Putting also Michal in the loop.

--- Additional comment from Michal Skrivanek on 2017-09-25 05:12:24 EDT ---

Possible, but it's not going to be nice though. You'd likely need exceptions in all other flows involving maintenance state since the host is not really in maintenance until the HE VM is gone.
Upgrades would be easier to handle externally, e.g. by the cluster upgrade ansible stuff

--- Additional comment from Oved Ourfali on 2017-09-25 05:16:18 EDT ---

(In reply to Michal Skrivanek from comment #9)
> Possible, but it's not going to be nice though. You'd likely need exceptions
> in all other flows involving maintenance state since the host is not really
> in maintenance until the HE VM is gone.
> Upgrades would be easier to handle externally, e.g. by the cluster upgrade
> ansible stuff

Which moves the hosts to maintenance before doing anything else.... :-/
The ansible logic goes through the engine (it uses our SDK) rather than doing things behind the scenes.

--- Additional comment from Michal Skrivanek on 2017-09-25 10:32:09 EDT ---

(In reply to Oved Ourfali from comment #10)

> Which moves the hosts to maintenance before doing anything else.... :-/
> The ansible logic goes through the engine (it uses our SDK) rather than
> doing things behind the scenes.

it already implements additional behavior of shutting down VMs when they can't be migrated. In general it's more easy to extend it than engine core

--- Additional comment from Oved Ourfali on 2017-09-25 10:38:56 EDT ---

But it can't shut down the hosted engine.
You will either upgrade without putting the host to maintenance, or you put it on maintenance although the hosted engine vm is running. Both require engine changes. Unless you issue the upgrade from outside of the engine api.

Anyway, I suggest scheduling a meeting to discuss that.

--- Additional comment from Sahina Bose on 2017-10-25 06:48:35 EDT ---

Moving to 4.2 due to open questions and discussions needed

--- Additional comment from Yaniv Lavi on 2017-11-01 06:41:25 EDT ---

If you shutdown VMs and engine you can update via CLI and then bring the node back up,
is there any issue with such a flow?

--- Additional comment from Oved Ourfali on 2017-11-01 07:05:13 EDT ---

If I understand you correctly, yes.
But not sure what you mean by "CLI".

Worth elaborating to make sure your proposal is clear.

--- Additional comment from Yaniv Lavi on 2017-11-01 07:07:58 EDT ---

(In reply to Oved Ourfali from comment #15)
> If I understand you correctly, yes.
> But not sure what you mean by "CLI".
> 
> Worth elaborating to make sure your proposal is clear.

SSH to the host and running 'yum update'.

--- Additional comment from Oved Ourfali on 2017-11-01 07:14:15 EDT ---

(In reply to Yaniv Lavi from comment #16)
> (In reply to Oved Ourfali from comment #15)
> > If I understand you correctly, yes.
> > But not sure what you mean by "CLI".
> > 
> > Worth elaborating to make sure your proposal is clear.
> 
> SSH to the host and running 'yum update'.

As far as I remember moving to maintenance doesn't stop any services, so it should work. However, I know that we're adding some logic to it with regards to hosted engine.

Also note that a reboot is required for NGN.

Martin - anything I'm missing?

--- Additional comment from Martin Perina on 2017-11-01 08:53:26 EDT ---

For single-host engine you cannot use host upgrade manager, because it requires host to be in maintenance, which means all VMs down. The same applies for ovirt-cluster-upgrade role, it requires engine to be working, which is impossible in this use case.

So the only way how to upgrade single-host engine is following:

1. Upgrade engine to relevant version
2. Shutdown HE VM
3. Connect to the host using SSH
4. Perform yum update and reboot host as needed
5. Start HE VM

Also when moving host to maintenance for upgrades, it's recommended to stop gluster services (and host upgrade manager invokes those stop).

--- Additional comment from Yaniv Lavi on 2017-11-01 10:11:48 EDT ---

(In reply to Martin Perina from comment #18)
> For single-host engine you cannot use host upgrade manager, because it
> requires host to be in maintenance, which means all VMs down. The same
> applies for ovirt-cluster-upgrade role, it requires engine to be working,
> which is impossible in this use case.
> 
> So the only way how to upgrade single-host engine is following:
> 
> 1. Upgrade engine to relevant version
> 2. Shutdown HE VM
> 3. Connect to the host using SSH
> 4. Perform yum update and reboot host as needed
> 5. Start HE VM
> 
> Also when moving host to maintenance for upgrades, it's recommended to stop
> gluster services (and host upgrade manager invokes those stop).

This sound reasonable for a single node use case.
We can also think of adding a script to help automate this and return the VMs to the same state post-upgrade. Sahina, based on this when do you plan to address this?

--- Additional comment from Sahina Bose on 2017-11-06 02:09:31 EST ---

(In reply to Yaniv Lavi from comment #19)
> (In reply to Martin Perina from comment #18)
> > For single-host engine you cannot use host upgrade manager, because it
> > requires host to be in maintenance, which means all VMs down. The same
> > applies for ovirt-cluster-upgrade role, it requires engine to be working,
> > which is impossible in this use case.
> > 
> > So the only way how to upgrade single-host engine is following:
> > 
> > 1. Upgrade engine to relevant version
> > 2. Shutdown HE VM
> > 3. Connect to the host using SSH
> > 4. Perform yum update and reboot host as needed
> > 5. Start HE VM
> > 
> > Also when moving host to maintenance for upgrades, it's recommended to stop
> > gluster services (and host upgrade manager invokes those stop).
> 
> This sound reasonable for a single node use case.
> We can also think of adding a script to help automate this and return the
> VMs to the same state post-upgrade. Sahina, based on this when do you plan
> to address this?

Yaniv, are you asking about "stopping gluster services on upgrade" - If so, this is taken care of.
If you're talking of this bug - i.e relaxing the restriction on HE engine setup - it's targeted to 4.2

--- Additional comment from Yaniv Lavi on 2017-11-06 06:11:15 EST ---

(In reply to Sahina Bose from comment #20)
>
> Yaniv, are you asking about "stopping gluster services on upgrade" - If so,
> this is taken care of.
> If you're talking of this bug - i.e relaxing the restriction on HE engine
> setup - it's targeted to 4.2

I am referring to the concerns raised on upgrade flow and provided the suggested flow for this deployment type.
This is to make sure we can address it for 4.2.

--- Additional comment from Sahina Bose on 2017-11-09 09:31:16 EST ---

(In reply to Yaniv Lavi from comment #21)
> (In reply to Sahina Bose from comment #20)
> >
> > Yaniv, are you asking about "stopping gluster services on upgrade" - If so,
> > this is taken care of.
> > If you're talking of this bug - i.e relaxing the restriction on HE engine
> > setup - it's targeted to 4.2
> 
> I am referring to the concerns raised on upgrade flow and provided the
> suggested flow for this deployment type.
> This is to make sure we can address it for 4.2.

Yes - the manual process would work, but is that acceptable for 4.2?

--- Additional comment from Yaniv Lavi on 2017-11-09 09:50:36 EST ---

(In reply to Sahina Bose from comment #22)
> (In reply to Yaniv Lavi from comment #21)
> > (In reply to Sahina Bose from comment #20)
> > >
> > > Yaniv, are you asking about "stopping gluster services on upgrade" - If so,
> > > this is taken care of.
> > > If you're talking of this bug - i.e relaxing the restriction on HE engine
> > > setup - it's targeted to 4.2
> > 
> > I am referring to the concerns raised on upgrade flow and provided the
> > suggested flow for this deployment type.
> > This is to make sure we can address it for 4.2.
> 
> Yes - the manual process would work, but is that acceptable for 4.2?

Yes, I don't see a way to avoid it, this is the right way. We don't support in-service updates and we don't plan to,
I would try to script this and return the system at the end of the same state (engine up and VMs that were up will be booted). Should not be very hard to do.

--- Additional comment from Red Hat Bugzilla Rules Engine on 2017-11-22 05:01:03 EST ---

The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

--- Additional comment from Sahina Bose on 2017-11-24 05:02:24 EST ---

Sean, do we need to target single node HC for RHHI 2.0

--- Additional comment from Sahina Bose on 2017-12-08 06:36:19 EST ---

Retargeting based on discussion with Sean and Yaniv

Comment 3 Sahina Bose 2018-02-09 12:29:20 UTC
Created attachment 1393712 [details]
dalton-gdeploy.conf

Attached a sample file to setup the gluster volume

Comment 4 SATHEESARAN 2018-04-04 11:50:49 UTC
Tested with RHV 4.2.2-6. Its able to install HE with distribute volume type or on replica 3 volume

Comment 7 errata-xmlrpc 2018-11-08 05:37:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3523


Note You need to log in before you can comment on or make changes to this bug.