On Apr 26, 2017, at 1:49 AM, Yaniv Kaul <ykaul@redhat.com> wrote:

In my hopefully-near-complete quest to automate Ovirt configuration in our environment, I’m very close. One outstanding issue that remains is that, even though the hosted engine storage domain actually was imported and shows in the GUI, some part of Ovirt appears to think that hasn’t happened yet.

We'll be happy to hear, once complete, how you've achieved this automation. Note that there are several implementations already doing this successfully. See [1] for one.

Thanks, I looked at that. Our implementation is pretty site-specific, but briefly, the Ovirt part is just a set of Puppet classes and some scripts for glue. The site specific stuff does things like driving our Gluster config, dumping the DB/loading into our PG cluster[1] and reconfiguring, hooking in to monitoring, replacing the Apache SSL cert, etc. The basic stuff isn’t all that different than one of the generic Puppetforge modules, and if you don’t have our exact environment and requirements, the rest of it wouldn’t be useful. -j Still hoping for a response to the original question…

One outstanding issue that remains is that, even though the hosted engine storage domain actually was imported and shows in the GUI, some part of Ovirt appears to think that hasn’t happened yet.

In the GUI, a periodic error is logged: “The Hosted Engine Storage Domain doesn’t exist. It will be imported automatically…”

In engine.log, all I’m seeing that appears relevant is:

2017-04-25 10:28:57,988-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock Acquired to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null'}' 2017-04-25 10:28:57,992-07 WARN [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Validation of action 'ImportHostedEngineStorageDomain' failed for user SYSTEM. Reasons: VAR__ACTION__ADD,VAR__TYPE__STORAGE__DOMAIN,ACTION_TYPE_FAILED_STORAGE_DOMAIN_ALREADY_EXIST 2017-04-25 10:28:57,992-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock freed to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null’}’

Otherwise the log is pretty clean.

I saw nothing of interest in the Gluster logs or the hosted-engine-ha logs on the host it is running on.

It appears harmless, but then we aren’t actually using these systems yet, and in any case we don’t want the error spamming the log forever. This is 4.1.1.8-1.el7.centos, hosted engine on Centos 7.6.1311, Gluster for both the hosted engine and general data domains.

-j [1] We are a DB heavy shop and want our DBAs managing backups and whatnot, and the installer barfs because we aren’t running an ancient PG version and tune our DBs differently than the absurdly-mandatory Ovirt defaults, so this dance is painful.

On Apr 27, 2017, at 12:12 AM, Simone Tiraboschi <stirabos@redhat.com> wrote:

On Tue, Apr 25, 2017 at 7:53 PM, Jamie Lawrence <jlawrence@squaretrade.com> wrote: Hi all,

In my hopefully-near-complete quest to automate Ovirt configuration in our environment, I’m very close. One outstanding issue that remains is that, even though the hosted engine storage domain actually was imported and shows in the GUI, some part of Ovirt appears to think that hasn’t happened yet.

Did the engine imported it automatically once you had your first regular storage domain it did you forced it somehow?

It was imported automatically. The chain of events was install HE, wait for the emails saying it was done cogitating, create the regular Gluster SD, import it. Shortly thereafter, the HE domain was imported, and things (storage, hosts, clusters) all appear correct in the GUI, but the error persists. -j

In the GUI, a periodic error is logged: “The Hosted Engine Storage Domain doesn’t exist. It will be imported automatically…”

In engine.log, all I’m seeing that appears relevant is:

2017-04-25 10:28:57,988-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock Acquired to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null'}' 2017-04-25 10:28:57,992-07 WARN [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Validation of action 'ImportHostedEngineStorageDomain' failed for user SYSTEM. Reasons: VAR__ACTION__ADD,VAR__TYPE__STORAGE__DOMAIN,ACTION_TYPE_FAILED_STORAGE_DOMAIN_ALREADY_EXIST 2017-04-25 10:28:57,992-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock freed to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null’}’

Otherwise the log is pretty clean.

I saw nothing of interest in the Gluster logs or the hosted-engine-ha logs on the host it is running on.

It appears harmless, but then we aren’t actually using these systems yet, and in any case we don’t want the error spamming the log forever. This is 4.1.1.8-1.el7.centos, hosted engine on Centos 7.6.1311, Gluster for both the hosted engine and general data domains.

Has anyone seen this before?

Thanks in advance,

-j _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On Sat, Apr 29, 2017 at 1:11 AM, Jamie Lawrence <jlawrence@squaretrade.com> wrote:

I’m wondering if I can do this a different way. Since it is already imported, I can create VMs, and the only other warning I’m getting in the logs is unrelated, I’m thinking that the problem here is that something didn’t get properly set in the DB, and I should be able to fix that manually.

In looking at the code (https://github.com/oVirt/ovirt-engine/blob/master/ backend/manager/modules/bll/src/main/java/org/ovirt/ engine/core/bll/storage/domain/ImportHostedEngineStorageDomainCommand.java), it to my (not very deep) read that the setSucceeded call failed, even though AttachStorageDomainToPool worked.

if (getSucceeded()) { AttachStorageDomainToPoolParameters attachSdParams = new AttachStorageDomainToPoolParameters( addSdParams.getStorageDomainId(), addSdParams.getStoragePoolId()); setSucceeded(getBackend().runInternalAction( VdcActionType.AttachStorageDomainToPool, attachSdParams, getContext()).getSucceeded()); }

setActionReturnValue(heStorageDomain);

Is there a way to call setSucceeded without hacking together a custom utility? Not seeing it in vdsClient --help, which doesn’t surprise me. In looking over the stored procedures, I’m also not finding a likely candidate, but that is probably because there are so many that I’m just missing it.

Does anyone know what the relevant SP is, or in some other way clue me in on the right direction here?

I realize this is not supposed to be the way to do things. But I’m not finding a better solution, and attempting to find a “right” way via questions to this isn’t working either. And of course I take full responsibility when Ovirt kills my pets and drinks all my liquor.

I'd suggest to destroy (but without deleting its content!!!) the hosted-engine storage domain in the engine: the auto-import process should simply trigger again.

-j _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

Does anyone know the answer to the specific question below? I'm not asking for workarounds to try; that approach has repeatedly gone nowhere and time is becoming an issue for me. If I'm on the wrong track, I'd be happy to hear that, too. (Well, not happy, but that would at least be progress.) - - - - I’m wondering if I can do this a different way. Since it is already imported, I can create VMs, and the only other warning I’m getting in the logs is unrelated, I’m thinking that the problem here is that something didn’t get properly set in the DB, and I should be able to fix that manually. In looking at the code (https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bl...), it to my (not very deep) read that the setSucceeded call failed, even though AttachStorageDomainToPool worked. if (getSucceeded()) { AttachStorageDomainToPoolParameters attachSdParams = new AttachStorageDomainToPoolParameters( addSdParams.getStorageDomainId(), addSdParams.getStoragePoolId()); setSucceeded(getBackend().runInternalAction( VdcActionType.AttachStorageDomainToPool, attachSdParams, getContext()).getSucceeded()); } setActionReturnValue(heStorageDomain); Is there a way to call setSucceeded without hacking together a custom utility? Not seeing it in vdsClient --help, which doesn’t surprise me. In looking over the stored procedures, I’m also not finding a likely candidate, but that is probably because there are so many that I’m just missing it. Does anyone know what the relevant SP is, or in some other way clue me in on the right direction here? I realize this is not supposed to be the way to do things. But I’m not finding a better solution, and attempting to find a “right” way via questions to this isn’t working either. And of course I take full responsibility when Ovirt kills my pets and drinks all my liquor.