+++ 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