Re: [ovirt-devel] Ceph hyperconvergence
What can I do to help make this happen? I am not a programmer, just a sysadmin using ceph/cinder/ovirt 4 Should I put in an RFE? On Sun, Mar 19, 2017 at 9:12 AM, Yaniv Dary wrote: > We need a native way to use Ceph prior to this type of HCI. > This is currently not there yet. We are thinking of paths that will allow > this in the future, but nothing concrete. > > Yaniv Dary > Technical Product Manager > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > Tel : +972 (9) 7692306 <+972%209-769-2306> > 8272306 > Email: yd...@redhat.com > IRC : ydary > > > On Mon, Mar 13, 2017 at 6:01 PM, Logan Kuhn > wrote: > >> Hi >> >> It was suggested that I ask this list. Are there any plans to add >> hyperconverge with Ceph, similar to the way it has been implemented with >> Gluster? I know that I can add Cinder as an external provider as an >> interface to Ceph, but it's more clunky than a hyperconverged solution. >> >> Regards, >> Logan Kuhn >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ceph hyperconvergence
Yes, open a RFE for now. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Sun, Mar 19, 2017 at 4:16 PM, Logan Kuhn wrote: > What can I do to help make this happen? I am not a programmer, just a > sysadmin using ceph/cinder/ovirt 4 > > Should I put in an RFE? > > > On Sun, Mar 19, 2017 at 9:12 AM, Yaniv Dary wrote: > >> We need a native way to use Ceph prior to this type of HCI. >> This is currently not there yet. We are thinking of paths that will allow >> this in the future, but nothing concrete. >> >> Yaniv Dary >> Technical Product Manager >> Red Hat Israel Ltd. >> 34 Jerusalem Road >> Building A, 4th floor >> Ra'anana, Israel 4350109 >> >> Tel : +972 (9) 7692306 <+972%209-769-2306> >> 8272306 >> Email: yd...@redhat.com >> IRC : ydary >> >> >> On Mon, Mar 13, 2017 at 6:01 PM, Logan Kuhn >> wrote: >> >>> Hi >>> >>> It was suggested that I ask this list. Are there any plans to add >>> hyperconverge with Ceph, similar to the way it has been implemented with >>> Gluster? I know that I can add Cinder as an external provider as an >>> interface to Ceph, but it's more clunky than a hyperconverged solution. >>> >>> Regards, >>> Logan Kuhn >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ceph hyperconvergence
We need a native way to use Ceph prior to this type of HCI. This is currently not there yet. We are thinking of paths that will allow this in the future, but nothing concrete. Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary On Mon, Mar 13, 2017 at 6:01 PM, Logan Kuhn wrote: > Hi > > It was suggested that I ask this list. Are there any plans to add > hyperconverge with Ceph, similar to the way it has been implemented with > Gluster? I know that I can add Cinder as an external provider as an > interface to Ceph, but it's more clunky than a hyperconverged solution. > > Regards, > Logan Kuhn > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] System tests failure (wrong test code?)
On Sun, Mar 19, 2017 at 2:09 PM, Yaniv Kaul wrote:
>
>
> On Sun, Mar 19, 2017 at 12:14 PM, Arik Hadas wrote:
>
>>
>>
>> On Sat, Mar 18, 2017 at 12:57 PM, Yaniv Kaul wrote:
>>
>>>
>>>
>>> On Sat, Mar 18, 2017 at 12:05 AM, Michal Skrivanek
>>> wrote:
>>>
On 17 Mar 2017, at 20:49, Yaniv Kaul wrote:
On Thu, Mar 16, 2017 at 8:16 PM, Michal Skrivanek
wrote:
>
> On 16 Mar 2017, at 15:18, Yaniv Kaul wrote:
>
>
>
> On Thu, Mar 16, 2017 at 10:46 AM, Nir Soffer wr
> ote:
>
>> If found this error in system tests - looks like wrong assert - code
>> should check
>> if disk is not None before checking state.
>>
>> I'm not sure who is the owner of this test, so posting here.
>>
>
> Theoretically, perhaps.
> Practically, it worked (until yesterday?) and now I'm also seeing this
> failure - it's not a coincidence.
>
> However, looking at my failure[1], I'm seeing other nasty stuff, which
> may explain the later on failures
>
> For example, new NPE I have not seen in the past:
> 2017-03-16 09:57:57,581-04 INFO
> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
> (DefaultQuartzScheduler1) [5d94233] Ending command
> 'org.ovirt.engine.core.bll.AddVmTemplateCommand' successfully.
>
>
> Is this IST or which TZ?
>
Interesting question - I guess that's why we need the offset from UTC
or use UTC in the logs.
> Likely https://gerrit.ovirt.org/#/c/69323 merged 10:33:20 CET today
>
That's the cause or the fix?
oh, sorry, the cause.
we were not able to find anyone to confirm and resolve it today
unfortunately
>>>
>> A fix is posted: https://gerrit.ovirt.org/#/c/74276/
>> The cause is explained in the commit message.
>>
>
Merged.
>
> Thanks.
>
>
>> In our defense I'll say that somehow the system tests passed when we ran
>> them ([1]) and that the command for adding a template became way too
>> complicated than it is supposed to be with the introduction of import from
>> glance and instance-types.
>>
>
> Do we have intentions to simplify it?
>
Well, we had such intentions but these things are always the first
candidates to postpone. We should.
>
>
>>
>> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/129/
>>
>>
>>>
>>> A secondary bug is that it fails every 10 seconds or so, continuously.
>>> Y.
>>>
>>
>> Right, because it fails in the end-action phase of the command and we
>> have a retry mechanism that attempts to end the command (unless stated
>> otherwise) periodically.
>>
>
> But the end user experience is an event every few seconds (10?) that we
> fail an operation.
> When does it give up?
>
For the most part, chances are extremely low for a command to fail in its
end-action phase. Generally, commands either fail in their validation phase
or execution phase or when their async tasks/jobs fail. In those case, we
don't have/need a mechanism for periodic retry. On the other hand, the
end-action phase is relatively short and simple and is really not expected
to fail (unless there is a bug, like in this case), but if it does fail -
we have to retry and the user will probably experience more acute issues
than a flood of audit messages (e.g., inability to connect to the
database). AFAIK there is no limit to the number of retry attempts in this
case.
> Y.
>
>
>>
>>
>>>
>>>
>>>
Y.
>
> 2017-03-16 09:57:57,591-04 INFO
> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
> (DefaultQuartzScheduler1) [5d94233] START, SetVmStatusVDSCommand(
> SetVmStatusVDSCommandParameters:{runAsync='true',
> vmId='----', status='Down',
> exitStatus='Normal'}), log id: 30ee3299
> 2017-03-16 09:57:57,593-04 DEBUG [org.ovirt.engine.core.dal.dbb
> roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
> (DefaultQuartzScheduler1) [5d94233] Compiled stored procedure. Call string
> is [{call getvmdynamicbyvmguid(?)}]
> 2017-03-16 09:57:57,594-04 DEBUG [org.ovirt.engine.core.dal.dbb
> roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
> (DefaultQuartzScheduler1) [5d94233] SqlCall for procedure
> [GetVmDynamicByVmGuid] compiled
> 2017-03-16 09:57:57,595-04 ERROR
> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
> (DefaultQuartzScheduler1) [5d94233] Command 'SetVmStatusVDSCommand(
> SetVmStatusVDSCommandParameters:{runAsync='true',
> vmId='----', status='Down',
> exitStatus='Normal'})' execution failed: null
> 2017-03-16 09:57:57,595-04 DEBUG
> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
> (DefaultQuartzScheduler1) [5d94233] Exception:
> java.lang.NullPointerException
> at org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand.execut
> eVDSCommand(SetVmStatusVDSCommand.java:33) [vdsbroker.jar
Re: [ovirt-devel] System tests failure (wrong test code?)
On Sun, Mar 19, 2017 at 12:14 PM, Arik Hadas wrote:
>
>
> On Sat, Mar 18, 2017 at 12:57 PM, Yaniv Kaul wrote:
>
>>
>>
>> On Sat, Mar 18, 2017 at 12:05 AM, Michal Skrivanek
>> wrote:
>>
>>>
>>> On 17 Mar 2017, at 20:49, Yaniv Kaul wrote:
>>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 8:16 PM, Michal Skrivanek
>>> wrote:
>>>
On 16 Mar 2017, at 15:18, Yaniv Kaul wrote:
On Thu, Mar 16, 2017 at 10:46 AM, Nir Soffer wr
ote:
> If found this error in system tests - looks like wrong assert - code
> should check
> if disk is not None before checking state.
>
> I'm not sure who is the owner of this test, so posting here.
>
Theoretically, perhaps.
Practically, it worked (until yesterday?) and now I'm also seeing this
failure - it's not a coincidence.
However, looking at my failure[1], I'm seeing other nasty stuff, which
may explain the later on failures
For example, new NPE I have not seen in the past:
2017-03-16 09:57:57,581-04 INFO
[org.ovirt.engine.core.bll.AddVmTemplateCommand]
(DefaultQuartzScheduler1) [5d94233] Ending command
'org.ovirt.engine.core.bll.AddVmTemplateCommand' successfully.
Is this IST or which TZ?
>>>
>>> Interesting question - I guess that's why we need the offset from UTC or
>>> use UTC in the logs.
>>>
>>>
Likely https://gerrit.ovirt.org/#/c/69323 merged 10:33:20 CET today
>>>
>>> That's the cause or the fix?
>>>
>>>
>>> oh, sorry, the cause.
>>> we were not able to find anyone to confirm and resolve it today
>>> unfortunately
>>>
>>
> A fix is posted: https://gerrit.ovirt.org/#/c/74276/
> The cause is explained in the commit message.
>
Thanks.
> In our defense I'll say that somehow the system tests passed when we ran
> them ([1]) and that the command for adding a template became way too
> complicated than it is supposed to be with the introduction of import from
> glance and instance-types.
>
Do we have intentions to simplify it?
>
> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/129/
>
>
>>
>> A secondary bug is that it fails every 10 seconds or so, continuously.
>> Y.
>>
>
> Right, because it fails in the end-action phase of the command and we have
> a retry mechanism that attempts to end the command (unless stated
> otherwise) periodically.
>
But the end user experience is an event every few seconds (10?) that we
fail an operation.
When does it give up?
Y.
>
>
>>
>>
>>
>>>
>>> Y.
>>>
>>>
2017-03-16 09:57:57,591-04 INFO
[org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
(DefaultQuartzScheduler1) [5d94233] START, SetVmStatusVDSCommand(
SetVmStatusVDSCommandParameters:{runAsync='true',
vmId='----', status='Down',
exitStatus='Normal'}), log id: 30ee3299
2017-03-16 09:57:57,593-04 DEBUG [org.ovirt.engine.core.dal.dbb
roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
(DefaultQuartzScheduler1) [5d94233] Compiled stored procedure. Call string
is [{call getvmdynamicbyvmguid(?)}]
2017-03-16 09:57:57,594-04 DEBUG [org.ovirt.engine.core.dal.dbb
roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
(DefaultQuartzScheduler1) [5d94233] SqlCall for procedure
[GetVmDynamicByVmGuid] compiled
2017-03-16 09:57:57,595-04 ERROR
[org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
(DefaultQuartzScheduler1) [5d94233] Command 'SetVmStatusVDSCommand(
SetVmStatusVDSCommandParameters:{runAsync='true',
vmId='----', status='Down',
exitStatus='Normal'})' execution failed: null
2017-03-16 09:57:57,595-04 DEBUG
[org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
(DefaultQuartzScheduler1) [5d94233] Exception:
java.lang.NullPointerException
at org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand.execut
eVDSCommand(SetVmStatusVDSCommand.java:33) [vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73)
[vdsbroker.jar:]
at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33)
[dal.jar:]
at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandE
xecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:404)
[vdsbroker.jar:]
at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsComman
d(VDSBrokerFrontendImpl.java:33) [bll.jar:]
at org.ovirt.engine.core.bll.VmHandler.unLockVm(VmHandler.java:377)
[bll.jar:]
Y.
[1] http://jenkins.ovirt.org/job/ovirt-system-tests_master_chec
k-patch-el7-x86_64/326/artifact/exported-artifacts/basic_sui
te_master__logs/test_logs/basic-suite-master/post-004_basic_
sanity.py/lago-basic-suite-master-engine/_var_log/ovirt-engi
Re: [ovirt-devel] System tests failure (wrong test code?)
On Sat, Mar 18, 2017 at 12:57 PM, Yaniv Kaul wrote:
>
>
> On Sat, Mar 18, 2017 at 12:05 AM, Michal Skrivanek
> wrote:
>
>>
>> On 17 Mar 2017, at 20:49, Yaniv Kaul wrote:
>>
>>
>>
>> On Thu, Mar 16, 2017 at 8:16 PM, Michal Skrivanek
>> wrote:
>>
>>>
>>> On 16 Mar 2017, at 15:18, Yaniv Kaul wrote:
>>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 10:46 AM, Nir Soffer wrote:
>>>
If found this error in system tests - looks like wrong assert - code
should check
if disk is not None before checking state.
I'm not sure who is the owner of this test, so posting here.
>>>
>>> Theoretically, perhaps.
>>> Practically, it worked (until yesterday?) and now I'm also seeing this
>>> failure - it's not a coincidence.
>>>
>>> However, looking at my failure[1], I'm seeing other nasty stuff, which
>>> may explain the later on failures
>>>
>>> For example, new NPE I have not seen in the past:
>>> 2017-03-16 09:57:57,581-04 INFO
>>> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
>>> (DefaultQuartzScheduler1) [5d94233] Ending command
>>> 'org.ovirt.engine.core.bll.AddVmTemplateCommand' successfully.
>>>
>>>
>>> Is this IST or which TZ?
>>>
>>
>> Interesting question - I guess that's why we need the offset from UTC or
>> use UTC in the logs.
>>
>>
>>> Likely https://gerrit.ovirt.org/#/c/69323 merged 10:33:20 CET today
>>>
>>
>> That's the cause or the fix?
>>
>>
>> oh, sorry, the cause.
>> we were not able to find anyone to confirm and resolve it today
>> unfortunately
>>
>
A fix is posted: https://gerrit.ovirt.org/#/c/74276/
The cause is explained in the commit message.
In our defense I'll say that somehow the system tests passed when we ran
them ([1]) and that the command for adding a template became way too
complicated than it is supposed to be with the introduction of import from
glance and instance-types.
[1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/129/
>
> A secondary bug is that it fails every 10 seconds or so, continuously.
> Y.
>
Right, because it fails in the end-action phase of the command and we have
a retry mechanism that attempts to end the command (unless stated
otherwise) periodically.
>
>
>
>>
>> Y.
>>
>>
>>>
>>> 2017-03-16 09:57:57,591-04 INFO
>>> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
>>> (DefaultQuartzScheduler1) [5d94233] START, SetVmStatusVDSCommand(
>>> SetVmStatusVDSCommandParameters:{runAsync='true',
>>> vmId='----', status='Down',
>>> exitStatus='Normal'}), log id: 30ee3299
>>> 2017-03-16 09:57:57,593-04 DEBUG [org.ovirt.engine.core.dal.dbb
>>> roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
>>> (DefaultQuartzScheduler1) [5d94233] Compiled stored procedure. Call string
>>> is [{call getvmdynamicbyvmguid(?)}]
>>> 2017-03-16 09:57:57,594-04 DEBUG [org.ovirt.engine.core.dal.dbb
>>> roker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
>>> (DefaultQuartzScheduler1) [5d94233] SqlCall for procedure
>>> [GetVmDynamicByVmGuid] compiled
>>> 2017-03-16 09:57:57,595-04 ERROR
>>> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
>>> (DefaultQuartzScheduler1) [5d94233] Command 'SetVmStatusVDSCommand(
>>> SetVmStatusVDSCommandParameters:{runAsync='true',
>>> vmId='----', status='Down',
>>> exitStatus='Normal'})' execution failed: null
>>> 2017-03-16 09:57:57,595-04 DEBUG
>>> [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand]
>>> (DefaultQuartzScheduler1) [5d94233] Exception:
>>> java.lang.NullPointerException
>>> at org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand.execut
>>> eVDSCommand(SetVmStatusVDSCommand.java:33) [vdsbroker.jar:]
>>> at
>>> org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73)
>>> [vdsbroker.jar:]
>>> at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33)
>>> [dal.jar:]
>>> at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandE
>>> xecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:]
>>> at
>>> org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:404)
>>> [vdsbroker.jar:]
>>> at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsComman
>>> d(VDSBrokerFrontendImpl.java:33) [bll.jar:]
>>> at org.ovirt.engine.core.bll.VmHandler.unLockVm(VmHandler.java:377)
>>> [bll.jar:]
>>>
>>>
>>>
>>> Y.
>>>
>>> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_master_chec
>>> k-patch-el7-x86_64/326/artifact/exported-artifacts/basic_sui
>>> te_master__logs/test_logs/basic-suite-master/post-004_basic_
>>> sanity.py/lago-basic-suite-master-engine/_var_log/ovirt-
>>> engine/engine.log
>>>
>>>
*08:28:05* # snapshots_merge: *08:28:31* Unhandled exception in
at 0x276a5f0>*08:28:31* Traceback (most recent call
last):*08:28:31* File
"/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 217, in
assert_equals_within*08:28:31* res = func()*08:28:31* File
"/home/jenkins/workspace/ovirt-system-tests_manual
Re: [ovirt-devel] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]
On Sun, Mar 19, 2017 at 10:33 AM, Eyal Edri wrote: > > > On Sun, Mar 19, 2017 at 10:30 AM, Oved Ourfali > wrote: > >> As Piotr mentioned, the job is using 1.3.8 however 1.3.9 was released. >> > > Thanks, > We will look into the logs and find out what caused it to use 1.3.8 and > report here on the results, can't be sure yet if its a bug in the job or > anything else. > Let me explain what happened: 1. check-patch jobs used to run on latest 'tested' repo, but that repo is very big as it contains history of all the builds done for a release [1] 2. recently we found a bug that caused OST to fail due to out of memory because it tried to sync the entire tested repo into memory ( that's how OST works ), so the tested repo was removed from check-patch. 3. This means that now check-patch is only using the repos in the reposync file, which for 4.1 is latest released. 4. vdsm-jsonrpc-java 1.3.9 wasn't released in any official oVirt 4.1 release, this is why the job used 1.3.8 which is the latest released. 5. We also don't want to replace the default repos for OST on 4.1 to something other than released, because the basic suite per release should always check against official release [2] 6. As a side note - manual jobs also support running on latest tested, so this issue is solely restricted to 'check-patch' jobs. We do however believe that running check-patch on latest code is important, so we'll look into providing an alternate solution that won't break any of the above restrictions, Suggestions are welcome of course. [1] It is done so anyone that wants to check oVirt can do it w/o worrying that a pkg will be removed during testing ( something that was happening when used experimental lastest.tested repo ) [2] As opposed to experimental flows which DO check against latest code, which is why 4.1 experimental didn't fail on this issue, as it used 1.3.9 > > >> >> On Sun, Mar 19, 2017 at 10:27 AM, Barak Korren >> wrote: >> >>> >>> >>> בתאריך 17 במרץ 2017 02:32 PM, "Piotr Kliczewski" < >>> piotr.kliczew...@gmail.com> כתב: >>> >>> >>> The change was merged 2 weeks ago. How can we make sure not to waste >>> people time next time to analyze the issue? >>> >>> >>> "Merged" is hardly "released". >>> >>> As long as a fix does not make it to a release, users can still come >>> across the issue, and so can OST. I can't think of a quick way to avoid >>> that, but I'm open to suggestions >>> >>> WRT getting more frequent oVirt releases, I'm hardly in a position to >>> give input about that. >>> >>> >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 <+972%209-769-2018> > irc: eedri (on #tlv #rhev-dev #rhev-integ) > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]
On Sun, Mar 19, 2017 at 10:30 AM, Oved Ourfali wrote: > As Piotr mentioned, the job is using 1.3.8 however 1.3.9 was released. > Thanks, We will look into the logs and find out what caused it to use 1.3.8 and report here on the results, can't be sure yet if its a bug in the job or anything else. > > On Sun, Mar 19, 2017 at 10:27 AM, Barak Korren wrote: > >> >> >> בתאריך 17 במרץ 2017 02:32 PM, "Piotr Kliczewski" < >> piotr.kliczew...@gmail.com> כתב: >> >> >> The change was merged 2 weeks ago. How can we make sure not to waste >> people time next time to analyze the issue? >> >> >> "Merged" is hardly "released". >> >> As long as a fix does not make it to a release, users can still come >> across the issue, and so can OST. I can't think of a quick way to avoid >> that, but I'm open to suggestions >> >> WRT getting more frequent oVirt releases, I'm hardly in a position to >> give input about that. >> >> >> >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]
As Piotr mentioned, the job is using 1.3.8 however 1.3.9 was released. On Sun, Mar 19, 2017 at 10:27 AM, Barak Korren wrote: > > > בתאריך 17 במרץ 2017 02:32 PM, "Piotr Kliczewski" < > piotr.kliczew...@gmail.com> כתב: > > > The change was merged 2 weeks ago. How can we make sure not to waste > people time next time to analyze the issue? > > > "Merged" is hardly "released". > > As long as a fix does not make it to a release, users can still come > across the issue, and so can OST. I can't think of a quick way to avoid > that, but I'm open to suggestions > > WRT getting more frequent oVirt releases, I'm hardly in a position to give > input about that. > > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]
בתאריך 17 במרץ 2017 02:32 PM, "Piotr Kliczewski" < piotr.kliczew...@gmail.com> כתב: The change was merged 2 weeks ago. How can we make sure not to waste people time next time to analyze the issue? "Merged" is hardly "released". As long as a fix does not make it to a release, users can still come across the issue, and so can OST. I can't think of a quick way to avoid that, but I'm open to suggestions WRT getting more frequent oVirt releases, I'm hardly in a position to give input about that. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [WARNING] Minimum requirements to fit the disk from the appliance OVF not met (required 50 GiB)
On Sat, Mar 18, 2017 at 11:20 PM, Yaniv Kaul wrote: > Any news? > This is still failing for me - perhaps I'm not using the right repo? I'm > using http://resources.ovirt.org/pub/ovirt-4.1-pre/rpm/el7 > I see the patch for fixing it [1] is still not merged, so it needs first to be merged and then it will be in ovirt-4.1-tested.repo, only after ovirt 4.1.1 releases another build it will be in the 4.1-pre repo. [1] https://gerrit.ovirt.org/#/c/73029/ > TIA,Y. > > On Tue, Mar 7, 2017 at 4:35 PM, Sandro Bonazzola > wrote: > >> Adding Yuval and Simone >> >> On Tue, Mar 7, 2017 at 3:00 PM, Yaniv Kaul wrote: >> >>> ovirt-system-tests is failing[1] even though I've given it 100GB+ for >>> every disk I could think of. What is it looking for and where exactly? >>> TIA, >>> Y. >>> >>> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_master_c >>> heck-patch-el7-x86_64/284/console >>> >>> *13:24:17* [ INFO ] Checking OVF archive content (could take a few minutes >>> depending on archive size)*13:24:43* [ INFO ] Checking OVF XML content >>> (could take a few minutes depending on archive size)*13:25:08* [ INFO ] >>> Detecting host timezone.*13:25:08* [WARNING] Minimum requirements to fit >>> the disk from the appliance OVF not met (required 50 GiB)*13:25:08* [ ERROR >>> ] Failed to execute stage 'Environment customization': Minimum requirements >>> to fit the disk from the appliance OVF not met (required 50 GiB)*13:25:08* >>> [ INFO ] Stage: Clean up >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
