[Users] Problem setting up new engine with 3.3 on Fedora 19

Sun Nov 3 21:45:55 UTC 2013

On 11/03/2013 04:32 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Bob Doolittle" <bob at doolittle.us.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: users at ovirt.org, "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Sent: Sunday, November 3, 2013 11:24:57 PM
>> Subject: Re: [Users] Problem setting up new engine with 3.3 on Fedora 19
>>
>>
>> On 11/03/2013 03:37 PM, Alon Bar-Lev wrote:
>>    ----- Original Message -----
>>>> From: "Bob Doolittle" <bob at doolittle.us.com>
>>>> To: users at ovirt.org
>>>> Sent: Sunday, November 3, 2013 10:17:36 PM
>>>> Subject: [Users] Problem setting up new engine with 3.3 on Fedora 19
>>>>
>>>> Hi,
>>>>
>>>> I am doing a fresh engine-setup, with all the defaults, using oVirt 3.3
>>>> on Fedora 19 (all updates).
>>>>
>>>> When I connect to it, it shows my default Datacenter as "Uninitialized"
>>>> and shows no Storage (it should show ISODOMAIN). I can see that my
>>>> ISODOMAIN appears to be created and NFS exported, and I can mount it
>>>> [*]. It's not actually mounted anywhere, however, which seems suspicious.
>>>>
>>>> In the Storage tab, if I go to create a New Domain, it shows "Data
>>>> Center Default (NFS) !", and if I mouse-over the exclamation point it
>>>> says "Data Center is uninitialized, in order to initialize add a data
>>>> domain". But I can't actually create a new domain, because the "Use
>>>> Host" pull-down is empty.
>>>>
>>>> Should I not see my local host in that pulldown menu? How am I supposed
>>>> to add local storage?
>>>> I can't find any errors in the log that logs that look relevant. I
>>>> checked:
>>>>
>>>> engine-config.log (no errors)
>>>>
>>>> setup/ovirt-engine-setup-*.log (no errors)
>>>>
>>>> engine.log has no errors that look relevant, but it does have a lot of
>>>> odd java exceptions, which can be viewed here:
>>>> http://pastebin.com/TYxi3p36
>>>>
>>>> Any suggestions?
>> First off, I believe this issue to be resolved thanks to some guidance
>> on #ovirt from abaron and samppah.
>>
>> The QuickStart Guide needs updating. It shows that a DC should be
>> initialized immediately after engine-setup. The reality is (apparently)
>> that you need to add a Host first, add a Data Domain using that Host,
>> and then you can connect the ISO_DOMAIN. Some browser refreshes may be
>> required along the way :)
>>
>> This was masked for me by the bug I mentioned below when I tried adding
>> a host earlier, because NFS service was not active.
>>
>>>> -Bob
>>>>
>>>> * There's a bug in F19 that interferes with engine-setup
>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=970595). Systemd does not
>>>> start the NFS service at boot and you have to do a weird kludge to
>>>> actually get it to start at bootup (described in the bug report). I've
>>>> applied the workaround so that's not my issue but it's worth mentioning
>>>> here.
>>> Thanks for the reference, sandro, we may want to depend on this newer
>>> package.
>>>
>>>> Unfortunately engine-setup doesn't detect that the service is down
>>>> when you attempt to configure an NFS storage domain. That sounds like an
>>>> engine-setup bug to me - it should check and warn the user, which would
>>>> go a fair ways towards mitigating the issue in F19,
>>> I am not sure I follow, we cannot be a database for every known [and future
>>> known] bug out there.
>>> We do restart nfs post setup[1], please send your complete setup log.
>> I'm guessing you're doing the obvious thing: "systemctl restart
>> nfs-server.service".
>>
>> The issue if you study the bug report is that simply doing that in F19
>> is not sufficient. It will not start the service. Hence the bug.
>> The workaround is:
>>
>> systemctl enable nfs-lock.service
>> systemctl enable nfs.target
>> systemctl start nfs.target
>>
> as far as I can see this already been fixed in fedora-19, if you update the nfsutils package.

That's disturbing. My system was fully up-to-date as of Friday, and I'm 
not seeing any pending updates for nfs-utils.
Perhaps it's a re-manifestation of the bug, or a new one which is 
similar in behavior.

>> This is a significant enough issue that I'd be tempted to put this into
>> oVirt for the time being, but that's just me, YMMV (Your Milage May
>> Vary). I do understand the issue of trying to work around a ton of
>> temporary bugs and that sometimes you have to choose your bullets, and
>> of course I'd rather see the fix in F19 than a workaround in oVirt. Not
>> sure how much control we have over the former vs the latter, however.
>> This seems a big issue, since at the moment F19 will simply not work for
>> the most basic of oVirt configurations. Hopefully someday soon this will
>> no longer be an issue but note this bug was reported 6 months ago, the
>> last update was over 2 months ago, and we still don't see a fix for this
>> critical issue in F19.
>>
>> Pointer to log here:
>> https://db.tt/cpnZc71k
> This log is stopped using Ctrl-C at customization stage.

I'm sorry then I don't know what happened to the logs because I don't 
have any others available.

If I see this issue again I'll be sure to save/post the log.

Regards,
     Bob

>   
>>>> and may be more
>>>> important for other platforms which may make different assumptions about
>>>> the default behavior of the NFS service (Fedora assumes it should be
>>>> running, it's just a bug there, but other platforms may arguably assume
>>>> it should not be running by default).
>>> We are not making that assumption as far as I understand.
>>>
>> Perfect. Thanks.
>>
>> Regards,
>>       Bob
>>
>>
>>