Re: [ovirt-devel] oVirt 4.2.0 RC3 status
On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital <mavital@redhat.com> wrote:
Nikolai succeed to reproduce the issue on the clean env,
That's not a precise reproduction, as Nikolai writes in comment 15 "It looks like different now." please see comments in *Bug 1525907*
<https://bugzilla.redhat.com/show_bug.cgi?id=1525907> - VDSM is in recovery mode after a restart in fresh installation. He also found another bug - *Bug 1527077* <https://bugzilla.redhat.com/show_bug.cgi?id=1527077> - SHE deployment fails over FC.
Meital.
On Mon, Dec 18, 2017 at 3:27 PM, Meital Avital <mavital@redhat.com> wrote:
Adding Ying to get her status
On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital <mavital@redhat.com> wrote:
*Update:* Deployment with iSCSI succeed
On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital <mavital@redhat.com> wrote:
Hi All,
The status of old HE deploy for today is: Deployment with NFS succeed Deployment with Gluster succeed Artyom testing HE deployment with iSCSI - in progress According to this BZ1525907 - Nikolai trying again to deploy HE on the same host on clean env - we think that this issue related to those host, this is what we are trying to understand. I don't have the results yet, soon I will have them and I will update this thread.
Thanks, Meital.
On Mon, Dec 18, 2017 at 1:18 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola <sbonazzo@redhat.com
wrote:
2017-12-18 8:37 GMT+01:00 Sandro Bonazzola <sbonazzo@redhat.com>:
> > > 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg <danken@redhat.com>: > >> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola < >> sbonazzo@redhat.com> wrote: >> >>> Hi, >>> according to https://bugzilla.redhat.com >>> /buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_mileston >>> e%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost%2Cmodified >>> we just need to rebuild VDSM to complete the acknowledged blockers. >>> >>> We still have a proposed blocker in NEW state according to >>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag% >>> 3Ablocker%3F%20target_milestone%3Aovirt-4.2.0%20status%3Anew >>> %2Cassigned%2Cpost%2Cmodified >>> >>> 1525907 <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> >>> Storage vdsm General danken@redhat.com NEW VDSM is in recovery >>> mode after a restart in fresh install... >>> <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> urgent >>> urgent ovirt-4.2.0 Sat 18:12 >>> >>> Dan, please review, let us know if we have to block on this or if >>> we can postpone to 4.2.1. >>> >> >> I don't think it is for me to review. >> >> The bug is very confusing and sparse in information, but it seems >> to claim that self-hosted engine is not deployable. I think that it is for >> Simone to reply to that claim. Is it true? When? Do you think, like Adam, >> that this is a problem of host connectivity to its storage? >> > > Adam, Nir, Tal, Allon, can you please review? >
Any update?
+Meital.
On Mon, Dec 18, 2017 at 3:09 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital <mavital@redhat.com> wrote:
Nikolai succeed to reproduce the issue on the clean env,
That's not a precise reproduction, as Nikolai writes in comment 15 "It looks like different now."
For sure it passed the problematic step since hosted-engine-setup was already correctly using vdsm.
please see comments in *Bug 1525907*
<https://bugzilla.redhat.com/show_bug.cgi?id=1525907> - VDSM is in recovery mode after a restart in fresh installation. He also found another bug - *Bug 1527077* <https://bugzilla.redhat.com/show_bug.cgi?id=1527077> - SHE deployment fails over FC.
On my opinion the target device was simply dirty as for https://bugzilla.redhat.com/show_bug.cgi?id=1215427#c4 I don't think it's a new bug.
Meital.
On Mon, Dec 18, 2017 at 3:27 PM, Meital Avital <mavital@redhat.com> wrote:
Adding Ying to get her status
On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital <mavital@redhat.com> wrote:
*Update:* Deployment with iSCSI succeed
On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital <mavital@redhat.com> wrote:
Hi All,
The status of old HE deploy for today is: Deployment with NFS succeed Deployment with Gluster succeed Artyom testing HE deployment with iSCSI - in progress According to this BZ1525907 - Nikolai trying again to deploy HE on the same host on clean env - we think that this issue related to those host, this is what we are trying to understand. I don't have the results yet, soon I will have them and I will update this thread.
Thanks, Meital.
On Mon, Dec 18, 2017 at 1:18 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola < sbonazzo@redhat.com> wrote:
> > > 2017-12-18 8:37 GMT+01:00 Sandro Bonazzola <sbonazzo@redhat.com>: > >> >> >> 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg <danken@redhat.com>: >> >>> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola < >>> sbonazzo@redhat.com> wrote: >>> >>>> Hi, >>>> according to https://bugzilla.redhat.com >>>> /buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_mileston >>>> e%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost%2Cmodified >>>> we just need to rebuild VDSM to complete the acknowledged >>>> blockers. >>>> >>>> We still have a proposed blocker in NEW state according to >>>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag% >>>> 3Ablocker%3F%20target_milestone%3Aovirt-4.2.0%20status%3Anew >>>> %2Cassigned%2Cpost%2Cmodified >>>> >>>> 1525907 <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> >>>> Storage vdsm General danken@redhat.com NEW VDSM is in recovery >>>> mode after a restart in fresh install... >>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> urgent >>>> urgent ovirt-4.2.0 Sat 18:12 >>>> >>>> Dan, please review, let us know if we have to block on this or if >>>> we can postpone to 4.2.1. >>>> >>> >>> I don't think it is for me to review. >>> >>> The bug is very confusing and sparse in information, but it seems >>> to claim that self-hosted engine is not deployable. I think that it is for >>> Simone to reply to that claim. Is it true? When? Do you think, like Adam, >>> that this is a problem of host connectivity to its storage? >>> >> >> Adam, Nir, Tal, Allon, can you please review? >> > > Any update? >
+Meital.
On Mon, Dec 18, 2017 at 3:18 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Mon, Dec 18, 2017 at 3:09 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital <mavital@redhat.com> wrote:
Nikolai succeed to reproduce the issue on the clean env,
That's not a precise reproduction, as Nikolai writes in comment 15 "It looks like different now."
For sure it passed the problematic step since hosted-engine-setup was already correctly using vdsm.
please see comments in *Bug 1525907*
<https://bugzilla.redhat.com/show_bug.cgi?id=1525907> - VDSM is in recovery mode after a restart in fresh installation.
Moved to ON_QA to repeat the test on a clean env
He also found another bug - *Bug 1527077*
<https://bugzilla.redhat.com/show_bug.cgi?id=1527077> - SHE deployment fails over FC.
On my opinion the target device was simply dirty as for https://bugzilla.redhat.com/show_bug.cgi?id=1215427#c4 I don't think it's a new bug.
Meital.
On Mon, Dec 18, 2017 at 3:27 PM, Meital Avital <mavital@redhat.com> wrote:
Adding Ying to get her status
On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital <mavital@redhat.com> wrote:
*Update:* Deployment with iSCSI succeed
On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital <mavital@redhat.com> wrote:
Hi All,
The status of old HE deploy for today is: Deployment with NFS succeed Deployment with Gluster succeed Artyom testing HE deployment with iSCSI - in progress According to this BZ1525907 - Nikolai trying again to deploy HE on the same host on clean env - we think that this issue related to those host, this is what we are trying to understand. I don't have the results yet, soon I will have them and I will update this thread.
Thanks, Meital.
On Mon, Dec 18, 2017 at 1:18 PM, Dan Kenigsberg <danken@redhat.com> wrote:
> > > On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola < > sbonazzo@redhat.com> wrote: > >> >> >> 2017-12-18 8:37 GMT+01:00 Sandro Bonazzola <sbonazzo@redhat.com>: >> >>> >>> >>> 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg <danken@redhat.com>: >>> >>>> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola < >>>> sbonazzo@redhat.com> wrote: >>>> >>>>> Hi, >>>>> according to https://bugzilla.redhat.com >>>>> /buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_mileston >>>>> e%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost%2Cmodified >>>>> we just need to rebuild VDSM to complete the acknowledged >>>>> blockers. >>>>> >>>>> We still have a proposed blocker in NEW state according to >>>>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag% >>>>> 3Ablocker%3F%20target_milestone%3Aovirt-4.2.0%20status%3Anew >>>>> %2Cassigned%2Cpost%2Cmodified >>>>> >>>>> 1525907 <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> >>>>> Storage vdsm General danken@redhat.com NEW VDSM is in recovery >>>>> mode after a restart in fresh install... >>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> urgent >>>>> urgent ovirt-4.2.0 Sat 18:12 >>>>> >>>>> Dan, please review, let us know if we have to block on this or >>>>> if we can postpone to 4.2.1. >>>>> >>>> >>>> I don't think it is for me to review. >>>> >>>> The bug is very confusing and sparse in information, but it seems >>>> to claim that self-hosted engine is not deployable. I think that it is for >>>> Simone to reply to that claim. Is it true? When? Do you think, like Adam, >>>> that this is a problem of host connectivity to its storage? >>>> >>> >>> Adam, Nir, Tal, Allon, can you please review? >>> >> >> Any update? >> > > +Meital. > >
participants (2)
-
Dan Kenigsberg -
Simone Tiraboschi