Resending - inadvertently dropped CCs.
On Wed, Dec 3, 2014 at 7:50 AM, Bob Doolittle <bob(a)doolittle.us.com> wrote:
Another issue with that page is that it assumes a remote database. I
am
not sure what percentage of cases have remote databases but clearly many
(most?) do not, since that's not default behavior. So that page definitely
needs attention. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1099995
https://bugzilla.redhat.com/show_bug.cgi?id=1099998
Some of us have wanted to disable global maintenance upon bootup by adding
a systemd service on Fedora 20 (since you must enable global maintenance to
shut it down cleanly), and have found it impossible to create the necessary
systemd dependencies. It seems that (at least with 3.4) hosted-engine
--set-maintenance --mode=none will return an error for several seconds
after all other services have started and it's not clear what can be waited
upon in order to issue the command with assurance it will complete
successfully. This isn't strictly a setup/migration issue but it is an
issue with setting up a desired configuration with hosted-engine. The way
to reproduce this is simply to wait until gdm-greeter displays the login
prompt, ssh into the system and execute hosted-engine --set-maintenance
--mode=none and observe the error. Or create a systemd service that depends
upon (waits for) the latest-possible service, try executing the command
there, and observe the error. Ideally there would be some external
observable event which a systemd service could depend upon, when
hosted-engine is ready to do its thing.
Regards,
Bob
On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
> Hi all,
>
> We already have quite a lot of open ovirt-hosted-engine-setup bugs for
> 3.6 [1].
>
> Yesterday I tried helping someone on irc who planned to migrate to
> hosted-engine
> manually, and without knowing (so it seems) that such a feature exists.
> He had
> an engine set up on a physical host, prepared a VM for it, and asked
> about migrating
> the engine to the VM. In principle this works, but the final result will
> be a
> hosted-engine, where the engine manages a VM the runs itself, without
> knowing it,
> and without HA.
>
> The current recommended migration flow is described in [2]. This page is
> perhaps
> a bit outdated, perhaps missing some details etc., but principally works.
> The main
> issue with it, AFAICT after discussing this a bit with few people, is
> that it
> requires a new clean host.
>
> I'd like to hear what people here think about such and similar flows.
>
> If you already had an engine and migrated to hosted-engine, what was
> good, what
> was bad, what would you like to change?
>
> If you plan such a migration, what do you find missing currently?
>
> [1]
http://red.ht/1vle8Vv
> [2]
http://www.ovirt.org/Migrate_to_Hosted_Engine
>
> Best,
> --
> Didi
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/devel
>