Hi,
I hit this problem again. Otopi sends many zero bytes before a response.
This time, on an engine installed from master RPM, not dev environment.
The engine and host machines are latest Centos 7.
Is there some workaround for deploying the host?
Thanks,
Andrej
On Thu, 20 Sep 2018 at 08:59, Y
That would work too... the end result would be same, tar pads the last
record with zeros as well
On Thu, Sep 20, 2018 at 9:51 AM Yedidyah Bar David wrote:
> On Mon, Sep 17, 2018 at 6:35 PM Yuval Turgeman
> wrote:
>
>> Ok, regarding the tar issue, there's another solution - since
>> commons-comp
On Mon, Sep 17, 2018 at 6:35 PM Yuval Turgeman wrote:
> Ok, regarding the tar issue, there's another solution - since
> commons-compress hard coded the blocking factor to 1, while the default in
> tar is 20, we could continue creating the tar as we do today, but add a
> bunch of zeros to the end
On Mon, Sep 17, 2018 at 2:29 PM Sandro Bonazzola wrote:
>
>
>
> Il giorno lun 17 set 2018 alle ore 13:27 Martin Perina
> ha scritto:
>>
>>
>>
>> On Mon, Sep 17, 2018 at 12:47 PM Dafna Ron wrote:
>>>
>>> I think that in ovirt-engine we currently only build to centos.
>>> since we have not had an
I had to re-trigger didi's fix due to a issue in Jenkins but I can now
confirm that the issue is resolved in ovirt-engine and that we have a new
ovirt-engine package in tested for el7:
https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/10340/
https://resource
Ok, regarding the tar issue, there's another solution - since
commons-compress hard coded the blocking factor to 1, while the default in
tar is 20, we could continue creating the tar as we do today, but add a
bunch of zeros to the end of the tarball.
[yturgema@piggie ~/aa]$ ls -l ovirt-host-deploy
On Mon, 17 Sep 2018, 16:25 Ravi Shankar Nori, wrote:
> host-deploy is still broken on master fc28
>
Yes, there are multiple issues on FC28, but the question is if this fixed
OST on CentOS?
> On Mon, Sep 17, 2018 at 8:01 AM, Yuval Turgeman
> wrote:
>
>> I'm pretty sure I verified this on el7 a
host-deploy is still broken on master fc28
On Mon, Sep 17, 2018 at 8:01 AM, Yuval Turgeman wrote:
> I'm pretty sure I verified this on el7 as well, i'll check again, but
> thinking about it, tar will stop when it gets to the first empty block, so
> if the record size on the engine's side is larg
I'm pretty sure I verified this on el7 as well, i'll check again, but
thinking about it, tar will stop when it gets to the first empty block, so
if the record size on the engine's side is large and the end is filled with
zeros, -b1 will make it stop at the first empty block so the next read on
the
Didi,
Is this what you are looking for
https://ovirt-jira.atlassian.net/browse/OVIRT-2259
?
Galit
On Mon, Sep 17, 2018 at 1:54 PM Dafna Ron wrote:
> I think that in ovirt-engine we currently only build to centos.
> since we have not had an engine build for 2 weeks (on master) I think we
> shoul
Il giorno lun 17 set 2018 alle ore 13:27 Martin Perina
ha scritto:
>
>
> On Mon, Sep 17, 2018 at 12:47 PM Dafna Ron wrote:
>
>> I think that in ovirt-engine we currently only build to centos.
>> since we have not had an engine build for 2 weeks (on master) I think we
>> should merge and worry ab
On Mon, Sep 17, 2018 at 12:47 PM Dafna Ron wrote:
> I think that in ovirt-engine we currently only build to centos.
> since we have not had an engine build for 2 weeks (on master) I think we
> should merge and worry about fc28 once it would be relevant.
>
So let's get the change reverted and let
I think that in ovirt-engine we currently only build to centos.
since we have not had an engine build for 2 weeks (on master) I think we
should merge and worry about fc28 once it would be relevant.
the failure we have now could be another regression missed since the
project has been broken for two
On Mon, Sep 17, 2018 at 11:49 AM Dafna Ron wrote:
>
> Didi, Marin, any update on the patch?
Yes - it passed. Actually failed, but only after host-deploy:
https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_manual/3189/
I'd rather not merge it as-is, because it will brea
Didi, Marin, any update on the patch?
On Sun, Sep 16, 2018 at 11:09 AM Yedidyah Bar David wrote:
> On Sun, Sep 16, 2018 at 12:53 PM Yedidyah Bar David
> wrote:
> >
> > On Fri, Sep 14, 2018 at 6:06 PM Martin Perina
> wrote:
> > >
> > >
> > >
> > > On Fri, Sep 14, 2018 at 4:51 PM, Ravi Shankar
On Sun, Sep 16, 2018 at 12:53 PM Yedidyah Bar David wrote:
>
> On Fri, Sep 14, 2018 at 6:06 PM Martin Perina wrote:
> >
> >
> >
> > On Fri, Sep 14, 2018 at 4:51 PM, Ravi Shankar Nori wrote:
> >>
> >> I see the same errors on my dev env. From the logs attached by Andrej the
> >> response receive
On Fri, Sep 14, 2018 at 6:06 PM Martin Perina wrote:
>
>
>
> On Fri, Sep 14, 2018 at 4:51 PM, Ravi Shankar Nori wrote:
>>
>> I see the same errors on my dev env. From the logs attached by Andrej the
>> response received by otopi has a bunch of null chars before the actual
>> response CONFIRM DE
בתאריך יום ו׳, 14 בספט׳ 2018, 19:03, מאת Ravi Shankar Nori <
rn...@redhat.com>:
> Hi Martin,
>
> This is what I did. Checked out jenkins, ovirt-system-tests and ran the
> mock from ovirt-engine dir.
>
> ../jenkins/mock_configs/mock_runner.sh -e
> ../ovirt-system-tests/automation/upgrade-from-rele
Hi Martin,
This is what I did. Checked out jenkins, ovirt-system-tests and ran the
mock from ovirt-engine dir.
../jenkins/mock_configs/mock_runner.sh -e
../ovirt-system-tests/automation/upgrade-from-release_suite_master.sh el7
On Fri, Sep 14, 2018 at 11:23 AM, Martin Perina wrote:
>
>
> On Fri
On Fri, Sep 14, 2018 at 4:44 PM, Dafna Ron wrote:
> if you run it with mock you would remove any environmental conditions that
> can effect the outcome so I recommend using mock
>
Out of curiosity how to use mock_runner with run_suite? There are not
mentioned any steps on execution using mock_ru
On Fri, Sep 14, 2018 at 5:15 PM, Dafna Ron wrote:
> didi and Sandro are both not working today.
>
So we will need to wait until Sunday/Monday, because I don't think anyone
else from the team really understand otopi internals.
>
> if they are not back by Friday, can we try to find the patch that
didi and Sandro are both not working today.
if they are not back by Friday, can we try to find the patch that caused
this and revert?
CQ reported this as the cause: https://gerrit.ovirt.org/#/c/94081/3
But it did not seem related to this issue, however, it was merged 11 days
ago and we could have
On Fri, Sep 14, 2018 at 4:51 PM, Ravi Shankar Nori wrote:
> I see the same errors on my dev env. From the logs attached by Andrej the
> response received by otopi has a bunch of null chars before the actual
> response CONFIRM DEPLOY_PROCEED=yes
>
>
>
> 2018-09-14 15:49:23,018+0200 DEBUG otopi.plu
I see the same errors on my dev env. From the logs attached by Andrej the
response received by otopi has a bunch of null chars before the actual
response CONFIRM DEPLOY_PROCEED=yes
2018-09-14 15:49:23,018+0200 DEBUG otopi.plugins.otopi.dialog.machine
dialog.__logString:204 DIALOG:SEND ###
if you run it with mock you would remove any environmental conditions that
can effect the outcome so I recommend using mock
On Fri, Sep 14, 2018 at 3:32 PM, Martin Perina wrote:
>
>
> On Fri, Sep 14, 2018 at 3:49 PM, Dafna Ron wrote:
>
>> did you use mock to reproduce?
>>
>
> No, just run_suit
On Fri, Sep 14, 2018 at 3:49 PM, Dafna Ron wrote:
> did you use mock to reproduce?
>
No, just run_suite under myself
>
> On Fri, Sep 14, 2018 at 2:39 PM, Martin Perina wrote:
>
>> Hi,
>>
>> the problem is that we haven't fetched the temporary host-deploy log from
>> /tmp directory, so we don't
did you use mock to reproduce?
On Fri, Sep 14, 2018 at 2:39 PM, Martin Perina wrote:
> Hi,
>
> the problem is that we haven't fetched the temporary host-deploy log from
> /tmp directory, so we don't know which string that host-deploy process sent
> to engine is causing that issue. I tried to rep
Hi,
the problem is that we haven't fetched the temporary host-deploy log from
/tmp directory, so we don't know which string that host-deploy process sent
to engine is causing that issue. I tried to reproduce on my local machine,
but I was unable to reproduce it, 002_bootstrap phase finished succes
Full logs can be found here:
https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/10307/artifact/upgrade-from-release-suite.el7.x86_64/test_logs/upgrade-from-release-suite-master/post-002_bootstrap.py/
On Fri, Sep 14, 2018 at 12:48 PM, Dafna Ron wrote:
> Hi,
Hi,
The previous regression was resolved and we now have a new regression.
I don't think that the reported change is related so can someone from
ovirt-engine take a look?
The failure is add host on the upgrade suite.
Please note that we have not had an engine-ovirt build for over 10 days due
to
30 matches
Mail list logo
