[ovirt-devel] Re: Failure to run engine-setup

[Simone Tiraboschi]

On Tue, Jul 30, 2019 at 9:48 AM Eyal Shenitzky  wrote:

> Hi All,
>
> I am failing to run engine-setup due to the following issue:
>
> [ INFO  ] Generating post install configuration file
> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
>
> [ ERROR ] Failed to execute stage 'Misc configuration': a bytes-like
> object is required, not 'str'
> [ INFO  ] Rolling back database schema
>
>
> In the setup log I can see -
>
> 2019-07-30 10:41:31,418+0300 DEBUG otopi.transaction
> transaction._prepare:61 preparing 'File transaction for
> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-s
> etup-ovirt-post.conf''
> 2019-07-30 10:41:31,418+0300 DEBUG otopi.filetransaction
> filetransaction.prepare:184 file
> '/home/eshenitz/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.con
>
> f' missing
> 2019-07-30 10:41:31,419+0300 DEBUG otopi.transaction
> transaction._prepare:66 exception during prepare phase
> Traceback (most recent call last):
>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 62, in
> _prepare
>element.prepare()
>  File "/usr/lib/python3.6/site-packages/otopi/filetransaction.py", line
> 253, in prepare
>os.write(fd, self._content)
> TypeError: a bytes-like object is required, not 'str'
> 2019-07-30 10:41:31,420+0300 DEBUG otopi.context
> context._executeMethod:145 method exception
> Traceback (most recent call last):
>  File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
> _executeMethod
>method['method']()
>  File
> "/home/eshenitz/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/postinstall.py",
> line 98, in _misc
>otopicons.CoreEnv.MODIFIED_FILES
>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 106,
> in append
> self._prepare(element=element)
>  File "/usr/lib/python3.6/site-packages/otopi/transaction.py", line 62, in
> _prepare
>element.prepare()
>  File "/usr/lib/python3.6/site-packages/otopi/filetransaction.py", line
> 253, in prepare
>os.write(fd, self._content)
> TypeError: a bytes-like object is required, not 'str'
> 2019-07-30 10:41:31,421+0300 ERROR otopi.context
> context._executeMethod:154 Failed to execute stage 'Misc configuration': a
> bytes-like object is required, not 'str'
> 2019-07-30 10:41:31,421+0300 DEBUG otopi.transaction transaction.abort:119
> aborting 'CinderLib Database Transaction'
>
> Does anyone encounter it?
>

Maybe is a side effect of https://gerrit.ovirt.org/#/c/102204/ on python 3
env.
Didi?


>
> Thanks,
> --
> Regards,
> Eyal Shenitzky
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/OXHERFXZVEJVTJSJA2CNCXNWCFYIWOPW/
>


-- 

Simone Tiraboschi

He / Him / His

Principal Software Engineer

Red Hat <https://www.redhat.com/>

stira...@redhat.com
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
<https://redhat.com/summit>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/EFC3IDDP3TRLPDKM7K4BHWF3A4H5ITRY/

[ovirt-devel] Re: Low Performance Issue

[Simone Tiraboschi]

Il Sab 8 Giu 2019, 19:41 Akshita Jain  ha
scritto:

> I've setup oVirt HCI over 3 servers.
> Each server has 1* 480 GB SSD, 5* 1.8 TB SAS HDD with oVirt version 4.3.3
> But I am still able to get low performance.
>

Hi, do you have enough network bandwidth between your hosts?


> Can anyone suggest the tuning variables for Gluster volume.
>
> Remark :What should the value be set for network.remote-dio= enable /
> disable ?
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QZHFYHY45TYYTV2DG4OYEKIDWHR6U5MH/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ZPDDHTHAX5JXPTX4SJ4UDT43CZFECJHB/

[ovirt-devel] Re: ovirt-engine has been tagged (ovirt-engine-4.3.4.1)

[Simone Tiraboschi]

Sorry,
I also have https://gerrit.ovirt.org/#/c/99523/ on engine side which
address different bugs target for 4.3.4 (
https://bugzilla.redhat.com/1664479 https://bugzilla.redhat.com/1665934
https://bugzilla.redhat.com/1691244 ) but AFAIK this is going to be last
compose for 4.3.4.
Should  we postpone all of them to 4.3.5?

On Tue, May 21, 2019 at 10:56 AM Tal Nisan  wrote:

>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/DWHYEQH3VAK3BMCB3JQKWFEL7DEB7F5B/
>


-- 

Simone Tiraboschi

He / Him / His

Principal Software Engineer

Red Hat <https://www.redhat.com/>

stira...@redhat.com
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
<https://redhat.com/summit>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A3WQJ2TSTEINCSHKX4HDTHNIW4NKY5VM/

[ovirt-devel] Testing oVirt with Gluster 6

[Simone Tiraboschi]

Hi,
according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 the
network throughput usage increases by a x5 upgrading from Gluster 3.12 to
Gluster 5.y.

This seems definitively problematic on our hyper-converged environments: I
read more than one report where, over 1 Gbps network, sanlock could not be
refreshed quickly enough and so killed the engine VM if not rebooted the
host due to the watchdog.
This is probably due to the fact that, according to that bug, the network
got completely saturated.
Faster networks seems still fine.
https://bugzilla.redhat.com/show_bug.cgi?id=1673058  is probably going to
be solved for Gluster 5.6.

On the other side we have https://bugzilla.redhat.com/1693998
 about rebasing over
Gluster 6 which seems not affected by that issue.
Do you have concrete plans about testing oVirt with Gluster 6?

thanks,
Simone
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IVTYCFKCQ5P2WZ43CM245PTX5T54PLQX/

[ovirt-devel] Re: FYI - Many nightly suites, including Network, HE and HC are failing since 2-3 days ago

[Simone Tiraboschi]

On Sun, Mar 17, 2019 at 3:04 PM Eyal Edri  wrote:

> Not sure if all the same issue, but seems to failing around the same time:
>
>   ovirt-system-tests_hc-basic-suite-4.2 1 day 12 hr - #824 12 hr - #825 57
> min  integ-tests
>   ovirt-system-tests_hc-basic-suite-master 2 days 12 hr - #1043 12 hr -
> #1045 51 min  integ-tests
>   ovirt-system-tests_he-basic-ansible-suite-4.3 N/A 11 hr - #11 24 sec 
> integ-tests
>   ovirt-system-tests_he-basic-ipv6-suite-master N/A 12 hr - #11 10 min 
> integ-tests
>   ovirt-system-tests_he-basic-iscsi-suite-master 2 days 10 hr - #871 10
> hr - #873 1 hr 36 min  integ-tests
>   ovirt-system-tests_he-basic-suite-master 2 days 11 hr - #1147 11 hr -
> #1149 1 hr 26 min  integ-tests
>   ovirt-system-tests_he-node-ng-suite-master 2 days 12 hr - #727 12 hr
> - #729 1 hr 54 min  integ-tests
>

It's a NullPointerException on engine side:
I opened a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1690159 which
is not on POST



>   ovirt-system-tests_network-suite-master 3 days 12 hr - #926 12 hr -
> #929 45 min  integ-tests
>   ovirt-system-tests_openshift-on-ovirt-suite-4.2 3 days 10 hr - #187 10
> hr - #190 45 min  integ-tests
>
> Links to jobs can be found here: https://jenkins.ovirt.org/
>
> --
>
> Eyal edri
>
>
> MANAGER
>
> RHV/CNV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CQP4YDTMT53J5JKZQLYSYOELIVCHKVKE/

[ovirt-devel] Re: Taking down the engine without setting global maintenance

[Simone Tiraboschi]

On Thu, Mar 7, 2019 at 10:34 AM Yedidyah Bar David  wrote:

> On Thu, Mar 7, 2019 at 11:30 AM Martin Sivak  wrote:
> >
> > Hi,
> >
> > there is no way to distinguish an engine that is not responsive
> > (software or network issue) from a VM that is being powered off. The
> > shutdown takes some time during which you just do not know.
>
> _I_ do not know, but the user might still know beforehand.
>
> > Global
> > maintenance informs the tooling in advance that something like this is
> > going to happen.
>
> Yes. But users keep forgetting setting it. So I am trying to come up
> with something that will fix that :-)
>

Now we have exactly the opposite:
engine-setup is already checking for global maintenance mode (the check
acts on the engine DB over what the hosts report when polled so we have a
bit of latency here) and engine-setup is exiting if we are on hosted-engine
and not in global maintenance mode.
https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/plugins/ovirt-engine-common/ovirt-engine/system/he.py#L49



>
> Perhaps instead of my original text, use something like "Right before
> the engine goes down, it should set global maintenance".
>
> >
> > Who do you expect should be touching the shared storage? The engine VM
> > itself? That might be possible, but remember the jboss instance is
> > just the top of the process hierarchy. There are a lot of components
> > where something might break during shutdown (filesystem umount timeout
> > for example).
>
> I did say "engine", not "engine vm". But see above for perhaps clearer
> text.
>
> >
> > Martin
> >
> > On Thu, Mar 7, 2019 at 9:27 AM Yedidyah Bar David 
> wrote:
> > >
> > > Hi all,
> > >
> > > How about making this change:
> > >
> > > Right before the engine goes down cleanly, it marks the shared storage
> > > saying it did not crash but exited cleanly, and then HE-HA will not
> > > try to restart it on another host. Perhaps make this optional, so that
> > > users can do clean shutdowns and still test HA cleanly (or some other
> > > use cases, where users might not want this).
> > >
> > > This should help a lot cases where people restarted their engine for
> > > some reason, e.g. upgrade, and forgot to set maintenance.
> > >
> > > Makes sense?
> > > --
> > > Didi
> > > ___
> > > Devel mailing list -- devel@ovirt.org
> > > To unsubscribe send an email to devel-le...@ovirt.org
> > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > > List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WCLSLEVXPHGRHL5BJHPLSYWPPOCMIJOQ/
>
>
>
> --
> Didi
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/N3HRNZTWPJ4N5CGUX3WT4VFZUF65IZBS/

[ovirt-devel] Re: [OST failure] he-node-ng_suite_master

[Simone Tiraboschi]

On Mon, Feb 11, 2019 at 10:20 AM Ales Musil  wrote:

> Hi,
> the he-node-ng_suite_master is with [1]:
>
> STDERR
>  
> Error:
>  ovirt-hosted-engine-setup conflicts with 
> ovirt-engine-appliance-4.4-20190206.1.el7.x86_64
>  
> Cannot
>  upload enabled repos report, is this client registered?
>  
> 
>  
> 
>   - STDERR
>  
> Error:
>  ovirt-hosted-engine-setup conflicts with 
> ovirt-engine-appliance-4.4-20190206.1.el7.x86_64
>  
> Cannot
>  upload enabled repos report, is this client registered?
>
>
> Does anyone know how to solve this?
>

Hi,
it should be already solved since we already created a 4.3 branch on
ovirt-hosted-engine-setup and ovirt-hosted-engine-setup on master is going
to work with appliance 4.4 on master as for:
https://gerrit.ovirt.org/#/c/97615/1/ovirt-hosted-engine-setup.spec.in@88

I think it's just a matter of configured repos.


>
> Thank you.
> Regards,
> Ales
>
> [1]
> https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/3133/
>
> --
>
> ALES MUSIL
> Associate Software Engineer - rhv network
>
> Red Hat EMEA 
>
>
> amu...@redhat.com   IM: amusil
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/PT3PXHKJCJBRL25CTELR6S5CXWXECZ25/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/SCGJ4ZYVRT7HNBTR6CYLJQIHZAMSFOZG/

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Wed, Feb 6, 2019 at 11:17 AM Barak Korren  wrote:

>
>
> On Wed, 6 Feb 2019 at 11:57, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 10:44 AM Barak Korren  wrote:
>>
>>>
>>>
>>> On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg 
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi <
>>>>>>> stira...@redhat.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg 
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi <
>>>>>>> stira...@redhat.com> wrote:
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron 
>>>>>>> wrote:
>>>>>>> >> >>
>>>>>>> >> >> Hi,
>>>>>>> >> >>
>>>>>>> >> >> Please note that ovirt-ansible-hosted-engine-setup has a
>>>>>>> versioning problem with the package and is causing bootstrap to fail for
>>>>>>> upgrade suite [1]
>>>>>>> >> >>
>>>>>>> >> >> This is effecting all projects, its been reported to the
>>>>>>> developers and should be fixed as soon as possible.
>>>>>>> >> >>
>>>>>>> >> >> you can view CQ status here:
>>>>>>> >> >>
>>>>>>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
>>>>>>> >> >>
>>>>>>> >> >> [1] http://pastebin.test.redhat.com/708086
>>>>>>> >>
>>>>>>> >> It is unfair to refer to an internal pastebin here. It is also not
>>>>>>> >> very sensible, as it is quite short.
>>>>>>> >>
>>>>>>> >> 2019-02-05 11:23:51,390-0500 ERROR
>>>>>>> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum
>>>>>>> >>
>>>>>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>>>>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>>>>>> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context
>>>>>>> >> context._executeMethod:142 method exception
>>>>>>> >> Traceback (most recent call last):
>>>>>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line
>>>>>>> 132,
>>>>>>> >> in _executeMethod
>>>>>>> >> method['method']()
>>>>>>> >>   File
>>>>>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>>>>>> >> line 248, in _packages
>>>>>>> >> self.processTransaction()
>>>>>>> >>   File
>>>>>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>>>>>> >> line 262, in processTransaction
>>>>>>> >> if self._miniyum.buildTransaction():
>>>>>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line
>>>>>>> 920,
>>>>>>> >> in buildTransaction
>>>>>>> >> raise yum.Errors.YumBaseError(msg)
>>>>>>> >> YumBaseError:
>>>>>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>>>>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Wed, Feb 6, 2019 at 10:44 AM Barak Korren  wrote:

>
>
> On Wed, 6 Feb 2019 at 11:34, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 10:23 AM Barak Korren  wrote:
>>
>>>
>>>
>>> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg 
>>>> wrote:
>>>>
>>>>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi 
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg 
>>>>> wrote:
>>>>> >>
>>>>> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi <
>>>>> stira...@redhat.com> wrote:
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron  wrote:
>>>>> >> >>
>>>>> >> >> Hi,
>>>>> >> >>
>>>>> >> >> Please note that ovirt-ansible-hosted-engine-setup has a
>>>>> versioning problem with the package and is causing bootstrap to fail for
>>>>> upgrade suite [1]
>>>>> >> >>
>>>>> >> >> This is effecting all projects, its been reported to the
>>>>> developers and should be fixed as soon as possible.
>>>>> >> >>
>>>>> >> >> you can view CQ status here:
>>>>> >> >>
>>>>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
>>>>> >> >>
>>>>> >> >> [1] http://pastebin.test.redhat.com/708086
>>>>> >>
>>>>> >> It is unfair to refer to an internal pastebin here. It is also not
>>>>> >> very sensible, as it is quite short.
>>>>> >>
>>>>> >> 2019-02-05 11:23:51,390-0500 ERROR
>>>>> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum
>>>>> >>
>>>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>>>> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context
>>>>> >> context._executeMethod:142 method exception
>>>>> >> Traceback (most recent call last):
>>>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132,
>>>>> >> in _executeMethod
>>>>> >> method['method']()
>>>>> >>   File
>>>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>>>> >> line 248, in _packages
>>>>> >> self.processTransaction()
>>>>> >>   File
>>>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>>>> >> line 262, in processTransaction
>>>>> >> if self._miniyum.buildTransaction():
>>>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920,
>>>>> >> in buildTransaction
>>>>> >> raise yum.Errors.YumBaseError(msg)
>>>>> >> YumBaseError:
>>>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>>>> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context
>>>>> >> context._executeMethod:151 Failed to execute stage 'Package
>>>>> >> installation':
>>>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>>>> >> 2019-02-05 11:23:51,413-0500 DEBUG
>>>>> >> otopi.plugins.otopi.debug.debug_failure.debug_failure
>>>>> >> debug_failure._notification:100 tcp connections:
>>>>> >>
>>>>> >> >>
>>>>> >> >
>>>>> >> > The issue is that on github we already have
>>>>> >> > VERSION="1.0.10"
>>>>> >> > as w

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Wed, Feb 6, 2019 at 10:23 AM Barak Korren  wrote:

>
>
> On Wed, 6 Feb 2019 at 11:15, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg  wrote:
>>
>>> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg 
>>> wrote:
>>> >>
>>> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi <
>>> stira...@redhat.com> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron  wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> Please note that ovirt-ansible-hosted-engine-setup has a
>>> versioning problem with the package and is causing bootstrap to fail for
>>> upgrade suite [1]
>>> >> >>
>>> >> >> This is effecting all projects, its been reported to the
>>> developers and should be fixed as soon as possible.
>>> >> >>
>>> >> >> you can view CQ status here:
>>> >> >>
>>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
>>> >> >>
>>> >> >> [1] http://pastebin.test.redhat.com/708086
>>> >>
>>> >> It is unfair to refer to an internal pastebin here. It is also not
>>> >> very sensible, as it is quite short.
>>> >>
>>> >> 2019-02-05 11:23:51,390-0500 ERROR
>>> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum
>>> >>
>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context
>>> >> context._executeMethod:142 method exception
>>> >> Traceback (most recent call last):
>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132,
>>> >> in _executeMethod
>>> >> method['method']()
>>> >>   File
>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>> >> line 248, in _packages
>>> >> self.processTransaction()
>>> >>   File
>>> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
>>> >> line 262, in processTransaction
>>> >> if self._miniyum.buildTransaction():
>>> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920,
>>> >> in buildTransaction
>>> >> raise yum.Errors.YumBaseError(msg)
>>> >> YumBaseError:
>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context
>>> >> context._executeMethod:151 Failed to execute stage 'Package
>>> >> installation':
>>> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
>>> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
>>> >> 2019-02-05 11:23:51,413-0500 DEBUG
>>> >> otopi.plugins.otopi.debug.debug_failure.debug_failure
>>> >> debug_failure._notification:100 tcp connections:
>>> >>
>>> >> >>
>>> >> >
>>> >> > The issue is that on github we already have
>>> >> > VERSION="1.0.10"
>>> >> > as we can see in
>>> >> >
>>> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3
>>> >> >
>>> >> > And this has been bumped before the commit that now is reported as
>>> broken.
>>> >> >
>>> >> > CI instead is still building the package as 1.0.9 ignoring the
>>> commit that bumped the version.
>>> >> > Honestly I don't know how I can fix it if the version value is
>>> already the desired one in the source code.
>>> >>
>>> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only
>>> >>
>>> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ans

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Wed, Feb 6, 2019 at 10:00 AM Dan Kenigsberg  wrote:

> On Wed, Feb 6, 2019 at 10:54 AM Simone Tiraboschi 
> wrote:
> >
> >
> >
> > On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg  wrote:
> >>
> >> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi 
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron  wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning
> problem with the package and is causing bootstrap to fail for upgrade suite
> [1]
> >> >>
> >> >> This is effecting all projects, its been reported to the developers
> and should be fixed as soon as possible.
> >> >>
> >> >> you can view CQ status here:
> >> >>
> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
> >> >>
> >> >> [1] http://pastebin.test.redhat.com/708086
> >>
> >> It is unfair to refer to an internal pastebin here. It is also not
> >> very sensible, as it is quite short.
> >>
> >> 2019-02-05 11:23:51,390-0500 ERROR
> >> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum
> >>
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> >> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context
> >> context._executeMethod:142 method exception
> >> Traceback (most recent call last):
> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132,
> >> in _executeMethod
> >> method['method']()
> >>   File
> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
> >> line 248, in _packages
> >> self.processTransaction()
> >>   File
> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
> >> line 262, in processTransaction
> >> if self._miniyum.buildTransaction():
> >>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920,
> >> in buildTransaction
> >> raise yum.Errors.YumBaseError(msg)
> >> YumBaseError:
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> >> 2019-02-05 11:23:51,391-0500 ERROR otopi.context
> >> context._executeMethod:151 Failed to execute stage 'Package
> >> installation':
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> >> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> >> 2019-02-05 11:23:51,413-0500 DEBUG
> >> otopi.plugins.otopi.debug.debug_failure.debug_failure
> >> debug_failure._notification:100 tcp connections:
> >>
> >> >>
> >> >
> >> > The issue is that on github we already have
> >> > VERSION="1.0.10"
> >> > as we can see in
> >> >
> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3
> >> >
> >> > And this has been bumped before the commit that now is reported as
> broken.
> >> >
> >> > CI instead is still building the package as 1.0.9 ignoring the commit
> that bumped the version.
> >> > Honestly I don't know how I can fix it if the version value is
> already the desired one in the source code.
> >>
> >> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only
> >>
> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm
> >> Not even under "tested":
> >>
> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm
> >>
> >> Simone, can you doublecheck that its artifacts have been built and
> >> have been accepted by the change queue?
> >
> >
> > It has been built here once as 1.0.10:
> >
> https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/
> >
> > then on the next commit, CI started building it again as 1.0.9 although
> in the source code we have 1.0.10 and so this issue.
>
> I don't understand the issue yet (that's not surprising as I do not
> know what is that "ghpush" job). Which CI job

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Wed, Feb 6, 2019 at 9:45 AM Dan Kenigsberg  wrote:

> On Wed, Feb 6, 2019 at 10:16 AM Simone Tiraboschi 
> wrote:
> >
> >
> >
> > On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron  wrote:
> >>
> >> Hi,
> >>
> >> Please note that ovirt-ansible-hosted-engine-setup has a versioning
> problem with the package and is causing bootstrap to fail for upgrade suite
> [1]
> >>
> >> This is effecting all projects, its been reported to the developers and
> should be fixed as soon as possible.
> >>
> >> you can view CQ status here:
> >>
> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
> >>
> >> [1] http://pastebin.test.redhat.com/708086
>
> It is unfair to refer to an internal pastebin here. It is also not
> very sensible, as it is quite short.
>
> 2019-02-05 11:23:51,390-0500 ERROR
> otopi.plugins.otopi.packagers.yumpackager yumpackager.error:85 Yum
>
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> 2019-02-05 11:23:51,390-0500 DEBUG otopi.context
> context._executeMethod:142 method exception
> Traceback (most recent call last):
>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/context.py", line 132,
> in _executeMethod
> method['method']()
>   File
> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
> line 248, in _packages
> self.processTransaction()
>   File
> "/tmp/ovirt-6fV8LBWX5i/otopi-plugins/otopi/packagers/yumpackager.py",
> line 262, in processTransaction
> if self._miniyum.buildTransaction():
>   File "/tmp/ovirt-6fV8LBWX5i/pythonlib/otopi/miniyum.py", line 920,
> in buildTransaction
> raise yum.Errors.YumBaseError(msg)
> YumBaseError:
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> 2019-02-05 11:23:51,391-0500 ERROR otopi.context
> context._executeMethod:151 Failed to execute stage 'Package
> installation':
> [u'ovirt-hosted-engine-setup-2.3.5-0.0.master.20190205110929.gitfdbc215.el7.noarch
> requires ovirt-ansible-hosted-engine-setup >= 1.0.10']
> 2019-02-05 11:23:51,413-0500 DEBUG
> otopi.plugins.otopi.debug.debug_failure.debug_failure
> debug_failure._notification:100 tcp connections:
>
> >>
> >
> > The issue is that on github we already have
> > VERSION="1.0.10"
> > as we can see in
> >
> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3
> >
> > And this has been bumped before the commit that now is reported as
> broken.
> >
> > CI instead is still building the package as 1.0.9 ignoring the commit
> that bumped the version.
> > Honestly I don't know how I can fix it if the version value is already
> the desired one in the source code.
>
> I don't see your ovirt-ansible-hosted-engine-setup-1.0.10, only
>
> https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm
> Not even under "tested":
>
> https://plain.resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-ansible-hosted-engine-setup-1.0.9-0.1.master.20190129095419.el7.noarch.rpm
>
> Simone, can you doublecheck that its artifacts have been built and
> have been accepted by the change queue?
>

It has been built here once as 1.0.10:
https://jenkins.ovirt.org/job/oVirt_ovirt-ansible-hosted-engine-setup_standard-on-ghpush/91/

then on the next commit, CI started building it again as 1.0.9 although in
the source code we have 1.0.10 and so this issue.
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FFS7BGNMZP7ZHMHLC3YEPHAROOFDJNNN/

[ovirt-devel] Re: package versioning problem causing failure on CQ ovirt-master on all projects

[Simone Tiraboschi]

On Tue, Feb 5, 2019 at 7:07 PM Dafna Ron  wrote:

> Hi,
>
> Please note that ovirt-ansible-hosted-engine-setup has a versioning
> problem with the package and is causing bootstrap to fail for upgrade suite
> [1]
>
> This is effecting all projects, its been reported to the developers and
> should be fixed as soon as possible.
>
> you can view CQ status here:
>
> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/
>
> [1] http://pastebin.test.redhat.com/708086
>
>
The issue is that on github we already have
VERSION="1.0.10"
as we can see in
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/master/build.sh#L3

And this has been bumped before the commit that now is reported as broken.

CI instead is still building the package as 1.0.9 ignoring the commit that
bumped the version.
Honestly I don't know how I can fix it if the version value is already the
desired one in the source code.


> Thanks,
> Dafna
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BXN4QB54ONYPAA5FTGWWE7PRT5BPI7AF/

[ovirt-devel] Re: oVirt 4.3.0 Go / No GO

[Simone Tiraboschi]

On Mon, Jan 28, 2019 at 9:01 AM Yedidyah Bar David  wrote:

> On Mon, Jan 28, 2019 at 9:33 AM Sandro Bonazzola 
> wrote:
>
>> 1636867  Miguel
>> Duarte Barroso Network ovirt-engine BLL.Network ASSIGNED medium [OVN] -
>> Can't create ovn network with Hebrew characters - "UnicodeEncodeError:
>> 'ascii' codec can't encode characters"
>> 
>> 1520546  Benny
>> Zlotnik Storage ovirt-engine BLL.Storage NEW high LSM with continuous
>> I/O to the VM failed and auto generated snapshot remains
>> 
>> 1647491  Benny
>> Zlotnik Storage ovirt-engine BLL.Storage NEW urgent All VMs on the same
>> host crash when a snapshot fail on one of them
>> 
>> 1665020  Daniel Erez
>> Storage ovirt-engine BLL.Storage NEW medium In case of a vdsm failure to
>> perform prepareImage as part of transfer disk image (download image),
>> TransferDiskImageCommand fails with NullPointerException
>> 
>> 1646161  shani
>> Storage ovirt-engine BLL.Storage NEW urgent IndexOutOfBoundsException:
>> Index: 0, Size: 0 during import of VM
>> 
>> 1664588  Tal Nisan
>> Storage ovirt-engine BLL.Storage NEW high [CinderLib] - Adding managed
>> storage via UI/REST fails
>> 
>> 1658976  shani
>> Storage ovirt-engine BLL.Storage POST high [Backup restore API] restore
>> VM (created from template with thin copy) from OVF data fails -
>> ImportVmFromConfigurationCommand fails with Error during ValidateFailure.:
>> java.lang.NullPointerException
>> 
>> 1597019  Benny
>> Zlotnik Storage vdsm Core NEW high LSM's diskReplicateFinish failed on
>> libvirtError: internal error: unable to execute QEMU command
>> 'block-job-complete': Block job 'drive-ua' not found
>> 
>> 1552344  Denis
>> Chaplygin Storage vdsm Core NEW high [Backup restore API][libgfapi]
>> Start VM, with snapshot disk attached, resides on Gluster domain, fails
>> with libvirtError 
>> 1563114  Tal Nisan
>> Storage ovirt-engine Frontend.WebAdmin POST medium VM snapshots subtab
>> doesn't show if a snapshot contains memory
>> 
>> 1668713  Ido
>> Rosenzwig Integration ovirt-hosted-engine-setup General POST high Attempting
>> to create Hosted Engine in Cockpit fails with qemu-kvm: -chardev
>> pty,id=charserial0: Failed to create PTY: Operation not permitted
>> 
>> 
>>
>
> Above should probably be split to two bugs - one (comment 2 there)
> is already merged (MODIFIED),
>

I also rebuilt it on Friday so it's already ON_QA.


> other (the main bug) still NEW, might
> be a blocker, but we do not know yet, AFAIU.
>

I tend to think it's not a blocker but just a wrongly configured host since
we never got it on our environments.


>
>
>> 1663949  Tomasz
>> Barański Virt ovirt-engine Host-Deploy POST high Can't check for update
>> on host after upgrade of engine
>> 
>> 1647018  Ori Liel
>> Infra ovirt-engine RestAPI POST urgent disk_attachment href contains
>> "null" instead of "diskattachments" in REST API requests
>> 
>> 1615974  Shirly
>> Radco Metrics ovirt-engine-metrics RFEs POST high [RFE][Tracker] -
>> Replace fluentd for shipping metrics and log, switch to rsyslog.
>> 
>> IDAssigneeoVirt TeamProductComponentStatusSeveritySummary
>>
>> Hi,
>> above you can find the list of current open proposed blockers with target
>> ovirt-4.3.0.
>> oVirt 4.3.0 is planned to be released tomorrow, January 29th 2019.
>> Assignee: please go over above list and:
>> - if the bug is not a blocker please re-target to another release
>> - if the bug is a real blocker please give an ETA.
>>
>>
>>
>>
>> --
>>
>> 

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt 4.2 (ovirt-ansible-hosted-engine-setup) ] [ 14-01-2019 ] [ 001_upgrade_engine.test_initialize_engine]

[Simone Tiraboschi]

On Tue, Jan 15, 2019 at 11:15 AM Yedidyah Bar David  wrote:

> On Tue, Jan 15, 2019 at 11:38 AM Dafna Ron  wrote:
> >
> > The last ovirt-engine package ran on Jan 11th and this failure happened
> on the 14th so the appliance package is suppose to be newer then the engine
> and should be running fine.
> > if this is not the case, then I suggest that the maintainers of the
> project see what is needed to be updated and trigger a new package build
> (which is why I was alerting to the failure)
> >
> > Thanks,
> > Dafna
> >
> >
> > On Tue, Jan 15, 2019 at 6:51 AM Yedidyah Bar David 
> wrote:
> >>
> >> On Mon, Jan 14, 2019 at 2:15 PM Dafna Ron  wrote:
> >> >
> >> > Hi,
> >> >
> >> > we are failing test 001_upgrade_engine.test_initialize_engine on
> ovirt 4.2 for project ovirt-ansible-hosted-engine-setup.
> >> >
> >> > Patch reported by CQ:
> >> >
> >> >
> https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/commit/860f6a69d38719de663cb8ade13eb8bdff2d1e6f
> - Rename the role - replacing '-' with '_'
> >> >
> >> > Ido, can you please check this issue?
> >> >
> >> > failed build:
> >> >
> >> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3712/
>
> This build has a single failure:
>
>
> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3712/testReport/junit/(root)/001_upgrade_engine/running_tests___upgrade_from_release_suite_el7_x86_64___test_initialize_engine/
>
> which is in the upgrade_from_release suite, not hosted-engine.
>
> However, I looked at the logs, and the root cause indeed seems to be
> related to hosted-engine, as the CQ identified (Nice!), which is:
>
>
> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3712/artifact/upgrade-from-release-suite.el7.x86_64/lago_logs/lago.log/*view*/
>
> 2019-01-14 10:38:38,168::ssh.py::ssh::58::lago.ssh::DEBUG::Running
> 8d4833e8 on lago-upgrade-from-release-suite-4-2-engine: yum -y update
> ovirt-*setup*
> 2019-01-14 10:38:39,732::ssh.py::ssh::81::lago.ssh::DEBUG::Command
> 8d4833e8 on lago-upgrade-from-release-suite-4-2-engine returned with 1
> 2019-01-14 10:38:39,733::ssh.py::ssh::89::lago.ssh::DEBUG::Command
> 8d4833e8 on lago-upgrade-from-release-suite-4-2-engine output:
>  Loaded plugins: fastestmirror, versionlock
> Determining fastest mirrors
> Excluding 9 updates due to versionlock (use "yum versionlock status"
> to show them)
> Resolving Dependencies
> --> Running transaction check
> ---> Package ovirt-ansible-engine-setup.noarch 0:1.1.5-1.el7 will be
> updated
> ---> Package ovirt-ansible-engine-setup.noarch
> 0:1.1.7-0.1.master.20181219093302.el7 will be an update
> ---> Package ovirt-ansible-hosted-engine-setup.noarch 0:1.0.2-1.el7
> will be updated
> ---> Package ovirt-ansible-hosted-engine-setup.noarch
> 0:1.0.6-0.1.master.20190114102323.el7 will be an update
> ---> Package ovirt-engine-dwh-setup.noarch 0:4.2.4.3-1.el7 will be updated
> ---> Package ovirt-engine-dwh-setup.noarch
> 0:4.2.5-0.0.master.20180708055101.el7 will be an update
> ---> Package ovirt-engine-extension-aaa-ldap-setup.noarch
> 0:1.3.8-1.el7 will be updated
> ---> Package ovirt-engine-extension-aaa-ldap-setup.noarch
> 0:1.3.9-0.0.master.gitc39177c.el7 will be an update
> --> Processing Dependency: ovirt-engine-extension-aaa-ldap =
> 1.3.9-0.0.master.gitc39177c.el7 for package:
>
> ovirt-engine-extension-aaa-ldap-setup-1.3.9-0.0.master.gitc39177c.el7.noarch
> ---> Package ovirt-engine-setup.noarch 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> ---> Package ovirt-engine-setup-base.noarch 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup-base.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> --> Processing Dependency: ovirt-engine-lib >=
> 4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 for package:
>
> ovirt-engine-setup-base-4.2.8.3-0.0.master.20190111080213.git7965c2e.el7.noarch
> ---> Package ovirt-engine-setup-plugin-ovirt-engine.noarch
> 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup-plugin-ovirt-engine.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> ---> Package ovirt-engine-setup-plugin-ovirt-engine-common.noarch
> 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup-plugin-ovirt-engine-common.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> ---> Package ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch
> 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> ---> Package ovirt-engine-setup-plugin-websocket-proxy.noarch
> 0:4.2.7.5-1.el7 will be updated
> ---> Package ovirt-engine-setup-plugin-websocket-proxy.noarch
> 0:4.2.8.3-0.0.master.20190111080213.git7965c2e.el7 will be an update
> ---> Package ovirt-imageio-proxy-setup.noarch 0:1.4.5-0.el7 will be updated
> ---> Package 

[ovirt-devel] Re: [OST] HE basic suite failing on reposync

[Simone Tiraboschi]

On Wed, Dec 5, 2018 at 10:18 AM Ales Musil  wrote:

>
>
> On Wed, Dec 5, 2018 at 10:13 AM Raz Tamir  wrote:
>
>> Could you please share the link to the job that failed?
>>
>
> It is failing locally.
>

Can you please share the details on how you configured
ovirt-appliance-master-el7

The initial configuration should be as here:
https://github.com/oVirt/ovirt-system-tests/blob/master/he-basic-suite-master/reposync-he.repo
that points to
http://resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/
where we found
https://resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-engine-appliance-4.3-20181204.1.el7.noarch.rpm
as expected.



>
>>
>> On Wed, Dec 5, 2018 at 10:19 AM Ales Musil  wrote:
>>
>>> Hello,
>>>
>>> I am trying to run locally he-basic-ansible-suite-master but it keeps
>>> failing on reposync:
>>> reposync command failed for repoid: ovirt-appliance-master-el7
>>>
>>> Any idea what could be wrong?
>>>
>>> Thank you.
>>> Regards,
>>> Ales
>>>
>>> --
>>>
>>> ALES MUSIL
>>> Associate Software Engineer - rhv network
>>>
>>> Red Hat EMEA 
>>>
>>>
>>> amu...@redhat.com   IM: amusil
>>> 
>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HKGKYUXRGIQOOVD4MTVCJFPFPSW4YCNW/
>>>
>>
>>
>> --
>>
>>
>> Raz Tamir
>> Manager, RHV QE
>>
>
>
> --
>
> ALES MUSIL
> Associate Software Engineer - rhv network
>
> Red Hat EMEA 
>
>
> amu...@redhat.com   IM: amusil
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/LXRGXKC6EBFRHH7UKY4Y3MKGWNPRBP5V/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/Z5IAM4ZXMCJYEP7CLVYCUEZOGZFA4X5A/

Re: [ovirt-devel] [OST][HC] HE fails to deploy

[Simone Tiraboschi]

On Fri, Apr 6, 2018 at 9:28 AM, Sahina Bose  wrote:

> 2018-04-05 20:46:52,773-0400 INFO 
> otopi.ovirt_hosted_engine_setup.ansible_utils 
> ansible_utils._process_output:100 TASK [Get local VM IP]
> 2018-04-05 20:55:28,217-0400 DEBUG 
> otopi.ovirt_hosted_engine_setup.ansible_utils 
> ansible_utils._process_output:94 {u'_ansible_parsed': True, u'stderr_lines': 
> [], u'cmd': u"virsh -r net-dhcp-leases default | grep -i 00:16:3e:24:d3:63 | 
> awk '{ print $5 }' | cut -f1 -d'/'", u'end': u'2018-04-05 20:55:28.046320', 
> u'_ansible_no_log': False, u'stdout': u'', u'changed': True, u'invocation': 
> {u'module_args': {u'warn': True, u'executable': None, u'_uses_shell': True, 
> u'_raw_params': u"virsh -r net-dhcp-leases default | grep -i 
> 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", u'removes': None, 
> u'creates': None, u'chdir': None, u'stdin': None}}, u'start': u'2018-04-05 
> 20:55:28.000470', u'attempts': 50, u'stderr': u'', u'rc': 0, u'delta': 
> u'0:00:00.045850', u'stdout_lines': []}
> 2018-04-05 20:55:28,318-0400 ERROR 
> otopi.ovirt_hosted_engine_setup.ansible_utils 
> ansible_utils._process_output:98 fatal: [localhost]: FAILED! => {"attempts": 
> 50, "changed": true, "cmd": "virsh -r net-dhcp-leases default | grep -i 
> 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", "delta": 
> "0:00:00.045850", "end": "2018-04-05 20:55:28.046320", "rc": 0, "start": 
> "2018-04-05 20:55:28.000470", "stderr": "", "stderr_lines": [], "stdout": "", 
> "stdout_lines": []}
>
> Both the 4.2 and master suites are failing on getting local VM IP.
> Any idea what changed or if I have to change the test?
>
> thanks!
>

Hi Sahina,
4.2 and master suite non HC are correctly running this morning.
http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_he-basic-ansible-suite-master/146/
http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_he-basic-ansible-suite-4.2/76/

I'll try to check the difference with HC suites.

Are you using more than one subnet in the HC suites?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [OST][HC] HE fails to deploy

[Simone Tiraboschi]

On Tue, Apr 3, 2018 at 10:14 AM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Mon, Apr 2, 2018 at 4:44 PM, Sahina Bose <sab...@redhat.com> wrote:
>
>> HE fails to deploy at waiting for host to be up in the local HE VM.
>> The setup logs does not indicate why it failed - atleast I couldn't find
>> anything
>>
>
> I see:
>
> "status": "install_failed"
>
> So I think that something went wrong with host-deploy on that host but we
> definitively need host-deploy logs for that and they are just on the engine
> VM.
>

According to the timestamps it could be related to:
Apr  2 09:58:13 lago-hc-basic-suite-master-host-0 systemd: Starting Open
vSwitch Database Unit...
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: runuser: System
error
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl:
/etc/openvswitch/conf.db does not exist ... (warning).
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: Creating empty
database /etc/openvswitch/conf.db runuser: System error
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: [FAILED]
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
ovsdb-server.service: control process exited, code=exited status=1
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Failed to start
Open vSwitch Database Unit.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Unit
ovsdb-server.service entered failed state.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
ovsdb-server.service failed.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Cannot add
dependency job for unit lvm2-lvmetad.socket, ignoring: Invalid request
descriptor
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Assertion failed
for Open vSwitch Delete Transient Ports.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
ovsdb-server.service holdoff time over, scheduling restart.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Cannot add
dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: start request
repeated too quickly for ovsdb-server.service
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Failed to start
Open vSwitch Database Unit.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Unit
ovsdb-server.service entered failed state.
Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
ovsdb-server.service failed.


>
>
>>
>> -- Forwarded message --
>> From: <jenk...@jenkins.phx.ovirt.org>
>> Date: Mon, Apr 2, 2018 at 7:50 PM
>> Subject: [oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master -
>> Build # 276 - Still Failing!
>> To: in...@ovirt.org, sab...@redhat.com
>>
>>
>> Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
>> te-master/
>> Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
>> te-master/276/
>> Build Number: 276
>> Build Status:  Still Failing
>> Triggered By: Started by timer
>>
>> -
>> Changes Since Last Success:
>> -
>> Changes for Build #265
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>> [Sandro Bonazzola] ovirt-engine: add jobs for 4.1.10 async
>>
>>
>> Changes for Build #266
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #267
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>> [Daniel Belenky] ppc repos: Use qemu EV release instead of test
>>
>> [Daniel Belenky] global_setup: Add generic package remove function
>>
>> [Daniel Belenky] Fix package verification in verify_packages
>>
>>
>> Changes for Build #268
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #269
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #270
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #271
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #272
>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>
>>
>> Changes for Build #273
>> [Eitan Raviv] network: macpool: test disallowing dups while dups exist
>>
>> [Daniel Belenky] docker cleanup:Fix edge case for unamed containers
>>
>> [Daniel Belenky] nested_config: Count nesting level of options
>>
>> [Daniel Belenky] Introduce conditional e

Re: [ovirt-devel] [OST][HC] HE fails to deploy

[Simone Tiraboschi]

On Mon, Apr 2, 2018 at 4:44 PM, Sahina Bose  wrote:

> HE fails to deploy at waiting for host to be up in the local HE VM.
> The setup logs does not indicate why it failed - atleast I couldn't find
> anything
>

I see:

"status": "install_failed"

So I think that something went wrong with host-deploy on that host but we
definitively need host-deploy logs for that and they are just on the engine
VM.


>
> -- Forwarded message --
> From: 
> Date: Mon, Apr 2, 2018 at 7:50 PM
> Subject: [oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master - Build
> # 276 - Still Failing!
> To: in...@ovirt.org, sab...@redhat.com
>
>
> Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
> te-master/
> Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
> te-master/276/
> Build Number: 276
> Build Status:  Still Failing
> Triggered By: Started by timer
>
> -
> Changes Since Last Success:
> -
> Changes for Build #265
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
> [Sandro Bonazzola] ovirt-engine: add jobs for 4.1.10 async
>
>
> Changes for Build #266
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #267
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
> [Daniel Belenky] ppc repos: Use qemu EV release instead of test
>
> [Daniel Belenky] global_setup: Add generic package remove function
>
> [Daniel Belenky] Fix package verification in verify_packages
>
>
> Changes for Build #268
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #269
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #270
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #271
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #272
> [Gal Ben Haim] Check if the prefix exists before printing its size
>
>
> Changes for Build #273
> [Eitan Raviv] network: macpool: test disallowing dups while dups exist
>
> [Daniel Belenky] docker cleanup:Fix edge case for unamed containers
>
> [Daniel Belenky] nested_config: Count nesting level of options
>
> [Daniel Belenky] Introduce conditional execution in STDCI DSL
>
> [Daniel Belenky] Add OST STDCI V2 jobs
>
>
> Changes for Build #274
> [Gal Ben Haim] he-iscsi-master: Temporarily exclude in check-patch
>
>
> Changes for Build #275
> [Gal Ben Haim] he-iscsi-master: Temporarily exclude in check-patch
>
>
> Changes for Build #276
> [Barak Korren] Force STDCI V2 job to use physical host
>
> [Daniel Belenky] Build container on changes to docker_cleanup
>
>
>
>
> -
> Failed Tests:
> -
> No tests ran.
>
>
> ___
> 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] Why do we need ovirt-engine-sdk-python on a host?

[Simone Tiraboschi]

On Mon, Feb 26, 2018 at 11:48 AM, Yaniv Kaul  wrote:

> Installed hosted-engine on a host, and was surprised to find out
> ovirt-engine-sdk-python.
> Trying to remove it ends up in several deps that I don't understand:
> cockpit-ovirt-dashboard
> ovirt-engine-appliance
> ovirt-host
> ovirt-hosted-engine-setup
>
> Is any of them using (still?) the v3 Python API?
>

The vintage hosted-engine otopi flow is still requiring v3 python SDK to
add the host to the engine.


>
> TIA,
> Y.
>
> ___
> 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] oVirt 4.2.0 GA status

[Simone Tiraboschi]

On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina  wrote:

> As Irit mentioned the provided reproduction steps are wrong (misuse of the
> code) and she posted correct example showing that jsonrpc code works as
> expected. So Martin/Simone are you using somewhere in HE code the original
> example that is misusing the client?
>

According to
https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9
It works in Irit example, at least on that host with that load and timings,
setting nr_retries=2 and _timeout=20

While we have _timeout=5 and no custom nr_retries
https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/lib/util.py#L417

So I think that we still have to fix it somehow.
Are we really sure that nr_retries=2 and _timeout=20 are really the magic
numbers that works on every conditions?


>
> Thanks
>
> Martin
>
>
> On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali 
> wrote:
>
>> From the latest comment it doesn't seem like a blocker to me.
>> Martin S. - your thoughts?
>>
>> On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola 
>> wrote:
>>
>>> We have a proposed blocker for the release:
>>> 1527155  Infra vdsm
>>> Bindings-API igoih...@redhat.com NEW jsonrpc reconnect logic does not
>>> work and gets stuck
>>>  urgent unspecified
>>> ovirt-4.2.0 04:30:30
>>>
>>> Please review and either approve the blcoker or postpone to 4.2.1.
>>> Thanks,
>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>>>
>>> Red Hat EMEA 
>>> 
>>> TRIED. TESTED. TRUSTED. 
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 RC3 status

[Simone Tiraboschi]

On Mon, Dec 18, 2017 at 3:18 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Mon, Dec 18, 2017 at 3:09 PM, Dan Kenigsberg <dan...@redhat.com> wrote:
>
>>
>>
>> On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital <mavi...@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 <mavi...@redhat.com>
>>> wrote:
>>>
>>>> Adding Ying to get her status
>>>>
>>>> On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital <mavi...@redhat.com>
>>>> wrote:
>>>>
>>>>> *Update:*
>>>>> Deployment with iSCSI succeed
>>>>>
>>>>> On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital <mavi...@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 <dan...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola <
>>>>>>> sbona...@redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-12-18 8:37 GMT+01:00 Sandro Bonazzola <sbona...@redhat.com>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg <dan...@redhat.com>:
>>>>>>>>>
>>>>>>>>>> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola <
>>>>>>>>>> sbona...@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 dan...@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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 RC3 status

[Simone Tiraboschi]

On Mon, Dec 18, 2017 at 3:09 PM, Dan Kenigsberg  wrote:

>
>
> On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital  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*
>>  - VDSM is in
>> recovery mode after a restart in fresh installation.
>> He also found another bug - *Bug 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 
>> wrote:
>>
>>> Adding Ying to get her status
>>>
>>> On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital 
>>> wrote:
>>>
 *Update:*
 Deployment with iSCSI succeed

 On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital 
 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 
> wrote:
>
>>
>>
>> On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola <
>> sbona...@redhat.com> wrote:
>>
>>>
>>>
>>> 2017-12-18 8:37 GMT+01:00 Sandro Bonazzola :
>>>


 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg :

> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola <
> sbona...@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 
>> Storage vdsm General dan...@redhat.com NEW VDSM is in recovery
>> mode after a restart in fresh install...
>>  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.
>>
>>
>

>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] 4.2.0 RC3 blockers status: no go

[Simone Tiraboschi]

On Fri, Dec 15, 2017 at 10:04 AM, Martin Sivak  wrote:

> On Fri, Dec 15, 2017 at 7:21 AM, Sandro Bonazzola 
> wrote:
>
>> 1522641  Node
>> cockpit-ovirt Hosted Engine phbai...@redhat.com ASSIGNED Hosted Engine
>> deployment looks like stuck, but become up ...
>>  urgent unspecified
>> ovirt-4.2.0 23:01:07
>>
>
> I believe this is just a manifestation of couple of other bugs and not a
> bug by itself. Well at least it wasn't.. the report contains too many
> different bits of info now. I added the depends on bugs there, all are
> fixed or are waiting for merge and then this needs to be retested.
>

I think we found the root cause, we are going to push a patch to
cockpit-ovirt soon.


>
> Martin
>
>
>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>>
>> Red Hat EMEA 
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>>
>> ___
>> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ANN] oVirt 4.2.0 Second Candidate Release is now available for testing

[Simone Tiraboschi]

On Wed, Dec 13, 2017 at 11:40 AM, Sandro Bonazzola 
wrote:

>
>
> 2017-12-13 11:37 GMT+01:00 Michal Skrivanek :
>
>>
>> > On 13 Dec 2017, at 09:58, Sandro Bonazzola  wrote:
>> >
>> >
>> >
>> > 2017-12-13 9:51 GMT+01:00 Michal Skrivanek > >:
>> > Hi Sandro,
>> > we’ve identified one more blocker for HE installations[1]. We plan
>> getting it in today if everything goes well, would be great if we can
>> update the RC with new vdsm soon after.
>> >
>> > Thanks,
>> > michal
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1524119
>> >
>> > We have right now 3 blockers:
>> > ID▲   oVirt Team  Product▲Component▲  Assignee
>> Status▼ Summary SeverityPriority▲
>> > 1522641   Nodecockpit-ovirt   Hosted Engine
>> phbai...@redhat.com NEW Hosted Engine deployment failed, there
>> display 'Timed out...urgent  unspecified
>>
>> seems this still requires clarification. There is some misunderstanding
>> between the assignee and qe.
>>
>
On my opinion it's just a duplicate of
  https://bugzilla.redhat.com/show_bug.cgi?id=1512534
and today Nikolai got it again on RHEL with everything at latest version.
It's not 100% reproducible being a time based issue.


>
>> > 1525353   Network ovirt-engineBLL.Network era...@redhat.com
>>  NEW vNIC mapping is broken on import from data domain - vNICs...
>>   urgent  urgent
>>
>> Dan, can you update why this is a urgent/urgent  blocker? It doesn’t seem
>> to qualify for that severity. Import VM from SD and end up with empty
>> mapping you can easily fix…that hardly critically affects running workloads.
>>
>
> VDSM build is ready and added to ovirt-4.2-pre repo.
> Pending decision on cockpit-ovirt and ovirt-engine for going ahead with
> the release.
>
>
>
>
>
>>
>> > 1524119   VirtvdsmGeneral from...@redhat.com  POST
>> Failed to migrate HE VM urgent  urgent
>> >
>> >
>> > Looks like we'll need a RC3.
>> >
>> >
>> >
>> >
>> >> On 12 Dec 2017, at 16:45, Sandro Bonazzola 
>> wrote:
>> >>
>> >> The oVirt Project is pleased to announce the availability of the
>> Second Candidate Release of oVirt 4.2.0, as of December 12th, 2017
>> >>
>> >> This is pre-release software. This pre-release should not to be used
>> in production.
>> >> Please take a look at our community page[1] to learn how to ask
>> questions and interact with developers and users.
>> >> All issues or bugs should be reported via oVirt Bugzilla[2].
>> >>
>> >> This update is the second candidate release of the 4.2.0 version. This
>> release brings more than 280 enhancements and more than one thousand bug
>> fixes, including more than 500 high or urgent severity fixes, on top of
>> oVirt 4.1 series.
>> >>
>> >> What's new in oVirt 4.2.0?
>> >>
>> >>  • The Administration Portal has been completely redesigned using
>> Patternfly, a widely adopted standard in web application design. It now
>> features a cleaner, more intuitive design, for an improved user experience.
>> >>  • There is an all-new VM Portal for non-admin users.
>> >>  • A new High Performance virtual machine type has been added to
>> the New VM dialog box in the Administration Portal.
>> >>  • Open Virtual Network (OVN) adds support for Open vSwitch
>> software defined networking (SDN).
>> >>  • oVirt now supports Nvidia vGPU.
>> >>  • The ovirt-ansible-roles package helps users with common
>> administration tasks.
>> >>  • Virt-v2v now supports Debian/Ubuntu based VMs.
>> >>
>> >> For more information about these and other features, check out the
>> oVirt 4.2.0 blog post.
>> >>
>> >> This release is available now on x86_64 architecture for:
>> >> * Red Hat Enterprise Linux 7.4 or later
>> >> * CentOS Linux (or similar) 7.4 or later
>> >>
>> >> This release supports Hypervisor Hosts on x86_64 and ppc64le
>> architectures for:
>> >> * Red Hat Enterprise Linux 7.4 or later
>> >> * CentOS Linux (or similar) 7.4 or later
>> >> * oVirt Node 4.2 (available for x86_64 only)
>> >>
>> >> See the release notes draft [3] for installation / upgrade
>> instructions and a list of new features and bugs fixed.
>> >>
>> >> Notes:
>> >> - oVirt Appliance is already available.
>> >> - oVirt Node is already available [4]
>> >>
>> >> Additional Resources:
>> >> * Read more about the oVirt 4.2.0 release highlights:
>> http://www.ovirt.org/release/4.2.0/
>> >> * Get more oVirt project updates on Twitter: https://twitter.com/ovirt
>> >> * Check out the latest project news on the oVirt blog:
>> http://www.ovirt.org/blog/
>> >>
>> >> [1] https://www.ovirt.org/community/
>> >> [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt
>> >> [3] http://www.ovirt.org/release/4.2.0/
>> >> [4] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/
>> >>
>> >> --
>> >> SANDRO BONAZZOLA
>> >> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>> 

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Simone Tiraboschi]

I think that this one should be considered a blocker as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1518887 - ovirt-ha-agent fails
parsing the OVF_STORE



On Wed, Nov 29, 2017 at 2:20 PM, Ala Hino  wrote:

> Fix verified by the automation and will be merged soon.
>
> On Tue, Nov 28, 2017 at 6:35 PM, Ala Hino  wrote:
>
>> Issue analyzed and fix verified by the automation test case.
>> Now, running all merge related automation test cases to make sure no
>> regression/new issues introduced.
>> Patch in gerrit: https://gerrit.ovirt.org/#/c/84821/
>>
>> On Tue, Nov 28, 2017 at 4:20 PM, Ala Hino  wrote:
>>
>>> 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
>>> remove all volumes
>>> This one only seen in automation and I am not able to reproduce it
>>> locally.
>>>
>>>
>>> On Tue, Nov 28, 2017 at 12:58 PM, Sandro Bonazzola 
>>> wrote:
>>>
 Hi,
 I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
 Assignee are in the TO list of this email.
 So far we are down to 7 bugs: https://bugzilla.redhat.
 com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_miles
 tone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost

 Please review them and provide an ETA for the fix. If the bug is marked
 as blocker by mistake, please remove the blocker flag and / or postpone the
 bug to a later release.

 Bug ID Product Assignee Status Summary
 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
 failed with the default CPU type
 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
 remove all volumes
 1507277 ovirt-engine era...@redhat.com POST [RFE][DR] - Vnic Profiles
 mapping in VMs register from data storage domain should be supported also
 for templates
 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when
 attaching a disk with cow format on glusterfs
 1488338 ovirt-engine mlipc...@redhat.com NEW SPM host is not moving to
 Non-Operational status when blocking its access to storage domain.
 1512534 ovirt-hosted-engine-ha pklic...@redhat.com ASSIGNED SHE
 deployment takes too much time and looks like stuck.
 1496719 vdsm edwa...@redhat.com POST Port mirroring is not set after
 VM migration

 --

 SANDRO BONAZZOLA

 ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

 Red Hat EMEA 
 
 TRIED. TESTED. TRUSTED. 
 

>>>
>>>
>>
>
> ___
> 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] Ansible Help Requested

[Simone Tiraboschi]

On Mon, Oct 2, 2017 at 2:40 PM, Phillip Bailey  wrote:

> Yaniv,
>
> The goal with the storage requirement is to verify connectivity of the
> storage information provided by the user, as the input is being gathered
> prior to running the setup process. The intent is to be able to provide
> warnings to the user during the data collection process.
>
> Thanks for the CPU-related information. I was already pulling the CPU
> model from the Ansible setup module. I needed help with verifying that the
> model selected for the HE VM is compatible with the host's model. The link
> you provided had the list available there, which helps tremendously. The
> only issue I can see is that PPC models aren't included in that list.
>

The current hosted-engine-setup is a noarch rpm but currently we don't have
any ppc engine-appliance to be deployed.


>
> -
>
> Artyom,
>
> That project looks awesome and is very helpful. Thank you!
>
> -Phillip Bailey
>
> On Thu, Sep 28, 2017 at 1:37 AM, Artyom Lukianov 
> wrote:
>
>> Our infra team already deploy HE via ansible you can check their work
>> under https://github.com/fusor/ansible-ovirt
>>
>> Best Regards
>>
>> On Wed, Sep 27, 2017 at 6:16 PM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Wed, Sep 27, 2017 at 5:15 PM, Phillip Bailey 
>>> wrote:
>>>
 Hi all,

 I'm working on the new Cockpit hosted engine wizard and could use some
 input from all of you. One goal of this project is to move away from
 reliance on the existing OTOPI-based tools and towards an ansible-based
 approach.

 The items below are things we'd like to do using ansible, if possible.
 If any of you have existing plays or suggestions for the best way to use
 ansible to solve these problems, please let me know.

 Thanks!

1. Verify provided storage settings for all allowable storage types.


>>> I'm not sure I understand the requirement here.
>>>
>>>

1.
2. Verify compatibility of selected CPU type for the engine VM with
the host's CPU


>>> This is easy. See [1] for a simple Python code. In bash:
>>> virsh -r capabilities |grep -m 1 ""
>>>
>>> Y.
>>> [1] https://github.com/lago-project/lago/pull/323/files#diff
>>> -1b557418847a737490a95d4841c6a362R96
>>>
>>> -Phillip Bailey

 ___
 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
>>>
>>
>>
>
> ___
> 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 HE master ] [ 17/09/17 ] [ engine-setup ]

[Simone Tiraboschi]

On Mon, Sep 18, 2017 at 4:33 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Mon, Sep 18, 2017 at 12:09 PM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>
>>
>>
>> On Sun, Sep 17, 2017 at 11:14 AM, Eyal Edri <ee...@redhat.com> wrote:
>>
>>>
>>>
>>> On Sun, Sep 17, 2017 at 11:50 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Sep 17, 2017 at 11:47 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It looks like HE suite ( both 'master' and '4.1' ) is failing
>>>>> constantly, most likely due to 7.4 updates.
>>>>>
>>>>
>> I'm investigating the issue on master.
>> In my case I choose to configure the engine VM with a static IP address
>> and engine-setup failed on the engine VM since it wasn't able to check
>> available OVN related packages.
>>
>> So we have two distinct issues here:
>> 1. we are executing engine-setup with --offline cli option but the OVN
>> plugins are ignoring it.
>>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1492702
> https://bugzilla.redhat.com/show_bug.cgi?id=1492706
>
>
>>
>> 2. the engine VM has no connectivity.
>> I dig it a bit and I found that the default gateway wasn't configured on
>> the engine VM although it's correctly set in cloud-init meta-data file.
>> So it seams that on 7.4 cloud-init is failing to set the default gateway:
>>
>>
> https://bugzilla.redhat.com/show_bug.cgi?id=1492726
>

I pushed a working patch with an ugly hack:
https://gerrit.ovirt.org/#/c/81934/

With that, I was able to successfully deploy hosted-engine on NFS using
Centos 7.4 on the host and on the engine VM.


>
>
>
>> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
>> connection.gateway-ping-timeout:0
>> ipv4.gateway:   --
>> ipv6.gateway:   --
>> IP4.GATEWAY:--
>> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
>> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway
>> Error: value for 'ipv4.gateway' is missing.
>> [root@enginevm ~]#
>> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
>> connection.gateway-ping-timeout:0
>> ipv4.gateway:   --
>> ipv6.gateway:   --
>> IP4.GATEWAY:--
>> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
>> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway
>> 192.168.1.1
>> [root@enginevm ~]# nmcli con reload "System eth0"
>> [root@enginevm ~]# nmcli con up "System eth0"
>> Connection successfully activated (D-Bus active path:
>> /org/freedesktop/NetworkManager/ActiveConnection/3)
>> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
>> connection.gateway-ping-timeout:0
>> ipv4.gateway:   192.168.1.1
>> ipv6.gateway:   --
>> IP4.GATEWAY:192.168.1.1
>> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
>> [root@enginevm ~]# mount /dev/sr0 /mnt/
>> mount: /dev/sr0 is write-protected, mounting read-only
>> [root@enginevm ~]# cat /mnt/meta-data
>> instance-id: d8b22f43-1565-44e2-916f-f211c7e07f13
>> local-hostname: enginevm.localdomain
>> network-interfaces: |
>>   auto eth0
>>   iface eth0 inet static
>> address 192.168.1.204
>> network 192.168.1.0
>> netmask 255.255.255.0
>> broadcast 192.168.1.255
>> gateway 192.168.1.1
>>
>>
>>
>>
>>> So there is no suspected patch from oVirt side that might have caused it.
>>>>>
>>>>
>>>> It's the firewall. I've fixed it[1] and specifically[2] but probably
>>>> not completely.
>>>>
>>>
>>> Great! Wasn't aware your patch address that, I've replied on the patch
>>> itself, but I think we need to split the fix to 2 seperate patches.
>>>
>>>
>>>>
>>>> Perhaps we should try to take[2] separately.
>>>> Y.
>>>>
>>>> [1] https://gerrit.ovirt.org/#/c/81766/
>>>> [2] https://gerrit.ovirt.org/#/c/81766/3/common/deploy-scrip
>>>> ts/setup_storage_unified_he_extra_el7.sh
>>>&

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt HE master ] [ 17/09/17 ] [ engine-setup ]

[Simone Tiraboschi]

On Mon, Sep 18, 2017 at 12:09 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Sun, Sep 17, 2017 at 11:14 AM, Eyal Edri <ee...@redhat.com> wrote:
>
>>
>>
>> On Sun, Sep 17, 2017 at 11:50 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>>
>>>
>>> On Sun, Sep 17, 2017 at 11:47 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like HE suite ( both 'master' and '4.1' ) is failing
>>>> constantly, most likely due to 7.4 updates.
>>>>
>>>
> I'm investigating the issue on master.
> In my case I choose to configure the engine VM with a static IP address
> and engine-setup failed on the engine VM since it wasn't able to check
> available OVN related packages.
>
> So we have two distinct issues here:
> 1. we are executing engine-setup with --offline cli option but the OVN
> plugins are ignoring it.
>

https://bugzilla.redhat.com/show_bug.cgi?id=1492702
https://bugzilla.redhat.com/show_bug.cgi?id=1492706


>
> 2. the engine VM has no connectivity.
> I dig it a bit and I found that the default gateway wasn't configured on
> the engine VM although it's correctly set in cloud-init meta-data file.
> So it seams that on 7.4 cloud-init is failing to set the default gateway:
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1492726


> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   --
> ipv6.gateway:   --
> IP4.GATEWAY:--
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway
> Error: value for 'ipv4.gateway' is missing.
> [root@enginevm ~]#
> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   --
> ipv6.gateway:   --
> IP4.GATEWAY:--
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway 192.168.1.1
> [root@enginevm ~]# nmcli con reload "System eth0"
> [root@enginevm ~]# nmcli con up "System eth0"
> Connection successfully activated (D-Bus active path: /org/freedesktop/
> NetworkManager/ActiveConnection/3)
> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   192.168.1.1
> ipv6.gateway:   --
> IP4.GATEWAY:192.168.1.1
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# mount /dev/sr0 /mnt/
> mount: /dev/sr0 is write-protected, mounting read-only
> [root@enginevm ~]# cat /mnt/meta-data
> instance-id: d8b22f43-1565-44e2-916f-f211c7e07f13
> local-hostname: enginevm.localdomain
> network-interfaces: |
>   auto eth0
>   iface eth0 inet static
> address 192.168.1.204
> network 192.168.1.0
> netmask 255.255.255.0
> broadcast 192.168.1.255
> gateway 192.168.1.1
>
>
>
>
>> So there is no suspected patch from oVirt side that might have caused it.
>>>>
>>>
>>> It's the firewall. I've fixed it[1] and specifically[2] but probably not
>>> completely.
>>>
>>
>> Great! Wasn't aware your patch address that, I've replied on the patch
>> itself, but I think we need to split the fix to 2 seperate patches.
>>
>>
>>>
>>> Perhaps we should try to take[2] separately.
>>> Y.
>>>
>>> [1] https://gerrit.ovirt.org/#/c/81766/
>>> [2] https://gerrit.ovirt.org/#/c/81766/3/common/deploy-scrip
>>> ts/setup_storage_unified_he_extra_el7.sh
>>>
>>>
>>>
>>>
>>>> It is probably also the reason why HC suites are failing, since they
>>>> are using also HE for deployments.
>>>>
>>>> I think this issue should BLOCK the Alpha release tomorrow, or at the
>>>> minimum, we need to verify its an OST issue and not a real regression.
>>>>
>>>> Links to relevant failures:
>>>> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-sui
>>>> te-master/37/consoleFull
>>>> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-sui
>>>> te-4.1/33/console
>>>>
>>>> Error snippet:
>>>>
>>>> 03:01:38
>>>> 03:

Re: [ovirt-devel] Error in running engine-setup

[Simone Tiraboschi]

On Sun, Sep 17, 2017 at 7:32 PM, shubham dubey  wrote:

> Thanks for the solution.
> I will look into that bug.
>
>
We already fixed it,
you should simply update otopi package on your devel system.


> Regards,
> Shubham
>
> On Sun, Sep 17, 2017 at 8:05 PM, Benny Zlotnik 
> wrote:
>
>> It's a known issue [1].
>> A workaround is available in the bug description
>>
>> [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1490977
>>
>> On Sun, Sep 17, 2017 at 5:30 PM, shubham dubey 
>> wrote:
>>
>>> Hi,
>>> I am having a issue in running engine-setup
>>>
>>> [0day@localhost ovirt-engine]$ $HOME/ovirt-engine/bin/engine-setup
>>> [ INFO  ] Stage: Initializing
>>>   Setup was run under unprivileged user this will produce
>>> development installation do you wish to proceed? (Yes, No) [No]: yes
>>> [ INFO  ] Stage: Environment setup
>>>   Configuration files: ['/home/0day/ovirt-engine/etc/
>>> ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
>>>   Log file: /home/0day/ovirt-engine/var/lo
>>> g/ovirt-engine/setup/ovirt-engine-setup-20170917195313-29bb2o.log
>>>   Version: otopi-1.7.1 (otopi-1.7.1-1.el7)
>>> [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to
>>> Engine database using existing credentials: engine@localhost:5432
>>> [ INFO  ] Stage: Clean up
>>>   Log file is located at /home/0day/ovirt-engine/var/lo
>>> g/ovirt-engine/setup/ovirt-engine-setup-20170917195313-29bb2o.log
>>> [ INFO  ] Generating answer file '/home/0day/ovirt-engine/var/l
>>> ib/ovirt-engine/setup/answers/20170917195316-setup.conf'
>>> [ INFO  ] Stage: Pre-termination
>>> [ INFO  ] Stage: Termination
>>> [ ERROR ] Execution of setup failed
>>>
>>> the log file output is here: https://paste.ubuntu.com/25557192/
>>> Can anyone tell me what's going wrong here?
>>>
>>> Thanks,
>>> Shubham
>>>
>>> ___
>>> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt HE master ] [ 17/09/17 ] [ engine-setup ]

[Simone Tiraboschi]

On Mon, Sep 18, 2017 at 12:09 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Sun, Sep 17, 2017 at 11:14 AM, Eyal Edri <ee...@redhat.com> wrote:
>
>>
>>
>> On Sun, Sep 17, 2017 at 11:50 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>>
>>>
>>> On Sun, Sep 17, 2017 at 11:47 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like HE suite ( both 'master' and '4.1' ) is failing
>>>> constantly, most likely due to 7.4 updates.
>>>>
>>>
> I'm investigating the issue on master.
> In my case I choose to configure the engine VM with a static IP address
> and engine-setup failed on the engine VM since it wasn't able to check
> available OVN related packages.
>
> So we have two distinct issues here:
> 1. we are executing engine-setup with --offline cli option but the OVN
> plugins are ignoring it.
>
> 2. the engine VM has no connectivity.
> I dig it a bit and I found that the default gateway wasn't configured on
> the engine VM although it's correctly set in cloud-init meta-data file.
> So it seams that on 7.4 cloud-init is failing to set the default gateway:
>
> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   --
> ipv6.gateway:   --
> IP4.GATEWAY:--
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway
> Error: value for 'ipv4.gateway' is missing.
> [root@enginevm ~]#
> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   --
> ipv6.gateway:   --
> IP4.GATEWAY:--
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway 192.168.1.1
> [root@enginevm ~]# nmcli con reload "System eth0"
> [root@enginevm ~]# nmcli con up "System eth0"
> Connection successfully activated (D-Bus active path: /org/freedesktop/
> NetworkManager/ActiveConnection/3)
> [root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
> connection.gateway-ping-timeout:0
> ipv4.gateway:   192.168.1.1
> ipv6.gateway:   --
> IP4.GATEWAY:192.168.1.1
> IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
> [root@enginevm ~]# mount /dev/sr0 /mnt/
> mount: /dev/sr0 is write-protected, mounting read-only
> [root@enginevm ~]# cat /mnt/meta-data
> instance-id: d8b22f43-1565-44e2-916f-f211c7e07f13
> local-hostname: enginevm.localdomain
> network-interfaces: |
>   auto eth0
>   iface eth0 inet static
> address 192.168.1.204
> network 192.168.1.0
> netmask 255.255.255.0
> broadcast 192.168.1.255
> gateway 192.168.1.1
>
>
An upstream user was also reporting that he updated his host and his engine
VM to Centos 7.4 and it failed to reboot the engine VM with 7.4 kernel
hanging at
"Probing EDD (edd=off to disable)...ok". He manually forced the old 7.3
kernel via grub menu and his engine VM correctly booted.
I wasn't able to reproduce it here.


>
>
>
>> So there is no suspected patch from oVirt side that might have caused it.
>>>>
>>>
>>> It's the firewall. I've fixed it[1] and specifically[2] but probably not
>>> completely.
>>>
>>
>> Great! Wasn't aware your patch address that, I've replied on the patch
>> itself, but I think we need to split the fix to 2 seperate patches.
>>
>>
>>>
>>> Perhaps we should try to take[2] separately.
>>> Y.
>>>
>>> [1] https://gerrit.ovirt.org/#/c/81766/
>>> [2] https://gerrit.ovirt.org/#/c/81766/3/common/deploy-scrip
>>> ts/setup_storage_unified_he_extra_el7.sh
>>>
>>>
>>>
>>>
>>>> It is probably also the reason why HC suites are failing, since they
>>>> are using also HE for deployments.
>>>>
>>>> I think this issue should BLOCK the Alpha release tomorrow, or at the
>>>> minimum, we need to verify its an OST issue and not a real regression.
>>>>
>>>> Links to relevant failures:
>>>> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-sui
>>>> te-master/37/consoleFull
>>>> http://jenkins.ovirt.org/job/ovirt-system-te

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt HE master ] [ 17/09/17 ] [ engine-setup ]

[Simone Tiraboschi]

On Sun, Sep 17, 2017 at 11:14 AM, Eyal Edri  wrote:

>
>
> On Sun, Sep 17, 2017 at 11:50 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Sun, Sep 17, 2017 at 11:47 AM, Eyal Edri  wrote:
>>
>>> Hi,
>>>
>>> It looks like HE suite ( both 'master' and '4.1' ) is failing
>>> constantly, most likely due to 7.4 updates.
>>>
>>
I'm investigating the issue on master.
In my case I choose to configure the engine VM with a static IP address and
engine-setup failed on the engine VM since it wasn't able to check
available OVN related packages.

So we have two distinct issues here:
1. we are executing engine-setup with --offline cli option but the OVN
plugins are ignoring it.

2. the engine VM has no connectivity.
I dig it a bit and I found that the default gateway wasn't configured on
the engine VM although it's correctly set in cloud-init meta-data file.
So it seams that on 7.4 cloud-init is failing to set the default gateway:

[root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
connection.gateway-ping-timeout:0
ipv4.gateway:   --
ipv6.gateway:   --
IP4.GATEWAY:--
IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
[root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway
Error: value for 'ipv4.gateway' is missing.
[root@enginevm ~]#
[root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
connection.gateway-ping-timeout:0
ipv4.gateway:   --
ipv6.gateway:   --
IP4.GATEWAY:--
IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
[root@enginevm ~]# nmcli con modify "System eth0" ipv4.gateway 192.168.1.1
[root@enginevm ~]# nmcli con reload "System eth0"
[root@enginevm ~]# nmcli con up "System eth0"
Connection successfully activated (D-Bus active path:
/org/freedesktop/NetworkManager/ActiveConnection/3)
[root@enginevm ~]# nmcli con show "System eth0" | grep -i GATEWAY
connection.gateway-ping-timeout:0
ipv4.gateway:   192.168.1.1
ipv6.gateway:   --
IP4.GATEWAY:192.168.1.1
IP6.GATEWAY:fe80::c4ee:3eff:fed5:fad9
[root@enginevm ~]# mount /dev/sr0 /mnt/
mount: /dev/sr0 is write-protected, mounting read-only
[root@enginevm ~]# cat /mnt/meta-data
instance-id: d8b22f43-1565-44e2-916f-f211c7e07f13
local-hostname: enginevm.localdomain
network-interfaces: |
  auto eth0
  iface eth0 inet static
address 192.168.1.204
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1




> So there is no suspected patch from oVirt side that might have caused it.
>>>
>>
>> It's the firewall. I've fixed it[1] and specifically[2] but probably not
>> completely.
>>
>
> Great! Wasn't aware your patch address that, I've replied on the patch
> itself, but I think we need to split the fix to 2 seperate patches.
>
>
>>
>> Perhaps we should try to take[2] separately.
>> Y.
>>
>> [1] https://gerrit.ovirt.org/#/c/81766/
>> [2] https://gerrit.ovirt.org/#/c/81766/3/common/deploy-scrip
>> ts/setup_storage_unified_he_extra_el7.sh
>>
>>
>>
>>
>>> It is probably also the reason why HC suites are failing, since they are
>>> using also HE for deployments.
>>>
>>> I think this issue should BLOCK the Alpha release tomorrow, or at the
>>> minimum, we need to verify its an OST issue and not a real regression.
>>>
>>> Links to relevant failures:
>>> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-sui
>>> te-master/37/consoleFull
>>> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-sui
>>> te-4.1/33/console
>>>
>>> Error snippet:
>>>
>>> 03:01:38
>>> 03:01:38   --== STORAGE CONFIGURATION ==--
>>> 03:01:38
>>> 03:02:47 [ ERROR ] Error while mounting specified storage path:
>>> mount.nfs: No route to host
>>> 03:02:58 [WARNING] Cannot unmount /tmp/tmp2gkFwJ
>>> 03:02:58 [ ERROR ] Failed to execute stage 'Environment customization':
>>> mount.nfs: No route to host
>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>>
>>> ASSOCIATE MANAGER
>>>
>>> RHV DevOps
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>>
>>> Red Hat EMEA 
>>>  TRIED. TESTED. TRUSTED.
>>> 
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org

Re: [ovirt-devel] [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to Engine database using existing credentials: engine@localhost:5432

[Simone Tiraboschi]

Il 12 Set 2017 18:34, "Jakub Niedermertl" <jnied...@redhat.com> ha scritto:

Since the problem is still present on current master, I've created a bug
[1] to track that.

[1]: https://bugzilla.redhat.com/1490977


This afternoon we merged a couple of patches to otopi to honour system path
so it should be fine now.
Please update otopi rpm on your system.




On Fri, Sep 8, 2017 at 5:17 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Fri, Sep 8, 2017 at 4:43 PM, Scott Dickerson <sdick...@redhat.com>
> wrote:
>
>>
>>
>> On Fri, Sep 8, 2017 at 9:50 AM, Simone Tiraboschi <stira...@redhat.com>
>> wrote:
>>
>>> We are now requiring Postgres 9.5 which means that you have to use SCL
>>> on el7 but on fedora 25 you already have Postgres 9.5.8 at system level so
>>> no changes are required there.
>>>
>>> I personally tried on fedora 25 and I didn't found any issue using the
>>> rpms published in ovirt-master-snapshot and dev-env from master branch of
>>> our gerrit repo.
>>>
>>> Can you please simply try with a make clean before make install-dev to
>>> ensure that you don't have any left over from previous build attempt?
>>>
>>>
>> I dropped and recreated my DBs in postgres and maually removed my
>> ~/ovirt-engine dev compile location.  The very first run of
>> '~/ovirt-engine/bin/engine-setup' works fine.  Any subsequent run fails
>> as Greg originally posted.  All of the credentials and settings line up
>> ok.  Again, it's the 2nd run of engine-setup that fails.
>>
>
> OK, the breaking leftover is 
> etc/ovirt-engine/engine.conf.d/10-setup-database.conf
> under your dev-env prefix. Removing it will fix engine-setup.
>
> Now let's try to fix it.
>
>
>
>>
>>
>>> On Fri, Sep 8, 2017 at 3:18 PM, Greg Sheremeta <gsher...@redhat.com>
>>> wrote:
>>>
>>>> Same here.
>>>>
>>>> Miroslava mentioned manual steps, but I only saw steps for SCL. Looks
>>>> like all of us on Fedora are broken (?!), and I don't see steps to fix in
>>>> the README (or, even better, emailed out with an [ACTION REQUIRED] subject
>>>> line]
>>>>
>>>> Greg
>>>>
>>>>
>>>> On Fri, Sep 8, 2017 at 9:14 AM, Jakub Niedermertl <jnied...@redhat.com>
>>>> wrote:
>>>>
>>>>> It still doesn't work on commit 76ec627d23 containing earlier
>>>>> mentioned patch https://gerrit.ovirt.org/#/c/81536/ and Fedora 26.
>>>>>
>>>>> My pg_hba.conf: https://paste.fedoraproject.or
>>>>> g/paste/PAkTprADCbUCOKyqgRXiMQ
>>>>>
>>>>> rpm -qa postgres*
>>>>> postgresql-server-9.6.4-1.fc26.x86_64
>>>>> postgresql-9.6.4-1.fc26.x86_64
>>>>> postgresql-libs-9.6.4-1.fc26.x86_64
>>>>>
>>>>>
>>>>> On Fri, Sep 8, 2017 at 3:01 PM, Alexander Wels <aw...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Thursday, September 7, 2017 10:14:16 AM EDT Simone Tiraboschi
>>>>>> wrote:
>>>>>> > On Thu, Sep 7, 2017 at 3:59 PM, Miroslava Voglova <
>>>>>> mvogl...@redhat.com>
>>>>>> >
>>>>>> > wrote:
>>>>>> > > It's because upgrade to Postgres 9.5. There is patch that edit
>>>>>> README with
>>>>>> > > more instructions how to proceed [1].
>>>>>> > >
>>>>>> > > [1] https://gerrit.ovirt.org/#/c/81536/
>>>>>> >
>>>>>> > I'm trying to improve that patch to have it handled almost fully
>>>>>> > automatically by make install-dev
>>>>>> >
>>>>>>
>>>>>> Can you hurry up, my environment is basically dead in the water right
>>>>>> now
>>>>>> because I run F25 and there are no instructions on how to make this
>>>>>> work. Even
>>>>>> reverting the patch won't allow me to run engine-setup.
>>>>>>
>>>>>> > > On Thu, Sep 7, 2017 at 3:12 PM, Greg Sheremeta <
>>>>>> gsher...@redhat.com>
>>>>>> > >
>>>>>> > > wrote:
>>>>>> > >> Just in case it helps:
>>>>>> > >> greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) %
>>>>>> noglob

Re: [ovirt-devel] Announcing Yuval Turgeman as oVirt Node co-maintainer

[Simone Tiraboschi]

+1, well deserved!

On Mon, Sep 11, 2017 at 9:32 AM, Sandro Bonazzola 
wrote:

> Hi,
> Yuval Turgeman took a major role in the oVirt Node project and solved many
> non trivial issues[1] demonstrating a very good knowledge of the codebase
> and of the product.
> Yuval has already co-maintainer permissions on oVirt Node.
> I'd like to thank Yuval for his contribution and I hope he'll keep up the
> good work!
>
> [1] https://bugzilla.redhat.com/buglist.cgi?quicksearch=
> product%3Aovirt-node%20assignee%3Ayturge%20status%
> 3Amodified%2Con_qa%2Cverified%2Cclosed
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
> ___
> 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] [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to Engine database using existing credentials: engine@localhost:5432

[Simone Tiraboschi]

On Fri, Sep 8, 2017 at 4:43 PM, Scott Dickerson <sdick...@redhat.com> wrote:

>
>
> On Fri, Sep 8, 2017 at 9:50 AM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>
>> We are now requiring Postgres 9.5 which means that you have to use SCL on
>> el7 but on fedora 25 you already have Postgres 9.5.8 at system level so no
>> changes are required there.
>>
>> I personally tried on fedora 25 and I didn't found any issue using the
>> rpms published in ovirt-master-snapshot and dev-env from master branch of
>> our gerrit repo.
>>
>> Can you please simply try with a make clean before make install-dev to
>> ensure that you don't have any left over from previous build attempt?
>>
>>
> I dropped and recreated my DBs in postgres and maually removed my
> ~/ovirt-engine dev compile location.  The very first run of
> '~/ovirt-engine/bin/engine-setup' works fine.  Any subsequent run fails
> as Greg originally posted.  All of the credentials and settings line up
> ok.  Again, it's the 2nd run of engine-setup that fails.
>

OK, the breaking leftover is
etc/ovirt-engine/engine.conf.d/10-setup-database.conf under your dev-env
prefix. Removing it will fix engine-setup.

Now let's try to fix it.


>
>
>> On Fri, Sep 8, 2017 at 3:18 PM, Greg Sheremeta <gsher...@redhat.com>
>> wrote:
>>
>>> Same here.
>>>
>>> Miroslava mentioned manual steps, but I only saw steps for SCL. Looks
>>> like all of us on Fedora are broken (?!), and I don't see steps to fix in
>>> the README (or, even better, emailed out with an [ACTION REQUIRED] subject
>>> line]
>>>
>>> Greg
>>>
>>>
>>> On Fri, Sep 8, 2017 at 9:14 AM, Jakub Niedermertl <jnied...@redhat.com>
>>> wrote:
>>>
>>>> It still doesn't work on commit 76ec627d23 containing earlier mentioned
>>>> patch https://gerrit.ovirt.org/#/c/81536/ and Fedora 26.
>>>>
>>>> My pg_hba.conf: https://paste.fedoraproject.or
>>>> g/paste/PAkTprADCbUCOKyqgRXiMQ
>>>>
>>>> rpm -qa postgres*
>>>> postgresql-server-9.6.4-1.fc26.x86_64
>>>> postgresql-9.6.4-1.fc26.x86_64
>>>> postgresql-libs-9.6.4-1.fc26.x86_64
>>>>
>>>>
>>>> On Fri, Sep 8, 2017 at 3:01 PM, Alexander Wels <aw...@redhat.com>
>>>> wrote:
>>>>
>>>>> On Thursday, September 7, 2017 10:14:16 AM EDT Simone Tiraboschi wrote:
>>>>> > On Thu, Sep 7, 2017 at 3:59 PM, Miroslava Voglova <
>>>>> mvogl...@redhat.com>
>>>>> >
>>>>> > wrote:
>>>>> > > It's because upgrade to Postgres 9.5. There is patch that edit
>>>>> README with
>>>>> > > more instructions how to proceed [1].
>>>>> > >
>>>>> > > [1] https://gerrit.ovirt.org/#/c/81536/
>>>>> >
>>>>> > I'm trying to improve that patch to have it handled almost fully
>>>>> > automatically by make install-dev
>>>>> >
>>>>>
>>>>> Can you hurry up, my environment is basically dead in the water right
>>>>> now
>>>>> because I run F25 and there are no instructions on how to make this
>>>>> work. Even
>>>>> reverting the patch won't allow me to run engine-setup.
>>>>>
>>>>> > > On Thu, Sep 7, 2017 at 3:12 PM, Greg Sheremeta <
>>>>> gsher...@redhat.com>
>>>>> > >
>>>>> > > wrote:
>>>>> > >> Just in case it helps:
>>>>> > >> greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) %
>>>>> noglob rpm
>>>>> > >> -qa postgres*
>>>>> > >> postgresql-server-9.6.3-1.fc26.x86_64
>>>>> > >> postgresql-9.6.3-1.fc26.x86_64
>>>>> > >> postgresql-libs-9.6.3-1.fc26.x86_64
>>>>> > >>
>>>>> > >>
>>>>> > >> On Thu, Sep 7, 2017 at 9:10 AM, Jakub Niedermertl <
>>>>> jnied...@redhat.com>
>>>>> > >>
>>>>> > >> wrote:
>>>>> > >>> I have the same issue.
>>>>> > >>>
>>>>> > >>> On Thu, Sep 7, 2017 at 2:40 PM, Greg Sheremeta <
>>>>> gsher...@redhat.com>
>>>>> > >>>
>>>>> > >>> wrote:
>>>>>

Re: [ovirt-devel] [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to Engine database using existing credentials: engine@localhost:5432

[Simone Tiraboschi]

We are now requiring Postgres 9.5 which means that you have to use SCL on
el7 but on fedora 25 you already have Postgres 9.5.8 at system level so no
changes are required there.

I personally tried on fedora 25 and I didn't found any issue using the rpms
published in ovirt-master-snapshot and dev-env from master branch of our
gerrit repo.

Can you please simply try with a make clean before make install-dev to
ensure that you don't have any left over from previous build attempt?

On Fri, Sep 8, 2017 at 3:18 PM, Greg Sheremeta <gsher...@redhat.com> wrote:

> Same here.
>
> Miroslava mentioned manual steps, but I only saw steps for SCL. Looks like
> all of us on Fedora are broken (?!), and I don't see steps to fix in the
> README (or, even better, emailed out with an [ACTION REQUIRED] subject line]
>
> Greg
>
>
> On Fri, Sep 8, 2017 at 9:14 AM, Jakub Niedermertl <jnied...@redhat.com>
> wrote:
>
>> It still doesn't work on commit 76ec627d23 containing earlier mentioned
>> patch https://gerrit.ovirt.org/#/c/81536/ and Fedora 26.
>>
>> My pg_hba.conf: https://paste.fedoraproject.or
>> g/paste/PAkTprADCbUCOKyqgRXiMQ
>>
>> rpm -qa postgres*
>> postgresql-server-9.6.4-1.fc26.x86_64
>> postgresql-9.6.4-1.fc26.x86_64
>> postgresql-libs-9.6.4-1.fc26.x86_64
>>
>>
>> On Fri, Sep 8, 2017 at 3:01 PM, Alexander Wels <aw...@redhat.com> wrote:
>>
>>> On Thursday, September 7, 2017 10:14:16 AM EDT Simone Tiraboschi wrote:
>>> > On Thu, Sep 7, 2017 at 3:59 PM, Miroslava Voglova <mvogl...@redhat.com
>>> >
>>> >
>>> > wrote:
>>> > > It's because upgrade to Postgres 9.5. There is patch that edit
>>> README with
>>> > > more instructions how to proceed [1].
>>> > >
>>> > > [1] https://gerrit.ovirt.org/#/c/81536/
>>> >
>>> > I'm trying to improve that patch to have it handled almost fully
>>> > automatically by make install-dev
>>> >
>>>
>>> Can you hurry up, my environment is basically dead in the water right now
>>> because I run F25 and there are no instructions on how to make this
>>> work. Even
>>> reverting the patch won't allow me to run engine-setup.
>>>
>>> > > On Thu, Sep 7, 2017 at 3:12 PM, Greg Sheremeta <gsher...@redhat.com>
>>> > >
>>> > > wrote:
>>> > >> Just in case it helps:
>>> > >> greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) %
>>> noglob rpm
>>> > >> -qa postgres*
>>> > >> postgresql-server-9.6.3-1.fc26.x86_64
>>> > >> postgresql-9.6.3-1.fc26.x86_64
>>> > >> postgresql-libs-9.6.3-1.fc26.x86_64
>>> > >>
>>> > >>
>>> > >> On Thu, Sep 7, 2017 at 9:10 AM, Jakub Niedermertl <
>>> jnied...@redhat.com>
>>> > >>
>>> > >> wrote:
>>> > >>> I have the same issue.
>>> > >>>
>>> > >>> On Thu, Sep 7, 2017 at 2:40 PM, Greg Sheremeta <
>>> gsher...@redhat.com>
>>> > >>>
>>> > >>> wrote:
>>> > >>>> I just rebased and engine wouldn't serve the UI (404) although it
>>> > >>>> looked like it started. I tried to run engine setup, and getting:
>>> > >>>>
>>> > >>>> greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) %
>>> > >>>> ovirt_engine_setup
>>> > >>>> [ INFO  ] Stage: Initializing
>>> > >>>>
>>> > >>>>   Setup was run under unprivileged user this will produce
>>> > >>>>
>>> > >>>> development installation do you wish to proceed? (Yes, No) [No]:
>>> yes
>>> > >>>> [ INFO  ] Stage: Environment setup
>>> > >>>>
>>> > >>>>   Configuration files: ['/home/greg/ovirt-engine/etc/
>>> > >>>>
>>> > >>>> ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
>>> > >>>>
>>> > >>>>   Log file: /home/greg/ovirt-engine/var/lo
>>> > >>>>
>>> > >>>> g/ovirt-engine/setup/ovirt-engine-setup-20170907083125-5vnlyd.log
>>> > >>>>
>>> > >>>>   Version: otopi-1.7.2_master
>>> (otopi-1.7.2-0.0.master.201707
>>> > >>>>

Re: [ovirt-devel] [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to Engine database using existing credentials: engine@localhost:5432

[Simone Tiraboschi]

On Thu, Sep 7, 2017 at 3:59 PM, Miroslava Voglova 
wrote:

> It's because upgrade to Postgres 9.5. There is patch that edit README with
> more instructions how to proceed [1].
>
> [1] https://gerrit.ovirt.org/#/c/81536/
>

I'm trying to improve that patch to have it handled almost fully
automatically by make install-dev


>
>
> On Thu, Sep 7, 2017 at 3:12 PM, Greg Sheremeta 
> wrote:
>
>> Just in case it helps:
>> greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) % noglob rpm
>> -qa postgres*
>> postgresql-server-9.6.3-1.fc26.x86_64
>> postgresql-9.6.3-1.fc26.x86_64
>> postgresql-libs-9.6.3-1.fc26.x86_64
>>
>>
>> On Thu, Sep 7, 2017 at 9:10 AM, Jakub Niedermertl 
>> wrote:
>>
>>> I have the same issue.
>>>
>>> On Thu, Sep 7, 2017 at 2:40 PM, Greg Sheremeta 
>>> wrote:
>>>
 I just rebased and engine wouldn't serve the UI (404) although it
 looked like it started. I tried to run engine setup, and getting:

 greg@dauntless:/home/greg/projects/ovirt-engine(master↑1|✔) %
 ovirt_engine_setup
 [ INFO  ] Stage: Initializing
   Setup was run under unprivileged user this will produce
 development installation do you wish to proceed? (Yes, No) [No]: yes
 [ INFO  ] Stage: Environment setup
   Configuration files: ['/home/greg/ovirt-engine/etc/
 ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
   Log file: /home/greg/ovirt-engine/var/lo
 g/ovirt-engine/setup/ovirt-engine-setup-20170907083125-5vnlyd.log
   Version: otopi-1.7.2_master (otopi-1.7.2-0.0.master.201707
 25101901.git770a428.fc25)
 [ ERROR ] Failed to execute stage 'Environment setup': Cannot connect
 to Engine database using existing credentials: engine@localhost:5432
 [ INFO  ] Stage: Clean up
   Log file is located at /home/greg/ovirt-engine/var/lo
 g/ovirt-engine/setup/ovirt-engine-setup-20170907083125-5vnlyd.log
 [ INFO  ] Generating answer file '/home/greg/ovirt-engine/var/l
 ib/ovirt-engine/setup/answers/20170907083128-setup.conf'
 [ INFO  ] Stage: Pre-termination
 [ INFO  ] Stage: Termination
 [ ERROR ] Execution of setup failed


 Anyone else seen this or know a fix?

 Best wishes,
 Greg


 --

 GREG SHEREMETA

 SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

 Red Hat

 

 gsher...@redhat.comIRC: gshereme
 

 ___
 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
>>
>
>
> ___
> 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 master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Wed, Sep 6, 2017 at 10:35 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 6 September 2017 at 11:11, Simone Tiraboschi <stira...@redhat.com>
> wrote:
> >
> > if you have both yesterday patches it was going to fail due to the lack
> of
> > rh-postgresql95-postgresql-server
> >
> > https://gerrit.ovirt.org/#/c/81478/ should be enough to require
> > rh-postgresql95-postgresql-server by itself,
> > so if DWH is part of the upgrade test, I hope it will pass.
>
> It passed:
> http://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-
> master_change-queue-tester/detail/ovirt-master_change-
> queue-tester/2347/pipeline


Thanks, nice to hear!


>
>
> Currently uploading updated packages to 'tested'.
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Wed, Sep 6, 2017 at 10:03 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 6 September 2017 at 10:58, Simone Tiraboschi <stira...@redhat.com>
> wrote:
> >
> >
> > We already found an rpm dependency issue on upgrade so now I'd say:
> > https://gerrit.ovirt.org/81478 and https://gerrit.ovirt.org/81476
> (still to
> > be merged) in order to solve also that issue.
> >
> Hmm... I thought the upgrade issue was what we were discussing.
>
> I triggered a CQ run with the latest merged engine and dwh patches. If
> I understand correctly it is doomed to fail as well?
>

Yes, two distinct issue:

if you don't test the two previous patch at the same time it's going to
fail with

engine-setup --config-append=/tmp/answer-file-post --accept-defaults
returned with 2
output:
 ***L:ERROR Internal error: type object 'DBEnvKeysConst' has no attribute
'NEED_DBMSUPGRADE'

if you have both yesterday patches it was going to fail due to the lack
of rh-postgresql95-postgresql-server

https://gerrit.ovirt.org/#/c/81478/ should be enough to require
rh-postgresql95-postgresql-server
by itself,
so if DWH is part of the upgrade test, I hope it will pass.

Thanks!




>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Wed, Sep 6, 2017 at 9:48 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 6 September 2017 at 10:42, Simone Tiraboschi <stira...@redhat.com>
> wrote:
> >
> >
> > On Wed, Sep 6, 2017 at 9:34 AM, Barak Korren <bkor...@redhat.com> wrote:
> >>
> >> On 5 September 2017 at 17:59, Simone Tiraboschi <stira...@redhat.com>
> >> wrote:
> >> >
> >> >
> >> > On Tue, Sep 5, 2017 at 2:00 PM, Dan Kenigsberg <dan...@redhat.com>
> >> > wrote:
> >> >>
> >> >> I believe that this issue is being tackled by
> >> >> https://gerrit.ovirt.org/#/c/81444/
> >> >
> >> >
> >> > No, the issue is on DWH setup side but we merged the related patches
> >> > there
> >> > almost together.
> >> > Not sure why OST is consuming an older DWH rpm.
> >>
> >> OST only uses packages that passed OST before + packages you explicitly
> >> add.
> >> The newer DWH setup package probably did not pass OST yet from one
> >> reason or another.
> >
> >
> > OK, in order to start consuming postgres 9.5 from SCL I had to introduce
> a
> > patch on ovirt-engine project and another on dwh project and I don't
> think
> > that we can successfully run the test suite with just one of the two.
> >
> > Should we simply wait or we have to manually run OST with a list of
> packages
> > from the two projects in order to have it flagging them as OK?
>
> Since we don`t have change dependency syntax yet, we need to trick the
> change queue into testing them together. The way to do that is to wait
> until it is busy testing something else and then send both changes
> together.
> We also need to make sure there are not other issues that will make it
> fail. We can verify that by using the manual job with both changes.
> Which are the two relevant changes?
>

We already found an rpm dependency issue on upgrade so now I'd say:
https://gerrit.ovirt.org/81478 and https://gerrit.ovirt.org/81476 (still to
be merged) in order to solve also that issue.


>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Wed, Sep 6, 2017 at 9:34 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 5 September 2017 at 17:59, Simone Tiraboschi <stira...@redhat.com>
> wrote:
> >
> >
> > On Tue, Sep 5, 2017 at 2:00 PM, Dan Kenigsberg <dan...@redhat.com>
> wrote:
> >>
> >> I believe that this issue is being tackled by
> >> https://gerrit.ovirt.org/#/c/81444/
> >
> >
> > No, the issue is on DWH setup side but we merged the related patches
> there
> > almost together.
> > Not sure why OST is consuming an older DWH rpm.
>
> OST only uses packages that passed OST before + packages you explicitly
> add.
> The newer DWH setup package probably did not pass OST yet from one
> reason or another.
>

OK, in order to start consuming postgres 9.5 from SCL I had to introduce a
patch on ovirt-engine project and another on dwh project and I don't think
that we can successfully run the test suite with just one of the two.

Should we simply wait or we have to manually run OST with a list of
packages from the two projects in order to have it flagging them as OK?


>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Tue, Sep 5, 2017 at 3:54 PM, Evgheni Dereveanchin 
wrote:

> Test failed: [ upgrade_engine ]
>
> Link to suspected patches:
> https://gerrit.ovirt.org/#/c/78307/46/
>
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2301/
> * this is failing since around job run 2291 but was masked by other errors
>
> Link to logs:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/2301/artifact/exported-artifacts/upgrade-from-
> release-suit-master-el7/test_logs/upgrade-from-release-
> suite-master/post-001_upgrade_engine.py/lago-upgrade-from-
> release-suite-master-engine/_var_log/ovirt-engine/setup/
> ovirt-engine-setup-20170905092844-6p7cux.log
>
> Error snippet from log:
>
> 
>
> 2017-09-05 09:28:45,444-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.execute:229 Creating own connection
> 2017-09-05 09:28:45,448-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.execute:274 Result: [{'count': 153L}]
> 2017-09-05 09:28:45,448-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.execute:224 Database: 'None', Statement: 'SHOW server_version',
> args: {}
> 2017-09-05 09:28:45,448-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.execute:229 Creating own connection
> 2017-09-05 09:28:45,452-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.execute:274 Result: [{'server_version': '9.2.18'}]
> 2017-09-05 09:28:45,452-0400 DEBUG 
> otopi.ovirt_engine_setup.engine_common.database
> database.checkServerVersion:449 PostgreSQL server version: 9.2.18
> 2017-09-05 09:28:45,453-0400 DEBUG otopi.plugins.ovirt_engine_
> common.ovirt_engine.db.connection connection._setup:146 Existing
> credential use failed
> Traceback (most recent call last):
>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-
> engine-common/ovirt-engine/db/connection.py", line 141, in _setup
> ] = dbovirtutils.checkDBMSUpgrade()
>   File 
> "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
> line 490, in checkDBMSUpgrade
> self.checkClientVersion()
>   File 
> "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
> line 457, in checkClientVersion
> self.command.get('psql'),
>   File "/usr/lib/python2.7/site-packages/otopi/command.py", line 74, in
> get
> command=command
> RuntimeError: Command 'psql' is required but missing
> 2017-09-05 09:28:45,454-0400 DEBUG otopi.context
> context._executeMethod:142 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in
> _executeMethod
> method['method']()
>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-
> engine-common/ovirt-engine/db/connection.py", line 162, in _setup
> raise RuntimeError(msg)
> RuntimeError: Cannot connect to Engine database using existing
> credentials: engine@localhost:5432
> 2017-09-05 09:28:45,455-0400 ERROR otopi.context
> context._executeMethod:151 Failed to execute stage 'Environment setup':
> Cannot connect to Engine database using existing credentials:
> engine@localhost:5432
>
>
It seams that for some strange reasons the test upgrade job is not
installing rh-postgresql95-postgresql which should be instead required as
for my modification the spec file:
https://gerrit.ovirt.org/#/c/78307/46/ovirt-engine.spec.in@274


Not sure if it's just a repo sync issue or something similar:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2301/artifact/exported-artifacts/upgrade-from-prevrelease-suit-master-el7/lago_logs/lago.log
And, by the way, the job is also testing 4.0.6.3 -> 4.2.0-0.0 and not 4.1
-> 4.2 as it should be (not sure why it's working).

Relevant log section:

Resolving Dependencies
--> Running transaction check
---> Package ovirt-engine-dwh-setup.noarch 0:4.0.6-1.el7.centos will be updated
---> Package ovirt-engine-dwh-setup.noarch
0:4.2.1-0.0.master.20170903090219.el7.centos will be an update
---> Package ovirt-engine-extension-aaa-ldap-setup.noarch
0:1.2.2-1.el7 will be updated
---> Package ovirt-engine-extension-aaa-ldap-setup.noarch
0:1.3.5-0.0.master.git7230cd9.el7.centos will be an update
--> Processing Dependency: ovirt-engine-extension-aaa-ldap =
1.3.5-0.0.master.git7230cd9.el7.centos for package:
ovirt-engine-extension-aaa-ldap-setup-1.3.5-0.0.master.git7230cd9.el7.centos.noarch
---> Package ovirt-engine-setup.noarch 0:4.0.6.3-1.el7.centos will be updated
---> Package ovirt-engine-setup.noarch
0:4.2.0-0.0.master.20170905115642.git4a0716e.el7.centos will be an
update
---> Package ovirt-engine-setup-base.noarch 0:4.0.6.3-1.el7.centos
will be updated
---> Package ovirt-engine-setup-base.noarch
0:4.2.0-0.0.master.20170905115642.git4a0716e.el7.centos will be an
update
--> Processing Dependency: ovirt-engine-lib >=
4.2.0-0.0.master.20170905115642.git4a0716e.el7.centos for package:

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-05 ] [upgrade_engine]

[Simone Tiraboschi]

On Tue, Sep 5, 2017 at 2:00 PM, Dan Kenigsberg  wrote:

> I believe that this issue is being tackled by
> https://gerrit.ovirt.org/#/c/81444/


No, the issue is on DWH setup side but we merged the related patches there
almost together.
Not sure why OST is consuming an older DWH rpm.


>
>
> On Tue, Sep 5, 2017 at 2:55 PM, Yaniv Kaul  wrote:
> > + Simone.
> > Y.
> >
> > On Tue, Sep 5, 2017 at 2:14 PM, Evgheni Dereveanchin <
> edere...@redhat.com>
> > wrote:
> >>
> >> Test failed: [ upgrade_engine ]
> >>
> >> Link to suspected patches:
> >> https://gerrit.ovirt.org/#/c/81205/9
> >>
> >> Link to Job:
> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2289/
> >>
> >> Link to all logs:
> >>
> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/2289/artifact/exported-artifacts/upgrade-from-
> prevrelease-suit-master-el7/test_logs/upgrade-from-
> prevrelease-suite-master/post-001_upgrade_engine.py/lago_logs/lago.log
> >>
> >> Error snippet from log:
> >>
> >> 
> >>
> >> engine-setup --config-append=/tmp/answer-file-post --accept-defaults
> >> returned with 2
> >> output:
> >>  ***L:ERROR Internal error: type object 'DBEnvKeysConst' has no
> attribute
> >> 'NEED_DBMSUPGRADE'
> >>
> >> 
> >>
> >> ___
> >> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Heads up: PostgreSQL 9.5

[Simone Tiraboschi]

On Tue, Sep 5, 2017 at 11:47 AM, Dan Kenigsberg <dan...@redhat.com> wrote:

> On Tue, Sep 5, 2017 at 11:12 AM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
> > Hi all,
> > we merged a set of patches to consume PostgreSQL 9.5 from SCL.
> > Please report any suspect behavior.
> >
> > We already fixed and published a patched version of ovirt-release-master
> > which includes the SCL repo but if you installed it in the past you need
> to
> > upgrade or manually install centos-release-scl-rh to configure the SCL
> repo.
> >
> > If you installed DWH in the past, you need to upgrade it as well.
>
>
> A recent rebase caused
> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1086/console to
> fail on
>
> 08:24:55 + systemctl start firewalld
> 08:24:55 + yum install --nogpgcheck -y --downloaddir=/dev/shm ntp
> net-snmp ovirt-engine ovirt-log-collector
> 'ovirt-engine-extension-aaa-ldap*'
> 08:24:55 Error: Package:
> ovirt-engine-tools-backup-4.2.0-0.0.master.20170905074337.
> git8cca476.el7.centos.noarch
> (alocalsync)
> 08:24:55Requires: rh-postgresql95-postgresql
> 08:24:55 Error: Package:
> ovirt-engine-4.2.0-0.0.master.20170905074337.git8cca476.el7.centos.noarch
> (alocalsync)
> 08:24:55Requires: rh-postgresql95-postgresql-server
>
> which seems related. Is it?
>

Yes, we are working on https://gerrit.ovirt.org/#/c/81444/ to include the
correct repo in ovirt-system-tests.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Heads up: PostgreSQL 9.5

[Simone Tiraboschi]

Hi all,
we merged a set of patches to consume PostgreSQL 9.5 from SCL.
Please report any suspect behavior.

We already fixed and published a patched version of ovirt-release-master
which includes the SCL repo but if you installed it in the past you need to
upgrade or manually install centos-release-scl-rh to configure the SCL repo.

If you installed DWH in the past, you need to upgrade it as well.

ciao
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

[Simone Tiraboschi]

On Wed, May 17, 2017 at 2:35 PM, Yedidyah Bar David  wrote:

> On Wed, May 17, 2017 at 2:54 PM, Dan Kenigsberg  wrote:
> > On Wed, May 17, 2017 at 12:23 PM, Yedidyah Bar David 
> wrote:
> >> On Wed, May 17, 2017 at 11:42 AM, Dan Kenigsberg 
> wrote:
> >>> On Wed, May 17, 2017 at 10:44 AM, Yedidyah Bar David 
> wrote:
>  On Wed, May 17, 2017 at 9:38 AM, Dan Kenigsberg 
> wrote:
> > On Tue, May 16, 2017 at 6:56 PM, Sandro Bonazzola <
> sbona...@redhat.com> wrote:
> >>
> >> Hi,
> >> with https://gerrit.ovirt.org/76855 it's requested to increase the
> appliance size by adding ovirt-provider-ovn and its dependencies.
> >>
> >> This raise a few questions.
> >> The support for ovirt-provider-ovn is enabled by default in
> engine-setup and going to be installed by default in the appliance so we're
> pushing to use it.
> >> Why not requiring it at ovirt-engine spec file level?
> >> Answer given in the commit message of above patch is:
> >>
> >> We do not want to have a hard dependency in the
> >> form of an rpm require.
> >> OVN and openvswitch are relatively heavy and complex,
> >> and are still experimental. We would not want to
> >> force everybody to pull them onto any Engine host.
> >>
> >> So why adding it to the appliance, which is the default for hosted
> engine which is our recommeded way to deploy oVirt, and enable it by
> default?
> >>
> >> How this differs from DWH? ovirt-engine requires ovirt-engine-setup
> which requires ovirt-engine-dwh setup which requires ovirt-engine-dwh.
> >> Why can't we just require ovirt-provider-ovn in ovirt-engine
> instead of tweaking the appliance?
> >>
> >> If we decide it's not mandatory, why not make the default to not
> enabling it in engine-setup and avoid to add it to the appliance?
> >> Being optional, adding it collides with Bug 1401931 - [RFE] reduce
> the size of the appliance
> >
> > Much like with DWH, I can envisage a use case where
> ovirt-provider-ovn
> > sits on a remote host, rather than on Engine's. However, the default
> > use case is to place them on the same host.
> >
> > I thought that it would be a good idea to include OVN on the
> > appliance, as a means to showcase this new and exciting feature of
> > oVirt. However, it is not a must. We can say that we'd like to keep
> > the appliance small; if someone wants to use OVN with it, let them
> run
> > ovirt-engine-setup manually, and pull in the dependencies.
> 
>  The appliance is assumed to (soon?) be our standard installation flow,
>  not a way to showcase things. For the latter, you might want to add
> ovn
>  to ovirt-live or to the ovirt demo tool [1] (not yet released IIUC).
> 
>  [1] https://trello.com/b/wocfflzf/sales-demo-tool-lago-based
> 
> >
> > For this we'd need to flip the default, and not install OVN when the
> > appliance is created, and skip OVN test in the offline test suite.
> 
>  +1
> >>>
> >>> Could you point us to the answer file used for appliance creation?
> >>
> >> Do you want to keep the default True for non-appliance? My +1 above
> >> was also for reverting the default, not only in appliance.
> >
> > Oh. I still want to have OVN by default for non-appliance. I like this
> > feature, and I want to entice people to use it.
>
> I think that Sandro's question above applies equally well to the
> non-appliance usecase. If it's good enough to be the default for
> non-appliance, might as well be so for the appliance as well. If
> it's not good enough for the appliance, perhaps default to No also
> for non-appliance.
>
> >
> > For appliance I understand that we have a size limitation, so ok, let
> > us not bloat it up.
>
> What's the impact on size? For the appliance image and for the
> eventually-installed machine?
>
> I do not think the impact on appliance size is the major question here,
> but whether we really expect most users to use OVN. But I might be
> surprised...
>
>
Now we have a bug to track it:
https://bugzilla.redhat.com/show_bug.cgi?id=1452131


> >
> > I hope you are also fine with disabling ovn in the following answer file.
> >
> >>
> >> The appliance-supplied answer file seems is:
> >>
> >> https://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git;
> a=blob;f=engine-appliance/data/ovirt-engine-answers;h=
> 2881af6563297a7a3d220dfe479d39f88c12ca46;hb=HEAD
> >>
> >> When hosted-engine --deploy is using the appliance, and if the user
> >> asks to run engine-setup automatically, it uses above file,
> >> but also adds another file, auto-generated, see here:
> >>
> >> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-
> setup.git;a=blob;f=src/plugins/gr-he-common/vm/cloud_init.py;h=
> 0a20f946d65199423c99769ab51e4fe092465e96;hb=HEAD#l1018
> >>
> >> None of them has the answer for OVN. 

Re: [ovirt-devel] OST: HE vm does not restart on HC setup

[Simone Tiraboschi]

On Wed, Feb 22, 2017 at 3:22 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 22 Feb 2017, at 13:53, Simone Tiraboschi <stira...@redhat.com> wrote:
>
>
>
> On Wed, Feb 22, 2017 at 1:33 PM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>
>> When ovirt-ha-agent checks the status of the engine VM we get:
>>
>> 2017-02-21 22:21:14,738-0500 ERROR (jsonrpc/2) [api] FINISH getStats 
>> error=Virtual machine does not exist: {'vmId': 
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'} (api:69)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 67, in 
>> method
>> ret = func(*args, **kwargs)
>>   File "/usr/share/vdsm/API.py", line 335, in getStats
>> vm = self.vm
>>   File "/usr/share/vdsm/API.py", line 130, in vm
>> raise exception.NoSuchVM(vmId=self._UUID)
>> NoSuchVM: Virtual machine does not exist: {'vmId': 
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'}
>>
>>
>> While in ovirt-ha-agent logs we have:
>>
>> MainThread::INFO::2017-02-21 
>> 22:21:18,583::hosted_engine::453::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
>>  Current state UnknownLocalVmState (score: 3400)
>>
>> ...
>>
>> MainThread::INFO::2017-02-21 
>> 22:21:31,199::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
>>  Unknown local engine vm status no actions taken
>>
>> Probably it's a bug or a regression somewhere on master.
>>
>
> On ovirt-ha-broker side the detection is based on a strict string match on
> the error message that is expected to be exactly 'Virtual machine does not
> exist' to set down status otherwise we set unknown status as in this case:
> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-
> ha.git;a=blob;f=ovirt_hosted_engine_ha/broker/submonitors/
> engine_health.py;h=d633cb860b811e84021221771bf706a9a4ac1d63;hb=refs/heads/
> master#l54
>
> Adding Francesco here to understand if something has recently changed
> there on vdsm side.
>
>
> That’s not a very robust code handling.
> Yes, the text changed, the vm id was added.
> And yes, it may change again any time I guess
>

I agree, we are going to move to code check:
https://gerrit.ovirt.org/#/c/72891


>
>
>
>>
>> On Wed, Feb 22, 2017 at 1:02 PM, Sandro Bonazzola <sbona...@redhat.com>
>> wrote:
>>
>>> Adding Lev
>>>
>>> On Wed, Feb 22, 2017 at 12:59 PM, Sahina Bose <sab...@redhat.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> On the HC setup, the HE VM is not restarted.
>>>> The agent.log has
>>>> MainThread::INFO::2017-02-21 
>>>> 22:09:58,022::state_machine::169::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(refresh)
>>>>  Global metadata: {}
>>>> MainThread::INFO::2017-02-21 
>>>> 22:09:58,023::state_machine::177::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(refresh)
>>>>  Local (id 1): {'engine-health': {'reason': 'failed to getVmStats', 
>>>> 'health': 'unknown', 'vm': 'unknown', 'detail': 'unknown'}, 'bridge': 
>>>> True, 'mem-free': 4079.0, 'maintenance': False, 'cpu-load': 0.0491, 
>>>> 'gateway': True}
>>>> ...
>>>> MainThread::INFO::2017-02-21 
>>>> 22:10:29,219::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
>>>>  Unknown local engine vm status no actions taken
>>>> MainThread::INFO::2017-02-21 
>>>> 22:10:29,219::brokerlink::111::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
>>>>  Trying: notify time=1487733029.22 type=state_transition 
>>>> detail=ReinitializeFSM-UnknownLocalVmState 
>>>> hostname='lago-hc-basic-suite-master-host0'
>>>> MainThread::INFO::2017-02-21 
>>>> 22:10:29,317::brokerlink::121::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
>>>>  Success, was notification of state_transition 
>>>> (ReinitializeFSM-UnknownLocalVmState) sent? ignored
>>>>
>>>> and the vdsm.log
>>>>
>>>> 2017-02-21 22:09:11,962-0500 INFO  (libvirt/events) [virt.vm] 
>>>> (vmId='2ccc0ef0-cc31-45b8-8e91-a78fa4cad671') Changed state to Down: User 
>>>> shut down from within the guest (code=7) (vm:1269)
>>>> 2017-02-21 22:09:11,962-0500 INFO  (libvirt/events) [virt.vm] 
>>>> (vmId='2ccc0ef0-cc31-45b8-8e91-a78fa4cad671') Stopping connection 
>>>> (gue

Re: [ovirt-devel] OST: HE vm does not restart on HC setup

[Simone Tiraboschi]

When ovirt-ha-agent checks the status of the engine VM we get:

2017-02-21 22:21:14,738-0500 ERROR (jsonrpc/2) [api] FINISH getStats
error=Virtual machine does not exist: {'vmId':
u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'} (api:69)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 67, in method
ret = func(*args, **kwargs)
  File "/usr/share/vdsm/API.py", line 335, in getStats
vm = self.vm
  File "/usr/share/vdsm/API.py", line 130, in vm
raise exception.NoSuchVM(vmId=self._UUID)
NoSuchVM: Virtual machine does not exist: {'vmId':
u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'}


While in ovirt-ha-agent logs we have:

MainThread::INFO::2017-02-21
22:21:18,583::hosted_engine::453::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
Current state UnknownLocalVmState (score: 3400)

...

MainThread::INFO::2017-02-21
22:21:31,199::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
Unknown local engine vm status no actions taken

Probably it's a bug or a regression somewhere on master.


On Wed, Feb 22, 2017 at 1:02 PM, Sandro Bonazzola 
wrote:

> Adding Lev
>
> On Wed, Feb 22, 2017 at 12:59 PM, Sahina Bose  wrote:
>
>> Hi all,
>>
>> On the HC setup, the HE VM is not restarted.
>> The agent.log has
>> MainThread::INFO::2017-02-21 
>> 22:09:58,022::state_machine::169::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(refresh)
>>  Global metadata: {}
>> MainThread::INFO::2017-02-21 
>> 22:09:58,023::state_machine::177::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(refresh)
>>  Local (id 1): {'engine-health': {'reason': 'failed to getVmStats', 
>> 'health': 'unknown', 'vm': 'unknown', 'detail': 'unknown'}, 'bridge': True, 
>> 'mem-free': 4079.0, 'maintenance': False, 'cpu-load': 0.0491, 'gateway': 
>> True}
>> ...
>> MainThread::INFO::2017-02-21 
>> 22:10:29,219::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
>>  Unknown local engine vm status no actions taken
>> MainThread::INFO::2017-02-21 
>> 22:10:29,219::brokerlink::111::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
>>  Trying: notify time=1487733029.22 type=state_transition 
>> detail=ReinitializeFSM-UnknownLocalVmState 
>> hostname='lago-hc-basic-suite-master-host0'
>> MainThread::INFO::2017-02-21 
>> 22:10:29,317::brokerlink::121::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify)
>>  Success, was notification of state_transition 
>> (ReinitializeFSM-UnknownLocalVmState) sent? ignored
>>
>> and the vdsm.log
>>
>> 2017-02-21 22:09:11,962-0500 INFO  (libvirt/events) [virt.vm] 
>> (vmId='2ccc0ef0-cc31-45b8-8e91-a78fa4cad671') Changed state to Down: User 
>> shut down from within the guest (code=7) (vm:1269)
>> 2017-02-21 22:09:11,962-0500 INFO  (libvirt/events) [virt.vm] 
>> (vmId='2ccc0ef0-cc31-45b8-8e91-a78fa4cad671') Stopping connection 
>> (guestagent:429)
>>
>> 2017-02-21 22:09:29,727-0500 ERROR (jsonrpc/4) [api] FINISH getStats 
>> error=Virtual machine does not exist: {'vmId': 
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'} (api:69)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 67, in 
>> method
>> ret = func(*args, **kwargs)
>>   File "/usr/share/vdsm/API.py", line 335, in getStats
>> vm = self.vm
>>   File "/usr/share/vdsm/API.py", line 130, in vm
>> raise exception.NoSuchVM(vmId=self._UUID)
>> NoSuchVM: Virtual machine does not exist: {'vmId': 
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'}
>>
>>
>> What should I be looking for to identify the issue?
>>
>> The logs are at 
>> http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/lastCompletedBuild/artifact/exported-artifacts/test_logs/hc-basic-suite-master/post-002_bootstrap.py/lago-hc-basic-suite-master-host0
>>
>> thanks
>>
>> sahina
>>
>>
>> ___
>> 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

Re: [ovirt-devel] [ovirt-users] Translate hint

[Simone Tiraboschi]

On Thu, Jan 26, 2017 at 11:50 AM, Gianluca Cecchi  wrote:

> On Thu, Jan 26, 2017 at 11:40 AM, Yuko Katabami 
> wrote:
>
>>
>>
>> You should notify the engineering team when you finished working.
>> Pulling translations from Zanata into the repo is a manual task, so
>> unless you ask the team, it will not be imported to the product.
>> Particularly with non-latest versions.
>>
>> Kind regards,
>>
>> Yuko
>>
>>>
>>>
> Thank you very much Yuko for the explanation! I'm going to test what you
> suggested.
> BTW: what should I do to "notify the engineering team"?
>
>
A message on devel@ovirt.org is enough


> Cheers,
> Gianluca
>
> ___
> 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 master ] [25.01.17] [add_hosts]

[Simone Tiraboschi]

On Wed, Jan 25, 2017 at 9:06 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Wed, Jan 25, 2017 at 9:03 PM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>
>>
>>
>> On Wed, Jan 25, 2017 at 7:25 PM, Piotr Kliczewski <pklic...@redhat.com>
>> wrote:
>>
>>> Do we have a BZ to track this issue?
>>>
>>> Now that the package was removed we need to make sure there are no
>>> references to it.
>>>
>>
>> A patch is here:
>> https://gerrit.ovirt.org/#/c/71209
>>
>> We have to open a bug and respin otopi
>>
>
> and ovirt-host-deploy too:
> https://gerrit.ovirt.org/#/c/71210/
>

and probably also the engine:
https://gerrit.ovirt.org/#/c/71211

and maybe something else...


>
>
>
>>
>>
>>>
>>> 25 sty 2017 19:20 "Eyal Edri" <ee...@redhat.com> napisał(a):
>>>
>>> Adding more VDSM & OTOPI maintainers.
>>>
>>> On Wed, Jan 25, 2017 at 6:40 PM, Gil Shinar <gshi...@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> vdsm-cli has been removed from VDSM rpms but hadn't been removed from
>>>> add hosts. Here is the error message:
>>>>
>>>> 2017-01-25 10:59:44 DEBUG otopi.plugins.otopi.packagers.yumpackager 
>>>> yumpackager.verbose:76 Yum Building transaction
>>>> 2017-01-25 10:59:47 ERROR otopi.plugins.otopi.packagers.yumpackager 
>>>> yumpackager.error:85 Yum 
>>>> [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-xmlrpc = 
>>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>>> 4.20.0-261.gitabb73a5.el7.centos']
>>>> 2017-01-25 10:59:47 DEBUG otopi.context context._executeMethod:142 method 
>>>> exception
>>>> Traceback (most recent call last):
>>>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/context.py", line 132, in 
>>>> _executeMethod
>>>> method['method']()
>>>>   File 
>>>> "/tmp/ovirt-9WzrERSugT/otopi-plugins/otopi/packagers/yumpackager.py", line 
>>>> 253, in _packages
>>>> if self._miniyum.buildTransaction():
>>>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/miniyum.py", line 919, in 
>>>> buildTransaction
>>>> raise yum.Errors.YumBaseError(msg)
>>>> YumBaseError: [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires 
>>>> vdsm-xmlrpc = 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>>> 4.20.0-261.gitabb73a5.el7.centos']
>>>> 2017-01-25 10:59:47 ERROR otopi.context context._executeMethod:151 Failed 
>>>> to execute stage 'Package installation': 
>>>> [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-xmlrpc = 
>>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>>> 4.20.0-261.gitabb73a5.el7.centos']
>>>> 2017-01-25 10:59:47 DEBUG otopi.transaction transaction.abort:119 aborting 
>>>> 'Yum Transaction'
>>>> 2017-01-25 10:59:47 INFO otopi.plugins.otopi.packagers.yumpackager 
>>>> yumpackager.info:80 Yum Performing yum transaction rollback
>>>>
>>>>
>>>> Link to suspected patches: https://gerrit.ovirt.org/#/c/68721/
>>>> Link to Job: http://jenkins.ovirt.org/job/t
>>>> est-repo_ovirt_experimental_master/4962/
>>>> Link to all logs: http://jenkins.ovirt.org/job/t
>>>> est-repo_ovirt_experimental_master/4962/artifact/exported-ar
>>>> tifacts/basic-suit-master-el7/test_logs/basic-suite-master/p
>>>> ost-002_bootstrap.py/lago-basic-suite-master-engine/_var_log
>>>> /ovirt-engine/host-deploy/
>>>>
>>>> Thanks
>>>> Gil
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>>
>>> --
>>> Eyal Edri
>>> Associate Manager
>>> RHV DevOps
>>> EMEA ENG Virtualization R
>>> Red Hat Israel
>>>
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> 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 master ] [25.01.17] [add_hosts]

[Simone Tiraboschi]

On Wed, Jan 25, 2017 at 9:03 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Wed, Jan 25, 2017 at 7:25 PM, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
>
>> Do we have a BZ to track this issue?
>>
>> Now that the package was removed we need to make sure there are no
>> references to it.
>>
>
> A patch is here:
> https://gerrit.ovirt.org/#/c/71209
>
> We have to open a bug and respin otopi
>

and ovirt-host-deploy too:
https://gerrit.ovirt.org/#/c/71210/


>
>
>>
>> 25 sty 2017 19:20 "Eyal Edri" <ee...@redhat.com> napisał(a):
>>
>> Adding more VDSM & OTOPI maintainers.
>>
>> On Wed, Jan 25, 2017 at 6:40 PM, Gil Shinar <gshi...@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> vdsm-cli has been removed from VDSM rpms but hadn't been removed from
>>> add hosts. Here is the error message:
>>>
>>> 2017-01-25 10:59:44 DEBUG otopi.plugins.otopi.packagers.yumpackager 
>>> yumpackager.verbose:76 Yum Building transaction
>>> 2017-01-25 10:59:47 ERROR otopi.plugins.otopi.packagers.yumpackager 
>>> yumpackager.error:85 Yum 
>>> [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-xmlrpc = 
>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>> 4.20.0-261.gitabb73a5.el7.centos']
>>> 2017-01-25 10:59:47 DEBUG otopi.context context._executeMethod:142 method 
>>> exception
>>> Traceback (most recent call last):
>>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/context.py", line 132, in 
>>> _executeMethod
>>> method['method']()
>>>   File 
>>> "/tmp/ovirt-9WzrERSugT/otopi-plugins/otopi/packagers/yumpackager.py", line 
>>> 253, in _packages
>>> if self._miniyum.buildTransaction():
>>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/miniyum.py", line 919, in 
>>> buildTransaction
>>> raise yum.Errors.YumBaseError(msg)
>>> YumBaseError: [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires 
>>> vdsm-xmlrpc = 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>> 4.20.0-261.gitabb73a5.el7.centos']
>>> 2017-01-25 10:59:47 ERROR otopi.context context._executeMethod:151 Failed 
>>> to execute stage 'Package installation': 
>>> [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-xmlrpc = 
>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>>> 4.20.0-261.gitabb73a5.el7.centos', 
>>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>>> 4.20.0-261.gitabb73a5.el7.centos']
>>> 2017-01-25 10:59:47 DEBUG otopi.transaction transaction.abort:119 aborting 
>>> 'Yum Transaction'
>>> 2017-01-25 10:59:47 INFO otopi.plugins.otopi.packagers.yumpackager 
>>> yumpackager.info:80 Yum Performing yum transaction rollback
>>>
>>>
>>> Link to suspected patches: https://gerrit.ovirt.org/#/c/68721/
>>> Link to Job: http://jenkins.ovirt.org/job/t
>>> est-repo_ovirt_experimental_master/4962/
>>> Link to all logs: http://jenkins.ovirt.org/job/t
>>> est-repo_ovirt_experimental_master/4962/artifact/exported-ar
>>> tifacts/basic-suit-master-el7/test_logs/basic-suite-master/p
>>> ost-002_bootstrap.py/lago-basic-suite-master-engine/_var_log
>>> /ovirt-engine/host-deploy/
>>>
>>> Thanks
>>> Gil
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHV DevOps
>> EMEA ENG Virtualization R
>> Red Hat Israel
>>
>> phone: +972-9-7692018 <+972%209-769-2018>
>> 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 master ] [25.01.17] [add_hosts]

[Simone Tiraboschi]

On Wed, Jan 25, 2017 at 7:25 PM, Piotr Kliczewski 
wrote:

> Do we have a BZ to track this issue?
>
> Now that the package was removed we need to make sure there are no
> references to it.
>

A patch is here:
https://gerrit.ovirt.org/#/c/71209

We have to open a bug and respin otopi


>
> 25 sty 2017 19:20 "Eyal Edri"  napisał(a):
>
> Adding more VDSM & OTOPI maintainers.
>
> On Wed, Jan 25, 2017 at 6:40 PM, Gil Shinar  wrote:
>
>> Hi,
>>
>> vdsm-cli has been removed from VDSM rpms but hadn't been removed from add
>> hosts. Here is the error message:
>>
>> 2017-01-25 10:59:44 DEBUG otopi.plugins.otopi.packagers.yumpackager 
>> yumpackager.verbose:76 Yum Building transaction
>> 2017-01-25 10:59:47 ERROR otopi.plugins.otopi.packagers.yumpackager 
>> yumpackager.error:85 Yum [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch 
>> requires vdsm-xmlrpc = 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>> 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>> 4.20.0-261.gitabb73a5.el7.centos']
>> 2017-01-25 10:59:47 DEBUG otopi.context context._executeMethod:142 method 
>> exception
>> Traceback (most recent call last):
>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/context.py", line 132, in 
>> _executeMethod
>> method['method']()
>>   File "/tmp/ovirt-9WzrERSugT/otopi-plugins/otopi/packagers/yumpackager.py", 
>> line 253, in _packages
>> if self._miniyum.buildTransaction():
>>   File "/tmp/ovirt-9WzrERSugT/pythonlib/otopi/miniyum.py", line 919, in 
>> buildTransaction
>> raise yum.Errors.YumBaseError(msg)
>> YumBaseError: [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires 
>> vdsm-xmlrpc = 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>> 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>> 4.20.0-261.gitabb73a5.el7.centos']
>> 2017-01-25 10:59:47 ERROR otopi.context context._executeMethod:151 Failed to 
>> execute stage 'Package installation': 
>> [u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-xmlrpc = 
>> 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-client = 
>> 4.20.0-261.gitabb73a5.el7.centos', 
>> u'vdsm-cli-4.20.0-261.gitabb73a5.el7.centos.noarch requires vdsm-python = 
>> 4.20.0-261.gitabb73a5.el7.centos']
>> 2017-01-25 10:59:47 DEBUG otopi.transaction transaction.abort:119 aborting 
>> 'Yum Transaction'
>> 2017-01-25 10:59:47 INFO otopi.plugins.otopi.packagers.yumpackager 
>> yumpackager.info:80 Yum Performing yum transaction rollback
>>
>>
>> Link to suspected patches: https://gerrit.ovirt.org/#/c/68721/
>> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/4962/
>> Link to all logs: http://jenkins.ovirt.org/job/t
>> est-repo_ovirt_experimental_master/4962/artifact/exported-ar
>> tifacts/basic-suit-master-el7/test_logs/basic-suite-master/p
>> ost-002_bootstrap.py/lago-basic-suite-master-engine/_var_
>> log/ovirt-engine/host-deploy/
>>
>> Thanks
>> Gil
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No module named dwh

[Simone Tiraboschi]

On Thu, Oct 13, 2016 at 5:34 PM, Vojtech Szocs <vsz...@redhat.com> wrote:

> Hi, thanks for fixing this.
>
> (Should we really add DWH as requirement for dev-env? Shouldn't it be
> opt-in instead?)
>

Good point,
on the packaged build DWH setup is now a strict dependency but you can
still choose to install it on a different server.


>
> Thanks,
> Vojtech
>
>
> - Original Message -
> > From: "Simone Tiraboschi" <stira...@redhat.com>
> > To: "Vojtech Szocs" <vsz...@redhat.com>
> > Cc: "devel" <devel@ovirt.org>
> > Sent: Thursday, October 13, 2016 12:23:39 AM
> > Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No
> module named dwh
> >
> > Hi,
> > Jakub was right: the issue has been introduced with commit 221c7ed.
> >
> > It affects just the dev env since there we are currently not installing
> (we
> > need to dig this!) DWH which instead is a dependency on the packaged
> builds
> > since 4.0.
> >
> > Patch https://gerrit.ovirt.org/#/c/65409/ fixes it.
> >
> > ciao
> >
> > On Wed, Oct 12, 2016 at 6:08 PM, Vojtech Szocs <vsz...@redhat.com>
> wrote:
> >
> > > Same problem here.
> > >
> > > Vojtech
> > >
> > >
> > > - Original Message -
> > > > From: "Dominik Holler" <dhol...@redhat.com>
> > > > To: devel@ovirt.org
> > > > Sent: Wednesday, October 12, 2016 2:39:27 PM
> > > > Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error:
> No
> > > module named dwh
> > > >
> > > > Hi,
> > > > I got the same error. Is there any experience about this, by now?
> > > > Dominik
> > > >
> > > > On Mon, 10 Oct 2016 15:48:08 -0400 (EDT)
> > > > Jakub Niedermertl <jnied...@redhat.com> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > does anyone else experience following error of `engine-setup`?
> > > > >
> > > > > $ ~/target/bin/engine-setup
> > > > > ***L:ERROR Internal error: No module named dwh
> > > > >
> > > > > I have a suspicion it might be related to commit '221c7ed
> packaging:
> > > > > setup: Remove constants duplication'.
> > > > >
> > > > > Jakub
> > > > > ___
> > > > > 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
> > > >
> > > ___
> > > 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] engine-setup: ***L:ERROR Internal error: No module named dwh

[Simone Tiraboschi]

Hi,
Jakub was right: the issue has been introduced with commit 221c7ed.

It affects just the dev env since there we are currently not installing (we
need to dig this!) DWH which instead is a dependency on the packaged builds
since 4.0.

Patch https://gerrit.ovirt.org/#/c/65409/ fixes it.

ciao

On Wed, Oct 12, 2016 at 6:08 PM, Vojtech Szocs  wrote:

> Same problem here.
>
> Vojtech
>
>
> - Original Message -
> > From: "Dominik Holler" 
> > To: devel@ovirt.org
> > Sent: Wednesday, October 12, 2016 2:39:27 PM
> > Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No
> module named dwh
> >
> > Hi,
> > I got the same error. Is there any experience about this, by now?
> > Dominik
> >
> > On Mon, 10 Oct 2016 15:48:08 -0400 (EDT)
> > Jakub Niedermertl  wrote:
> >
> > > Hi all,
> > >
> > > does anyone else experience following error of `engine-setup`?
> > >
> > > $ ~/target/bin/engine-setup
> > > ***L:ERROR Internal error: No module named dwh
> > >
> > > I have a suspicion it might be related to commit '221c7ed packaging:
> > > setup: Remove constants duplication'.
> > >
> > > Jakub
> > > ___
> > > 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
> >
> ___
> 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] Auto deploy GUI

[Simone Tiraboschi]

On Fri, Sep 30, 2016 at 8:37 AM, Suramya Shah 
wrote:

> We can create a GUI plug-in that will allow a user to easily setup and
> manage the deployment requirements .
>

Did you saw the cockpit plugin for hosted-engine-setup in next generation
node?


>
> ___
> 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] yum install ovirt-engine-4.0.2.6 , login the 'Administration Portal', the version is '4.0.4.4', That's why?

[Simone Tiraboschi]

On Tue, Sep 27, 2016 at 2:56 PM, 转圈圈 <313922...@qq.com> wrote:

> The Installation steps:
> # yum -y update
> #yum install http://plain.resources.ovirt.org/pub/yum-repo/ovirt-
> release40.rpm
> # yum -y install ovirt-engine-4.0.2.6
>

ohh, sorry, I was thinking that you were with oVirt 4.0.2 and you want to
run engine-setup without being asked to upgrade to 4.0.4.

oVirt is composed by multiple packages and 4.0.4 and 4.0.2 are in same repo
so it's not enough to simply query for ovirt-engine-4.0.2.6 since you are
going to get anything else from 4.0.4 because 4.0.4 > 4.0.2.
Probably the cleanest option is to use versionlock which also supports
wildcards on packet selection.
But can I ask again why you explicitly need 4.0.2 instead of 4.0.4 since
4.0.4 is just supposed to fix issues? what is bothering you with 4.0.4?
maybe it's a regression.


#engine-setup --offline
> Installed finshed,but login the 'Administration Portal',the version is
> '4.0.4.4',That's why?
>
I don't want to use the latest version.
> thanks !
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>


8556D1BC@5A3F9728.886CEA57
Description: Binary data
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] yum install ovirt-engine-4.0.2.6 , when run the "engine-setup" not updrages , Report an error

[Simone Tiraboschi]

On Tue, Sep 27, 2016 at 9:12 AM, 转圈圈 <313922...@qq.com> wrote:

> Ovirt current version is 4.0.4.4 ,i installed ovirt-engine with older
> version like 4.0.2.6 and install it by "yum install ovirt-engine-4.0.2.6
>  ", when run the  "engine-setup" i am not updrages ,Report an error,how
> can i to do,Thank you.
> i don't want to install the latest version.
>
>
engine-setup --offline will not check for updates.
But what's the problem with a recent release that should come with
different bug fixes?


> [root@localhost ~]# engine-setup
> [ INFO  ] Stage: Initializing
> [ INFO  ] Stage: Environment setup
>   Configuration files: ['/etc/ovirt-engine-setup.
> conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.
> d/10-packaging.conf']
>   Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-
> 20160927144353-coryv9.log
>   Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
> [ INFO  ] Stage: Environment packages setup
> [ INFO  ] Stage: Programs detection
> [ INFO  ] Stage: Environment setup
> [ INFO  ] Stage: Environment customization
>
>   --== PRODUCT OPTIONS ==--
>
>   Configure Engine on this host (Yes, No) [Yes]:
>   Configure Image I/O Proxy on this host? (Yes, No) [Yes]:
>   Configure WebSocket Proxy on this host (Yes, No) [Yes]:
>   Please note: Data Warehouse is required for the engine. If you
> choose to not configure it on this host, you have to configure it on a
> remote host, and then configure the engine on this host so that it can
> access the database of the remote Data Warehouse host.
>   Configure Data Warehouse on this host (Yes, No) [Yes]:
>   Configure VM Console Proxy on this host (Yes, No) [Yes]:
>
>   --== PACKAGES ==--
>
> [ INFO  ] Checking for product updates...
>   Setup has found updates for some packages:
>   PACKAGE: [updated] ovirt-engine-4.0.2.6-1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-4.0.4.4-1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-backend-4.0.2.6-
> 1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-backend-4.0.4.4-
> 1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-dbscripts-4.0.2.
> 6-1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-dbscripts-4.0.4.
> 4-1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-restapi-4.0.2.6-
> 1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-restapi-4.0.4.4-
> 1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-tools-4.0.2.6-1.
> el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-tools-4.0.4.4-1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-tools-backup-4.0.
> 2.6-1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-tools-backup-4.0.
> 4.4-1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-userportal-4.0.2.
> 6-1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-userportal-4.0.4.
> 4-1.el7.centos.noarch
>   PACKAGE: [updated] ovirt-engine-webadmin-portal-
> 4.0.2.6-1.el7.centos.noarch
>   PACKAGE: [update] ovirt-engine-webadmin-portal-
> 4.0.4.4-1.el7.centos.noarch
>   do you wish to update them now? (Yes, No) [Yes]: no
> [ ERROR ] Failed to execute stage 'Environment customization': Aborted,
> packages must be updated
> [ INFO  ] Stage: Clean up
>   Log file is located at /var/log/ovirt-engine/setup/
> ovirt-engine-setup-20160927144353-coryv9.log
> [ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/
> 20160927144532-setup.conf'
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> [ ERROR ] Execution of setup failed
>
>
>
> ___
> 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] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

[Simone Tiraboschi]

On Mon, Sep 19, 2016 at 3:07 PM, Roy Golan  wrote:

>
>
> On 19 September 2016 at 15:12, Doron Fediuck  wrote:
>
>> Hi All,
>>
>> Martin Sivak has been working on the oVirt engine since June 2013.
>> His main focus over the years was around MoM, external scheduler, 
>> hosted-engine, and
>> related engine code.
>>
>> In the past year Martin took over many of the oVirt scheduler related work 
>> and did a lot of improvements there. In total Martin has around 170 engine 
>> patches already merged.
>>
>> Within these you will find improving the scheduler's notifications and error 
>> handling, rewriting the pending resource mechanism which resolved many 
>> issues, VM affinity, affinity labels and multiple improvements for our 
>> scheduling policies and hosted engine.
>>
>> I would like to thank Martin for his great contribution and hope for many 
>> more patches to come :)
>>
>> I would also like to propose Martin as an engine maintainer for SLA and 
>> Scheduling.
>>
>> Thanks, Doron
>>
>>
> +1 Actually +2 :)
>

+1


>
>
>
>>
>> ___
>> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-announce] [ANN] oVirt 4.0.4 RC2 is now available

[Simone Tiraboschi]

On Fri, Sep 9, 2016 at 12:02 PM, Simone Tiraboschi <stira...@redhat.com>
wrote:

> We had a quick re-spin of the engine to include a fix for
> https://bugzilla.redhat.com/1372950
> The new engine version is 4.0.4.2; a new oVirt Engine Appliance is also
> available, oVirt Live ISO will follow.
>

ovirt-live 4.0.4_rc2.1 is also in.


>
>
> On Wed, Sep 7, 2016 at 10:28 PM, Rafael Martins <rmart...@redhat.com>
> wrote:
>
>> The oVirt Project is pleased to announce the availability of the Second
>> Release Candidate of oVirt 4.0.4 for testing, as of September 7th, 2016.
>>
>> This release is available now for:
>> * Fedora 23 (tech preview)
>> * Red Hat Enterprise Linux 7.2 or later
>> * CentOS Linux (or similar) 7.2 or later
>>
>> This release supports Hypervisor Hosts running:
>> * Red Hat Enterprise Linux 7.2 or later
>> * CentOS Linux (or similar) 7.2 or later
>> * Fedora 23 (tech preview)
>> * oVirt Next Generation Node 4.0
>>
>> This is pre-release software. Please take a look at our community page[1]
>> to know how to ask questions and interact with developers and users.
>> All issues or bugs should be reported via oVirt Bugzilla[2].
>> This pre-release should not to be used in production.
>>
>> This update is the first release candidate of the fourth in a series of
>> stabilization updates to the 4.0 series. See the release notes [3] for
>> installation / upgrade instructions and a list of new features and bugs
>> fixed.
>>
>> Notes:
>> * A new oVirt Live ISO is available. [4]
>> * A new oVirt Next Generation Node is available [4].
>> * A new oVirt Engine Appliance is available for Red Hat Enterprise Linux
>>   and CentOS Linux (or similar)
>> * Mirrors[5] might need up to one day to synchronize.
>>
>> Additional Resources:
>> * Read more about the oVirt 4.0.4 release highlights:http://www.ovirt.or
>> g/release/4.0.4/
>> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
>> * Check out the latest project news on the oVirt blog:
>> http://www.ovirt.org/blog/
>>
>> [1] https://www.ovirt.org/community/
>> [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt
>> [3] http://www.ovirt.org/release/4.0.4/
>> [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/
>> [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors
>>
>> --
>> Rafael Martins
>> ___
>> Announce mailing list
>> annou...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/announce
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Announcing Rafael Martins as ovirt*uploader and ovirt-log-collector maintainer

[Simone Tiraboschi]

Well deserved, congratulations!

On Mon, Aug 8, 2016 at 4:28 PM, Simone Tiraboschi <stira...@redhat.com> wrote:
> On Thu, Aug 4, 2016 at 4:09 PM, Eyal Edri <ee...@redhat.com> wrote:
>> Congrats!
>> Good Luck with the new role & responsibility!
>>
>> On Thu, Aug 4, 2016 at 3:23 PM, Martin Perina <mper...@redhat.com> wrote:
>>>
>>> Congratulations!
>>>
>>> On Thu, Aug 4, 2016 at 2:11 PM, Sandro Bonazzola <sbona...@redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>> Rafael Martins has contributed several bug fixes and improvements to
>>>> ovirt-iso-uploader, ovirt-image-uploader and ovirt-log-collector.
>>>> He took a major role in the projects and he's currently default assignee
>>>> for bugs related to these projects.
>>>>
>>>> Rafael already has maintainer permissions on uploaders and log-collector.
>>>> I'd like to thank Rafael for his contribution and I hope he'll keep up
>>>> the good work!
>>>>
>>>> --
>>>> 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
>>>
>>>
>>>
>>> ___
>>> Infra mailing list
>>> in...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/infra
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHV DevOps
>> EMEA ENG Virtualization R
>> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Announcing Rafael Martins as ovirt*uploader and ovirt-log-collector maintainer

[Simone Tiraboschi]

On Thu, Aug 4, 2016 at 4:09 PM, Eyal Edri  wrote:
> Congrats!
> Good Luck with the new role & responsibility!
>
> On Thu, Aug 4, 2016 at 3:23 PM, Martin Perina  wrote:
>>
>> Congratulations!
>>
>> On Thu, Aug 4, 2016 at 2:11 PM, Sandro Bonazzola 
>> wrote:
>>>
>>> Hi,
>>> Rafael Martins has contributed several bug fixes and improvements to
>>> ovirt-iso-uploader, ovirt-image-uploader and ovirt-log-collector.
>>> He took a major role in the projects and he's currently default assignee
>>> for bugs related to these projects.
>>>
>>> Rafael already has maintainer permissions on uploaders and log-collector.
>>> I'd like to thank Rafael for his contribution and I hope he'll keep up
>>> the good work!
>>>
>>> --
>>> 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
>>
>>
>>
>> ___
>> Infra mailing list
>> in...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] python-paramiko availability

[Simone Tiraboschi]

On Thu, Jul 7, 2016 at 10:59 PM, Paul Dyer  wrote:
> Hi,
>
> I am trying to install the ovirt-4.0 engine to a fresh install of RHEL 7.2.
> There is a dependency for python-paramiko, but it appears that rpm was
> removed from RHEL between 6 and 7...
>
> The dependency appears when I install ovirt-engine:
>
> Error: Package: ovirt-engine-setup-base-4.0.0.6-1.el7.centos.noarch
> (ovirt-4.0)
>Requires: python-paramiko
>
> This doc notes the package removal:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Removed_Packages.html
>
> Does anyone know where to source this package?

You can get it from EPEL7.
http://koji.fedoraproject.org/koji/buildinfo?buildID=765436

> Thanks,
> Paul
>
>
> --
> Paul Dyer,
> Mercury Consulting Group, RHCE
> 504-302-8750
>
> ___
> 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] [vdsm] about package release number

[Simone Tiraboschi]

On Thu, Jun 16, 2016 at 5:24 PM, Francesco Romani  wrote:
> Hi all,
>
> it was recently pointed out that Vdsm 4.18.3 rpms have -0 release number, 
> like in
>
> rpmbuild/RPMS/x86_64/vdsm-4.18.3-0.fc23.x86_64.rpm
>
> But this is OK only for packages built from master. From stable branch and 
> official releases,
> we should have something like
>
> rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.c2e510e.fc23.x86_64.rpm
>
> or perhaps just
>
> rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.fc23.x86_64.rpm

If we want to follow the fedora packaging guidelines ([1]), There are
three cases in which non-numeric versions occur in the Release field:
- Snapshot packages
- Pre-release packages
- Post-release packages

So, being this a release candidate, in theory we should avoid
including a checkout tag in the package name.
It's instead a good practice for snapshot builds.

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease

> To quickly unblock 4.0, I posted
>
> https://gerrit.ovirt.org/#/c/59337/ - please consider this a quick fix and 
> review as such
>
> To properly address the versioning, I posted my take here
>
> https://gerrit.ovirt.org/#/q/topic:new-release
>
> This is not marked a draft, yet I posted mostly as discussion material, I'm 
> not confident
> this is really (or completely) the proper way to go.
>
> Please share your thoughts.
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> ___
> 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] oVirt 4.0 Nightly repo

[Simone Tiraboschi]

On Wed, Jun 15, 2016 at 4:07 PM, Dan Kenigsberg <dan...@redhat.com> wrote:
> On Tue, Jun 14, 2016 at 03:14:03PM +0200, Simone Tiraboschi wrote:
>> All stable branch maintainers,
>> I just noticed that our oVirt 4.0 nightly repo (
>> http://resources.ovirt.org/pub/ovirt-4.0-snapshot/ ) still includes a
>> lot of packages from master branches.
>>
>> Can you please ensure that our jenkins is building your project
>> packages in order to compose the 4.0 nightly repo from a stable
>> branch?
>>
>> If not, you have to push a patch like https://gerrit.ovirt.org/59150/
>> to correctly configure the publisher job for 4.0 nightly.
>
> I see that Vdsm
> http://resources.ovirt.org/pub/ovirt-4.0-snapshot/rpm/el7Server/x86_64/
>
> has both (correct) 4.18.2 builds and misleading 4.18. ones such as
> vdsm-4.18.999-73.gitd35b8e7.el7.centos.x86_64.rpm
>
> Can you manually remove them? they hide the correct builds.

Done
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 4.0 Nightly repo

[Simone Tiraboschi]

All stable branch maintainers,
I just noticed that our oVirt 4.0 nightly repo (
http://resources.ovirt.org/pub/ovirt-4.0-snapshot/ ) still includes a
lot of packages from master branches.

Can you please ensure that our jenkins is building your project
packages in order to compose the 4.0 nightly repo from a stable
branch?

If not, you have to push a patch like https://gerrit.ovirt.org/59150/
to correctly configure the publisher job for 4.0 nightly.

thanks,
Simone
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 4.0 rc1 build planned

[Simone Tiraboschi]

Fyi oVirt developers,

An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM CEST).
Taking into consideration the time it takes for Jenkins to run a full
CI everything need to be backported by Monday 11PM.
Please make sure to mark as verified and CR +2 so it will be ready for
merging Tuesday morning.

https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.0%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost_id=5201498
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Flaky stompTests tests

[Simone Tiraboschi]

2016-04-25 20:15 GMT+02:00 Nir Soffer :
> Hi all,
>
> We see random failures in the stomp tests for long time.
>
> I suggest we mark these tests as broken for now.
>
> See examples at the end of the message.
>
> Nir
>
> 
>

> 17:14:24 
> ==
> 17:14:24 ERROR: test_event(False) (stompTests.StompTests)
> 17:14:24 
> --
> 17:14:24 Traceback (most recent call last):
> 17:14:24   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/testlib.py",
> line 74, in wrapper
> 17:14:24 return f(self, *args)
> 17:14:24   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/stompTests.py",
> line 110, in test_event
> 17:14:24 client.callMethod("event", [], str(uuid4()))
> 17:14:24   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/lib/yajsonrpc/__init__.py",
> line 340, in callMethod
> 17:14:24 raise JsonRpcNoResponseError(methodName)
> 17:14:24 JsonRpcNoResponseError: [-32605] No response for JSON-RPC
> event request.

I'd suggest to investigate this a bit more since it can hide a serious issue.
I'm moving hosted-engine-setup from XMLRPC to JsonRPC and I'm facing
exactly this kind of issue: it seams that some requests got lost and I
just receive a JsonRpcNoResponseError after a long time.
The real issue is that my request never reached VDSM getting lost
somehow in the queuing mechanism.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-announce] [ovirt-users] [ANN] oVirt 3.6.2 Third Release Candidate is now available for testing

[Simone Tiraboschi]

On Mon, Jan 25, 2016 at 2:18 PM, Gianluca Cecchi 
wrote:

> On Wed, Jan 20, 2016 at 12:59 PM, Sandro Bonazzola 
> wrote:
>
>> The oVirt Project is pleased to announce the availability
>> of the Third Release Candidate of oVirt 3.6.2 for testing, as of January
>> 20th, 2016
>>
>>
>>
> Tested successfully on CentOS 7.2 with SH Engine on NFS and verified
> correct auto-import of SH Domain.
> Hypervisor is a CentOS 7.2 VM inside Qemu/KVM in virt-manager (under my
> laptop that is Fedora 23).
> So it is a nested virtualization environment.
>
> Some NOTES
> 1) appliance
> I see that the appliance rpm pulled in was
>  ovirt-engine-appliance-3.6-20151216.1.el7.centos.noarch
>
> I presumed it was not populated with correct rpms.
> So in "hosted-engine --deploy" setup I used the appliance, but answered
>
> Automatically execute engine-setup on the engine appliance on first boot
> (Yes, No)[Yes]? No
>
> I then connect to the appliance OS and configure 3.6-pre repo and run
>
> yum update
>
> Strange that this pulled in the package
>
> ovirt-release36-003-1.noarch
>
> and so the repo file was overwritten and was again 3.6 only and not
> 3.6-pre.
> I re-modified /etc/yum.repos.d/ovirt-3.6.repo re-adding the pre.
>
> and finally
> engine-setup
>
> and successfully completed the final part on host.
>
> 2) localtime on Engine was not asked but was set to UTC.
> So
> [root@shengine ~]# ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
>
> shutdown engine OS and after some minutes the VM came back online.
>
>
You are right here: we are not copying the host timezone to the appliance:
we can do it via cloud-init.
Good catch!


> 3) As this is a nested environment with NFS domain provided by the only
> host itself,
> In /usr/lib/systemd/system/ovirt-ha-broker.service
>
> Agdded in section [Unit]
>
> After=nfs-server.service
> So that I can manage shutdown/restart of host for complete maintenance
> operations
>
> 4) After adding first data domain, the hosted_storage storage domain came
> up automatically without any problem. Able to see engine vm in web admin
> portal and its disk and access its console (used vnc)
> Also able to add ISO Domain.
> (both data and iso are NFS on the host itself)
>
> 5) The only "problem" (?) I see is this message that I don't understand.
> On hypervisors
>
> [root@ovc72 ~]# systemctl status ovirt-ha-agent -l
> ● ovirt-ha-agent.service - oVirt Hosted Engine High Availability
> Monitoring Agent
>Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-agent.service;
> enabled; vendor preset: disabled)
>Active: active (running) since Mon 2016-01-25 11:02:56 CET; 1h 0min ago
>  Main PID: 17138 (ovirt-ha-agent)
>CGroup: /system.slice/ovirt-ha-agent.service
>└─17138 /usr/bin/python
> /usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent --no-daemon
>
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Connecting
> storage server
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.lib.storage_server.StorageServer:Refreshing the
> storage domain
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Preparing
> images
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.lib.image.Image:Preparing images
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine:Reloading
> vm.conf from the shared storage domain
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> INFO:ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config:Trying
> to get a fresher copy of vm configuration from the OVF_STORE
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> WARNING:ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore:Unable to find
> OVF_STORE
> Jan 25 12:03:27 ovc72.localdomain.local ovirt-ha-agent[17138]:
> ovirt-ha-agent
> ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config ERROR Unable
> to get vm.conf from OVF_STORE, falling back to initial vm.conf
>
>
We will let you edit some of the engine VM parameters from the engine
itself.
All the modification will be saved as OVF file on a special volume called
OVF_STORE; when needed ovirt-ha-agent tries to get the up-to-date engine VM
configuration from there and if there is any issue it falls back to the
initial vm.conf from the setup time.
The issue is that by default OVF_STORE gets populated only after 1 hour and
so if you wait less than 1 hour you'll get that message since the OVF_STORE
is still not there.


> 6) ISO upload from engine by default doesn't work because its own host
> doesn't allow it
> [root@shengine ~]# ovirt-iso-uploader -i ISO_DOMAIN upload
> /root/CentOS-7-x86_64-NetInstall-1511.iso
> Please provide the REST API password for the admin@internal oVirt 

[ovirt-devel] oVirt 3.6.2 RC2 build planned

[Simone Tiraboschi]

Fyi oVirt developers,

An oVirt build is planned for this Tuesday 11:00 AM, please make sure to
backport
any open patches to the stable branch for review by the stable branch
maintainers.

Here's a list of open blockers:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A3.6.2%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 3.6.2 RC2 merge / tag / bugzilla reminder

[Simone Tiraboschi]

All stable branch maintainers, please make sure to  merge all relevant open
bugs until Tuesday morning 11:00 AM TLV time (10:00 CET).

https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A3.6.2%20target_release%3A---%20status%3Amodified%2Cpost


Every package build (i.e oVirt product) - please make sure every bug in
MODIFIED has the right Target Release and Target Milestone.
A Target release should state the version of the package you're building
and should include the same version you used for the tag you just used for
this build. (e.g. for ovirt-engine, tag will be: ovirt-engine-3.6.2, and
target release must be: 3.6.2)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] [QE] oVirt 3.6.1 Hosted Engine test day

[Simone Tiraboschi]

On Mon, Dec 14, 2015 at 4:39 PM, Gianluca Cecchi 
wrote:

> On Mon, Dec 14, 2015 at 4:10 PM, Sandro Bonazzola  wrote:
>
>>
>>>
>>> You should just activate it.
>>> Adding Roy, looks like this doesn't happen to me only.
>>>
>>>
>> See *Bug 1290518*  -
>>  failed Activating hosted engine domain during auto-import on NFS
>>
>>
> I confirm that I hit the bug and I was able to simply activate the storage
> domain and able to see the engine vm
>
> Dec 14, 2015 4:22:23 PM Hosted Engine VM was imported successfully
> Dec 14, 2015 4:22:23 PM Starting to import Vm HostedEngine to Data Center
> Default, Cluster Default
> Dec 14, 2015 4:22:19 PM Storage Domain hosted_storage (Data Center
> Default) was activated by admin@internal
>
>
> NOTES:
> 1) I configured the engine vm as a vnc one during install (in 3.6.0, as
> the appliance was the 3.6.0 one as we noted)
>
> [ INFO  ] Stage: Setup validation
>
>   --== CONFIGURATION PREVIEW ==--
>
>   Bridge interface   : eth0
>   Engine FQDN: shengine.localdomain.local
>   Bridge name: ovirtmgmt
>   SSH daemon port: 22
>   Firewall manager   : iptables
>   Gateway address: 192.168.122.1
>   Host name for web application  : hosted_engine_1
>   Host ID: 1
>   Image size GB  : 10
>   GlusterFS Share Name   : hosted_engine_glusterfs
>   GlusterFS Brick Provisioning   : False
>   Storage connection :
> ovc71.localdomain.local:/SHE_DOMAIN
>   Console type   : vnc
>   Memory size MB : 8192
>   MAC address: 00:16:3e:72:e7:26
>   Boot type  : disk
>   Number of CPUs : 1
>   OVF archive (for disk boot):
> /usr/share/ovirt-engine-appliance/ovirt-engine-appliance-3.6-20151211.1.el7.centos.ova
>   Restart engine VM after engine-setup: True
>   CPU Type   : model_Nehalem
>
>   Please confirm installation settings (Yes, No)[Yes]:
>
> but after import in 3.6.1 I see it configured as with spice console in web
> admin gui.
> I indeed am able to access it via spice, but just to notice that if one
> eventually would like to have it vnc, he/she has to edit the engine vm
> after update to 3.6.1.
> BTW: is it possible/supported to edit engine vm from the gui and change
> for example the console mode?
>
> 2) During setup, see above, it was configured with iptables as firewall
> manager
> During the update to 3.6.1 this was the workflow shown at video:
>
> [root@shengine ~]# engine-setup
> [ INFO  ] Stage: Initializing
> [ INFO  ] Stage: Environment setup
>   Configuration files:
> ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf',
> '/etc/ovirt-engine-setup.conf.d/10-packaging.conf',
> '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf']
>   Log file:
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20151214134331-ga1lxy.log
>   Version: otopi-1.4.0 (otopi-1.4.0-1.el7.centos)
> [ INFO  ] Stage: Environment packages setup
> [ INFO  ] Stage: Programs detection
> [ INFO  ] Stage: Environment setup
> [ INFO  ] Stage: Environment customization
>
>   --== PRODUCT OPTIONS ==--
>
>
>   --== PACKAGES ==--
>
> [ INFO  ] Checking for product updates...
>   Setup has found updates for some packages:
>   PACKAGE: [updated] ovirt-engine-3.6.0.3-1.el7.centos.noarch
> ...
>   PACKAGE: [update] ovirt-engine-wildfly-overlay-8.0.4-1.el7.noarch
>   do you wish to update them now? (Yes, No) [Yes]:
>  [ INFO  ] Checking for an update for Setup...
>
>   --== ALL IN ONE CONFIGURATION ==--
>
>   --== NETWORK CONFIGURATION ==--
>
>   Setup can automatically configure the firewall on this system.
>   Note: automatic configuration of the firewall may overwrite
> current settings.
>   Do you want Setup to configure the firewall? (Yes, No) [Yes]:
> [ INFO  ] firewalld will be configured as firewall manager.
>
> So the former setup was with iptables durinh sh engine setup in 3.6.0
> while then with firewalld in 3.6.1.
>
> In fact on the engine I see
>
>
> [root@shengine ~]# systemctl status iptables
> iptables.service
>Loaded: not-found (Reason: No such file or directory)
>Active: inactive (dead)
>
> [root@shengine ~]# systemctl status firewalld
> firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
>Active: active (running) since Mon 2015-12-14 14:19:56 UTC; 1h 15min ago
>  Main PID: 431 (firewalld)
>CGroup: 

Re: [ovirt-devel] SSO Setup

[Simone Tiraboschi]

On Tue, Dec 1, 2015 at 2:47 PM, Ravi Nori  wrote:

> Hi,
>
> Some of you have faced issues setting up engine after SSO patches were
> merged.
>
> Below are the issues and the proposed solutions on how to proceed.
>
> * Issue #1: Host name resolution.
>
> During setup make sure the engine FQDN that you provide can be resolved.
> If it cannot be resolved externally edit /etc/hosts and add an entry for
> your
> host name pointing to the local host ip address.
>

Here probably we could enforce it at engine-setup


>
> * Issue #2 : non-localized string ???pageheader.notLoggedIn?? in Ovirt
> landing page
>
> Do a fresh setup in a new directory on your dev machine. This fixes the
> issue.
> I am still investigating the cause.
>
> If you face addition issues please feel free to ping me or open a BZ.
>
> Thanks,
>
> Ravi
> ___
> 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] [vdsm] merge rights on master branch

[Simone Tiraboschi]

On Thu, Nov 19, 2015 at 8:13 AM, Vinzenz Feenstra 
wrote:

> On 11/17/2015 11:47 AM, Dan Kenigsberg wrote:
>
>> Nir Soffer has been contributing to Vdsm for more than two years now.
>> Beyond his storage-related expertise, he is well-known for his thorough
>> code reviews and his pains when the master branch is broken. It's time
>> for him to take even bigger responsibility.
>>
>> David, please grant Nir Soffer with merge rights on the master branch of
>> Vdsm.
>>
> +1
> Nir: Congrats :-)


Nir: well deserved!


>
>
>> I'll keep merging network, virt, and infra patches myself, but much less
>> than before. Adam keeps his merge right as before (he tends to use them
>> on emergencies only).
>>
>> Regards,
>> Dan.
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> --
> Regards,
>
> Vinzenz Feenstra | Senior Software Engineer
> RedHat Engineering Virtualization R & D
> Phone: +420 532 294 625
> IRC: vfeenstr or evilissimo
>
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Where should the answer file for the improved HE flow be located?

[Simone Tiraboschi]

On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David  wrote:

> On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch 
> wrote:
> > Hey,
> >
> > lately we had the issue that the answer file for the engine in the HE
> > flow changed (it required an additional answer).
>
> "in the HE flow" specifically?
>
> As discussed in private, this might best (?) be solved by adding an option
> to engine-setup which will make it accept the default answer for each
> question
> where a default is supplied.
>

Yes, this one is probably the best option but it requires to add an
additional CLI option and tweak otopi dialog to handle it if required so
the impact is not that small.
On my opinion is the way to go for 4.0 but for 3.6.0 it would be much
simpler to just add the missing value in the appliance answerfile.


>
> >
> > Currently the answerfile is maintained by node in the engine appliance.
> >
> > I wonder if it wouldn't make more sense to keep the answer file (which
> > is solely used for the HE flow) could be maintained inside the
> > hosted-engine-setup repository, and be packaged in a subpackage (i.e.
> > hosted-engine-setup-answers[-3.6]).
>
> IIUC the appliance is not specific to HE, right? Can be used independently.
>
> >
> > Another thought is that the HE-setup cloud-init is already referencing
> > the engine answerfile, if it was matained in the same package, then it
> > should also be easier to ensure that the assumed and real paths of the
> > answerfile match.
> >
> > So, if the answerfile was in that subpackage of HE-setup, we could
> > just install that specific package inside the appliance, and the rest
> > is left to the HE-setup logic.
>
> IMHO it would be best if we do not need to maintain this answerfile at all.
> If the existence of such an option would have been enough, I'd vote for
> adding it.
>
> Otherwise, I'd like to understand what, if at all, in the
> currently-maintained
> answerfile is HE-specific, and what is different from merely accepting the
> defaults.
>

When the user selects to deploy hosted-engine using the appliance we could
run engine-setup there in a not interactive way, to do that we need a least
an answerfile.
Currently we are using two:
- one is already inside the appliance, it contains all the appliance
defaults. It's there to loose the coupling between hosted-engine-setup and
engine-setup as much as possible
- the second contains user preferences (eg. the admin password) and it's
generated by hosted-engine-setup and injected via cloud-init

In this case is the appliance we got a new rpm (the serial console proxy)
witch requires an additional answer so, to keep that principle and couple
as less as possible, it's answer should go inside the appliance.

As Didi proposed the best long term solution is to have a default-only mode
in engine-setup so that we could get rid of the appliance answerfile.



> If we do agree eventually that such an answerfile needs to be maintained
> manually, I agree with Tolik, who said in a private discussion that it
> should
> be maintained inside the package of engine-setup. Perhaps we even need more
> than one such file, depending on the answers to above :-)
>
> Best,
> --
> Didi
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck on 100% while vdsmd indefinitely tries to restart

[Simone Tiraboschi]

Hi,
I tried to have hosted-engine deploying the engine appliance over oVirt node. I 
think it will be quite a common scenario.
I tried with an oVirt node build from yesterday.

Unfortunately I'm not able to conclude the setup cause oVirt node got the CPU 
load indefinitely stuck on 100% and so it's almost unresponsive.

The issue seams to be related to vdsmd daemon witch couldn't really start and 
so it retries indefinitely using all the available CPU power (it also runs with 
niceless -20...).

[root@node36 admin]# grep Unit vdsmd.service entered failed state. 
/var/log/messages  | wc -l
368
It tried 368 times in a row in a few minutes.

With journalctl I can read:
May 29 10:06:45 node36 systemd[1]: Unit vdsmd.service entered failed state.
May 29 10:06:45 node36 systemd[1]: vdsmd.service holdoff time over, scheduling 
restart.
May 29 10:06:45 node36 systemd[1]: Stopping Virtual Desktop Server Manager...
May 29 10:06:45 node36 systemd[1]: Starting Virtual Desktop Server Manager...
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running mkdirs
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
configure_coredump
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
configure_vdsm_logs
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
wait_for_network
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running run_init_hooks
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
upgraded_version_check
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
check_is_configured
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
validate_configuration
May 29 10:06:47 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
prepare_transient_repository
May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
syslog_available
May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running nwfilter
May 29 10:06:50 node36 vdsmd_init_common.sh[13697]: vdsm: Running dummybr
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running 
load_needed_modules
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running tune_system
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running test_space
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running test_lo
May 29 10:06:51 node36 systemd[1]: Started Virtual Desktop Server Manager.
May 29 10:06:51 node36 systemd[1]: vdsmd.service: main process exited, 
code=exited, status=1/FAILURE
May 29 10:06:51 node36 vdsmd_init_common.sh[13821]: vdsm: Running 
run_final_hooks
May 29 10:06:52 node36 systemd[1]: Unit vdsmd.service entered failed state.
May 29 10:06:52 node36 systemd[1]: vdsmd.service holdoff time over, scheduling 
restart.
May 29 10:06:52 node36 systemd[1]: Stopping Virtual Desktop Server Manager...
May 29 10:06:52 node36 systemd[1]: Starting Virtual Desktop Server Manager...
repeated a lot of times

/var/log/vdsm/vdsm.log is empty.

while
[root@node36 admin]# /usr/share/vdsm/daemonAdapter -0 /dev/null -1 /dev/null -2 
/dev/null /usr/share/vdsm/vdsm; echo $?
1


ciao,
Simone
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck on 100% while vdsmd indefinitely tries to restart

[Simone Tiraboschi]

- Original Message -
 From: Nir Soffer nsof...@redhat.com
 To: Simone Tiraboschi stira...@redhat.com
 Cc: devel@ovirt.org, Fabian Deutsch fdeut...@redhat.com
 Sent: Friday, May 29, 2015 5:45:48 PM
 Subject: Re: [ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck on 
 100% while vdsmd indefinitely tries to
 restart
 
 
 
 - Original Message -
  From: Simone Tiraboschi stira...@redhat.com
  To: Nir Soffer nsof...@redhat.com
  Cc: devel@ovirt.org, Fabian Deutsch fdeut...@redhat.com
  Sent: Friday, May 29, 2015 6:42:08 PM
  Subject: Re: [ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck
  on 100% while vdsmd indefinitely tries to
  restart
  
  
  
  - Original Message -
   From: Nir Soffer nsof...@redhat.com
   To: Simone Tiraboschi stira...@redhat.com
   Cc: devel@ovirt.org, Fabian Deutsch fdeut...@redhat.com
   Sent: Friday, May 29, 2015 5:26:52 PM
   Subject: Re: [ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck
   on 100% while vdsmd indefinitely tries to
   restart
   
   - Original Message -
From: Simone Tiraboschi stira...@redhat.com
To: devel@ovirt.org
Cc: Fabian Deutsch fdeut...@redhat.com
Sent: Friday, May 29, 2015 1:44:02 PM
Subject: [ovirt-devel] oVirt node 3.6 and CPU load indefinitely stuck
on
100% while vdsmd indefinitely tries to
restart

Hi,
I tried to have hosted-engine deploying the engine appliance over oVirt
node.
I think it will be quite a common scenario.
I tried with an oVirt node build from yesterday.

Unfortunately I'm not able to conclude the setup cause oVirt node got
the
CPU
load indefinitely stuck on 100% and so it's almost unresponsive.

The issue seams to be related to vdsmd daemon witch couldn't really
start
and
so it retries indefinitely using all the available CPU power (it also
runs
with niceless -20...).

[root@node36 admin]# grep Unit vdsmd.service entered failed state.
/var/log/messages  | wc -l
368
It tried 368 times in a row in a few minutes.

With journalctl I can read:
May 29 10:06:45 node36 systemd[1]: Unit vdsmd.service entered failed
state.
May 29 10:06:45 node36 systemd[1]: vdsmd.service holdoff time over,
scheduling restart.
May 29 10:06:45 node36 systemd[1]: Stopping Virtual Desktop Server
Manager...
May 29 10:06:45 node36 systemd[1]: Starting Virtual Desktop Server
Manager...
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running
mkdirs
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running
configure_coredump
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running
configure_vdsm_logs
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running
wait_for_network
May 29 10:06:45 node36 vdsmd_init_common.sh[13697]: vdsm: Running
run_init_hooks
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running
upgraded_version_check
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running
check_is_configured
May 29 10:06:46 node36 vdsmd_init_common.sh[13697]: vdsm: Running
validate_configuration
May 29 10:06:47 node36 vdsmd_init_common.sh[13697]: vdsm: Running
prepare_transient_repository
May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running
syslog_available
May 29 10:06:49 node36 vdsmd_init_common.sh[13697]: vdsm: Running
nwfilter
May 29 10:06:50 node36 vdsmd_init_common.sh[13697]: vdsm: Running
dummybr
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running
load_needed_modules
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running
tune_system
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running
test_space
May 29 10:06:51 node36 vdsmd_init_common.sh[13697]: vdsm: Running
test_lo
May 29 10:06:51 node36 systemd[1]: Started Virtual Desktop Server
Manager.
May 29 10:06:51 node36 systemd[1]: vdsmd.service: main process exited,
code=exited, status=1/FAILURE
May 29 10:06:51 node36 vdsmd_init_common.sh[13821]: vdsm: Running
run_final_hooks
May 29 10:06:52 node36 systemd[1]: Unit vdsmd.service entered failed
state.
May 29 10:06:52 node36 systemd[1]: vdsmd.service holdoff time over,
scheduling restart.
May 29 10:06:52 node36 systemd[1]: Stopping Virtual Desktop Server
Manager...
May 29 10:06:52 node36 systemd[1]: Starting Virtual Desktop Server
Manager...
repeated a lot of times

/var/log/vdsm/vdsm.log is empty.

while
[root@node36 admin]# /usr/share/vdsm/daemonAdapter -0 /dev/null -1
/dev/null
-2 /dev/null /usr/share/vdsm/vdsm; echo $?
1
   
   Can you try to run vdsm manually from the shell?
   
   # /usr/share/vdsm/vdsm
   
   Typically you would see a python traceback explaining the failure.
  
  I tried and it just fails.
  Exit code is 1

Re: [ovirt-devel] Error in engine-setup in ovirt 3.5

[Simone Tiraboschi]

- Original Message -
 From: Simone Tiraboschi stira...@redhat.com
 To: Shmuel Melamud smela...@redhat.com
 Cc: Yedidyah Bar David ybard...@redhat.com, devel@ovirt.org
 Sent: Thursday, May 7, 2015 10:50:32 AM
 Subject: Re: [ovirt-devel] Error in engine-setup in ovirt 3.5
 
 
 
 - Original Message -
  From: Shmuel Melamud smela...@redhat.com
  To: devel@ovirt.org, Yedidyah Bar David ybard...@redhat.com
  Sent: Thursday, May 7, 2015 10:26:39 AM
  Subject: [ovirt-devel] Error in engine-setup in ovirt 3.5
  
  Hi!
  
  Can you help me with this? I'm trying to install oVirt 3.5.3. I've built
  the
  Engine in a separate directory, created a separate DB and now running
  /home/smelamud/engine-root/3.5/bin/engine-setup. After answering all
  questions I get:
  
--== OVIRT ENGINE CONFIGURATION ==--
  
Skipping storing options as database already prepared
  
--== PKI CONFIGURATION ==--
  
Organization name for certificate [tlv.redhat.com]:
  
--== APACHE CONFIGURATION ==--
  
  
--== SYSTEM CONFIGURATION ==--
  
  
--== MISC CONFIGURATION ==--
  
  
--== END OF CONFIGURATION ==--
  
  [ INFO  ] Stage: Setup validation
  [WARNING] Less than 16384MB of memory is available
  [ INFO  ] Cleaning stale zombie tasks and commands
  [ ERROR ] Failed to execute stage 'Setup validation': LooseVersion instance
  has no attribute 'version'
  [ INFO  ] Stage: Clean up
Log file is located at

  /home/smelamud/engine-root/3.5/var/log/ovirt-engine/setup/ovirt-engine-setup-20150506180037-z9jn82.log
  [ INFO  ] Generating answer file
  '/home/smelamud/engine-root/3.5/var/lib/ovirt-engine/setup/answers/20150506180209-setup.conf'
  [ INFO  ] Stage: Pre-termination
  [ INFO  ] Stage: Termination
  [ ERROR ] Execution of setup failed
  
  Looks like some bug in engine-setup.
 
 Ok, got it.
 on engine-setup we need to discriminate if we are upgrading or if we are
 deploying for the first time: generally we do it identifying it you have an
 existing DB instance from a previous setup and you have it cause you
 manually created.
 So engine-setup assumes that is an upgrade but something is missing (in this
 precise case, info about the previously uninstalled release from postinstall
 file) and so it fails.
 If you need I can help to forcefully complete that setup but is not really a
 supported configuration on user side.

Adding
OVESETUP_ASYNC/clearTasks=bool:False
to your answerfile should be enough to workaround on that.
 
  Log file is attached.
  
  --
  Shmuel
  
  ___
  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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status (building RC2 today!)

[Simone Tiraboschi]

- Original Message -
 From: Oved Ourfali oourf...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com, Simone Tiraboschi 
 stira...@redhat.com
 Cc: us...@ovirt.org, Ido Barkan ibar...@redhat.com, Francesco Romani 
 from...@redhat.com, Eli Mesika
 emes...@redhat.com, Maor Lipchuk mlipc...@redhat.com, devel@ovirt.org, 
 Adam Litke ali...@redhat.com,
 Vered Volansky vvola...@redhat.com
 Sent: Wednesday, March 18, 2015 9:18:14 AM
 Subject: Re: [ovirt-devel] [ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status 
 (building RC2 today!)
 
 
 On Mar 18, 2015 9:57 AM, Sandro Bonazzola sbona...@redhat.com wrote:
 
  Hi,
  we still have 5 open blockers for 3.5.2[1]:
 
  Bug ID Whiteboard Status Summary
  1161012 infra POST task cleaning utility  should erase commands that have
  running tasks
 
 Simone, latest comment by you implies that it is working now with the latest
 patches. All appear in the bugzilla as merged. Should it move to modified?

We were missing the cherry-pick to 3.5.2; I did it right now.

Than verifying it we found another issue.
I order to generate a zombie task we suddenly bring down an host during a 
template creation so we got a task that will never end.
Now taskcleaner correctly detects it and it clean it up and so the user can 
continue with the upgrade.

The issue is that, on this specific case, the VM got locked for template 
creation and than no one apply for unlocking it and so it remains locket for 
template creation also without any pending task.
We opened a new bug for that:
https://bugzilla.redhat.com/show_bug.cgi?id=1202333



  1187244 network POST [RHEL  7.0 + 7.1] Host configure with DHCP is losing
  connectivity after some time - dhclient is not running
  1177220 storage ASSIGNED [BLOCKED] Failed to Delete First snapshot with
  live merge
  1196327 virt ASSIGNED [performance] bad getVMList output creates
  unnecessary calls from Engine
  1202360 virt POST [performance] bad getVMList output creates unnecessary
  calls from Engine
 
  And 2 dependency on libvirt not yet fixed:
  Bug ID Status Summary
  1199182 POST 2nd active commit after snapshot triggers qemu failure
  1199036 POST Libvirtd was restarted when do active blockcommit while there
  is a blockpull job running
 
  ACTION: Assignee to provide ETA for the blocker bug.
 
  Despite the blockers bug count, we're going to build RC2 today 2015-03-18
  at 12:00 UTC for allowing the verification of fixed bugs and testing on
  CentOS 7.1.
  If you're going to test this release candidate on CentOS please be sure to
  have the CR[2] repository enabled and system fully updated to CentOS 7.1.
 
  We still have 7 bugs in MODIFIED and 31 on QA[3]:
 
  MODIFIED ON_QA Total
  infra 2 10 12
  integration 0 2 2
  network 0 2 2
  node 0 1 1
  sla 2 1 3
  storage 3 11 14
  virt 0 4 4
  Total 7 31 38
 
  ACTION: Testers: you're welcome to verify bugs currently ON_QA.
 
  All remaining bugs not marked as blockers have been moved to 3.5.3.
  A release management entry has been added for tracking the schedule of
  3.5.3[4]
  A bug tracker [5] has been created for 3.5.3.
  We have 32 bugs currently targeted to 3.5.3[6]:
 
  Whiteboard NEW ASSIGNED POST Total
  docs 2 0 0 2
  external 1 0 0 1
  gluster 4 0 1 5
  infra 2 2 0 4
  node 2 0 1 3
  ppc 0 0 1 1
  sla 4 0 0 4
  storage 8 0 0 8
  ux 1 0 1 2
  virt 1 0 1 2
  Total 25 2 5 32
 
 
  ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3
  ensuring they're correctly targeted.
  ACTION: Maintainers: to fill release notes for 3.5.2, the page has been
  created and updated here [7]
  ACTION: Testers: please add yourself to the test page [8]
 
  7 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch
  according to Change-Id
 
  commit 6b5a8169093357656d3e638c7018ee516d1f44bd
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Thu Feb 19 14:40:23 2015 +0200
      core: Add validation when Storage Domain is blocked.
      Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f
 
  commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Sun Mar 1 17:17:16 2015 +0200
      restapi: reconfigure values on import data Storage Domain.
      Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b
 
  commit 4283f755e6b77995247ecb9ddd904139bc8c322c
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Tue Mar 10 12:05:05 2015 +0200
      restapi: Quering FCP unregistered Storage Domains
      Change-Id: Iafe2f2afcd0e6e68ad2054c857388acc30a7
 
  commit a3d8b687620817b38a64a3917f4440274831bca3
  Author: Maor Lipchuk mlipc...@redhat.com
  Date:   Wed Feb 25 17:00:47 2015 +0200
      core: Add fk constraint on vm_interface_statistics
      Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8
 
  commit c8caaceb6b1678c702961d298b3d6c48183d9390
  Author: emesika emes...@redhat.com
  Date:   Mon Mar 9 18:01:58 2015 +0200
      core: do not use distinct if sort expr have func
      Change-Id

Re: [ovirt-devel] oVirt node, hosted-engine, oVirt appliance and cloud-init

[Simone Tiraboschi]

- Original Message -
 From: Bob Doolittle b...@doolittle.us.com
 To: Simone Tiraboschi stira...@redhat.com, devel@ovirt.org, users-ovirt 
 us...@ovirt.org
 Cc: Fabian Deutsch fdeut...@redhat.com
 Sent: Thursday, March 12, 2015 3:54:27 PM
 Subject: Re: [ovirt-devel] oVirt node, hosted-engine, oVirt appliance and 
 cloud-init
 
 On 03/12/2015 10:02 AM, Simone Tiraboschi wrote:
  Hi all,
  cloud-init is a powerful tool to configure from outside a cloud instance or
  an appliance as in our scenario.
 
  Deploying the engine as an appliance is indeed a good way to speed up and
  make easier the hosted-engine deployment: you don't need to install an OS
  on the engine virtual machine and than install the engine and so on but
  you could simply run a ready to use oVirt engine appliance. But you still
  need to configure it and so cloud-init support within hosted-engine is a
  reasonable way to complement it.
 
  Then we could also integrate it with oVirt node to let the user input the
  required info from node TUI in order to have an almost unattended
  hosted-engine setup on oVirt node using an engine appliance with
  cloud-init.
 
  The idea is to collect the required information interactively from
  hosted-engine setup or from node TUI (passing them to hosted-engine setup
  via an answer file) and pass them to the appliance via cloud-init using a
  no-cloud datasource.
 
  So now the question is what do you really want to configure via cloud-init?
  It's just to define what we want in order to be more focused on user needs:
  for instance we could configure engine VM instance hostname, we could set
  the root password, we could create other users, we could upload ssh
  private keys, we could run a command on the first boot and so on.
  So, if you have any ideas or requirement about that it's the right time for
  it.
 
 Great suggestions, Simone!
 
 The things you list cover most of what I do to the engine VM (I do all of
 those except for configure ssh private keys). In addition, I:
 
   * Add a couple of packages (e.g. zsh)
   * Configure alternate shells for some initial users (this could be run a
   command on the first boot, as long as adding the necessary packages was
   done before that somehow, perhaps simply as a prior command)
   * Populate some specific files, e.g.:
   o Add specific ssh *public* keys into the $HOME/.ssh/authorized_keys
   files for some user and root accounts
   o Replace /etc/hosts with a master copy that contains all hosts on my
   network
 
 
 I'd like to see the additional packages abstracted out somehow and added
 prior to the run a command on the first boot step, as opposed to using
 yum explicitly for one of those commands, but that's somewhat of a
 cosmetic nice to have since obviously it can be done explicitly. It's
 separate conceptually, so would be nice to treat as such.

It's already designed like that in cloud-init:
http://cloudinit.readthedocs.org/en/latest/topics/examples.html#install-arbitrary-packages

 I'm learning Puppet at the moment, and it strikes me that what you want to do
 is pretty much the same thing that Puppet manifests are designed to do.

You could also setup an run puppet from cloud-init:
http://cloudinit.readthedocs.org/en/latest/topics/examples.html#setup-and-run-puppet

 Thanks,
Bob
 
 
  thanks,
  Simone
 
 
 
 
  ___
  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] [QE][ACTION NEEDED] oVirt 3.5.2 RC status - postponing

[Simone Tiraboschi]

- Original Message -
 From: Oved Ourfali oourf...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com
 Cc: yzasl...@redhat.com, devel@ovirt.org, us...@ovirt.org, Simone 
 Tiraboschi stira...@redhat.com
 Sent: Tuesday, February 24, 2015 4:23:37 PM
 Subject: Re: [ovirt-devel] [QE][ACTION NEEDED] oVirt 3.5.2 RC status - 
 postponing
 
 
 On Feb 24, 2015 4:54 PM, Sandro Bonazzola sbona...@redhat.com wrote:
 
  Hi,
  We still have one open blocker for 3.5.2[1]:
 
  Bug ID Whiteboard Status Summary
  1161012 infra POST task cleaning utility  should erase commands that have
  running tasks
 
 
 Yair and Simone, what's blocking this one from getting merged?

This one:
https://gerrit.ovirt.org/#/c/37847/2/packaging/setup/dbutils/taskcleaner.sh

On my opinion, it's still not the right behavior on upgrades.

  We need to postpone the RC until this will be fixed.
  The patch is already under review and verification so it shouldn't take too
  much.
 
 
  There are still 48 bugs [2] targeted to 3.5.2.
  Excluding node and documentation bugs we still have 42 bugs [3] targeted to
  3.5.2.
 
  Whiteboard NEW ASSIGNED POST Total
  doc 1 0 0 1
  docs 1 0 0 1
  gluster 4 0 1 5
  infra 4 2 8 14
  integration 0 0 1 1
  network 1 1 0 2
  node 4 0 1 5
  ppc 0 0 1 1
  sla 4 0 0 4
  storage 11 0 0 11
  ux 1 0 0 1
  virt 1 0 1 2
  Total 32 3 13 48
 
 
  Maintainers / Assignee:
  - Please add the bugs to the tracker if you think that 3.5.2 should not be
  released without them fixed.
  - Please update the target to 3.5.3 or later for bugs that won't be in
  3.5.2:
    it will ease gathering the blocking bugs for next releases.
  - Please fill release notes, the page has been created and updated here [4]
 
  Community:
  - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the
  test page [5]
 
  [1] http://bugzilla.redhat.com/1186161
  [2] http://goo.gl/crVJPH
  [3] http://goo.gl/2qTZZU
  [4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes
  [5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing
 
  --
  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

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt on el6 and novcn rpm from epel

[Simone Tiraboschi]

Hi All,
two days ago novnc rpm has been retired from EPEL-6 [1]. We have a dependencies 
from it and some user is already complaining he cannot install oVirt 3.5.0 on 
Centos 6.6.

The reason seams a broken deps on openstack-nova-novncproxy-0.4-2.el6.noarch [2]

[1] - https://admin.fedoraproject.org/pkgdb/package/novnc/
[2] - http://pkgs.fedoraproject.org/cgit/novnc.git/commit/?h=el6

What should we do?
a. include and maintain it on our repo
b. find somebody else to maintain on EPEL-6
c. release the dependencies if not really needed

ciao,
Simone
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Propose Shirly Radco as DWH Reports Maintainer.

[Simone Tiraboschi]

- Original Message -
 From: Yaniv Dary yd...@redhat.com
 To: devel@ovirt.org, infra in...@ovirt.org
 Sent: Thursday, September 18, 2014 2:02:19 PM
 Subject: [ovirt-devel] Propose Shirly Radco as DWH  Reports Maintainer.
 
 Hi,
 Shirly Radco has contributed many features, bug fixes and documentation
 enhancements for DWH  Reports
 and has taken a major role in the project progress and management in the last
 9 months.
 
 I would like to propose Shirly as a  DWH  Reports projects Maintainer.

+1
Well deserved!

 I would like to thank Shirly for her great contribution and hope she will
 keep up the good work!
 
 
 
 
 ---
 Yaniv Dary
 BI Software Engineer
 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 : Yaniv D
 ___
 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] [ovirt-users] oVirt 3.5 test day 2 results

[Simone Tiraboschi]

- Original Message -
 From: Jiri Belka jbe...@redhat.com
 To: Simone Tiraboschi stira...@redhat.com
 Cc: users us...@ovirt.org, devel@ovirt.org
 Sent: Thursday, July 31, 2014 8:26:20 AM
 Subject: Re: [ovirt-users] [ovirt-devel] oVirt 3.5 test day 2 results
 
   '...no so usable', this is joke. It's real design failure. Do not take
   this personally but whoever approved this did bad job.
  
  No, of course: I'm not so proud of it too. :-)
  
  A previous attempt used ssh and scp to do all automatically but it was
  rejected being judged not so secure.
  Avoiding to use ssh and scp so seams a strong requirement; if you have any
  better idea feel free to propose it.
 
 I will not repeat myself again in details, all setup should be done from
 Admin portal, same was one adds a host.
 
 Anyway, job spent time on this work is useless. I hope it will be moved
 to trash bin, this is ridiculous.
 
 What is obvious is that who designed this is not UNIX sysadmin oriented
 junkie.
 
 j.
 

The big part of this task was indeed to properly complete the modularization of 
engine setup: now you can run engine-setup only for the websocket-proxy stuff 
and it don't try anymore to setup jboss AS and DBMS stuff as it did in the 
past. We need that in any case.
The work on the console UI for websocket proxy cert was quite small since the 
'interface' is really simple.

Of course we can do better, but I'm not so sure we really need it now.

Actual solution can be judged cumbersome but I think that only a few sysadmin 
are really going to install the websocket proxy on a separate host; I'm almost 
sure that they aren't going to move it one day on an host and one day on 
another so a bit of manual work on my opinion can be acceptable on that.

Simone



___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] oVirt 3.5 test day 2 results

[Simone Tiraboschi]

- Original Message -
 From: Sven Kieske svenkie...@gmail.com
 To: devel@ovirt.org
 Sent: Thursday, July 31, 2014 3:35:08 PM
 Subject: Re: [ovirt-devel] [ovirt-users]  oVirt 3.5 test day 2 results
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 30.07.2014 18:14, Simone Tiraboschi wrote:
  A previous attempt used ssh and scp to do all automatically but it
  was rejected being judged not so secure.
 So who judged it?
 Maybe he/she could share some
 reasoning how this could be more
 insecure and more error prone
 than a clumsy do-this-by-hand-setup ?

I just discussed it with Alon as it involves security concerns.
I think we found a good compromise adding also the opportunity to save the CSR 
into a file still asking to the user to manually transfer and sign it on the 
other host.
I'm going to fix it.


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 3.5 test day 2 results

[Simone Tiraboschi]

Thanks Francesco,
some comments between the lines.


- Original Message -
 From: Francesco Romani from...@redhat.com
 To: users us...@ovirt.org, devel@ovirt.org
 Sent: Tuesday, July 29, 2014 5:42:06 PM
 Subject: [ovirt-devel] oVirt 3.5 test day 2 results
 
 Hi everyone,
 
 Hi tested again
 http://www.ovirt.org/Features/WebSocketProxy_on_a_separate_host
 
 What happened on tast day 1
 * found minor packaging issues
 * stopped earlier facing SSL issues, had a followup the day after an managed
 to have the feature working.
 
 This time things got better, and again the feature works as expected.
 
 The packaging issues are gone, but I still had UX annoyances along the way.
 
 I followed instructions on the wiki page above.
 Platform:
 F20 hypervisor host
 F20 engine host
 F19 websocket proxy
 (Didn't had time to test on different platforms because local bandwith issues
 eat lot of time just to install things)
 
 Installation went fine.
 
 websocket proxy setup is maybe a bit clumsy (I mean the text mode wizard),
 but it is bearable
 (I don't mind at all, but someone else can...);

We choose that way to avoid to ask to the user to provide the root password of 
the engine host, in order to automatically copying files via SCP or executing 
commands over ssh on the remote host, for security reasons.
I agree with you that due to that assumption this result is not so usable.

 for some reasons (I cannot exclude an error from mine) engine got configured
 to use localhost as websocket proxy.

As a default value, engine-setup configure the engine to look for a websocket 
proxy on localhost. The setup on the two host are asynchronous but we always 
need a value for the websocket proxy location so we use localhost as the 
default value for that.
On the second host, setting up the websocket proxy, engine-setup produces all 
the command that the user have to run on the engine host in order to enroll the 
certificate and to have it pointing to the right websocket proxy.

That command in my case is:
   engine-config -s WebSocketProxy=f19t6.localdomain:6100
and should be enough to configure the websocket proxy location without manually 
touching the DB.

I tried to reproduce and I also encountered the problem you stated: the engine 
still points to localhost for websocket proxy.
Going deeper, 'engine-config -g WebSocketProxy' already returns the new correct 
value but the web console still points on localhost.

Now I had to reload the whole engine to make that property effective; if I 
remember correctly with past release it was enough to change the property value 
without reloading it.
I'm reporting a bug for that: https://bugzilla.redhat.com/1124851

 To fix this I edited the engine config (update on DBMS), but then faced this
 error on proxy side:
 
 Jul 29 17:13:14 shinji ovirt-websocket-proxy.py[17004]: 1: handler exception:
 [Errno 1] _ssl.c:504: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
 shared cipher
 
 to redo the websocket setup I removed (actually renamed)
 /etc/pki/ovirt-engine and rerun setup.
 
 After that everything worked fine
 
 Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 8: connecting to:
 192.168.1.53:5900 (using SSL)
 Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177:
 SSL/TLS (wss://) WebSocket connection
 Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177:
 Version hybi-13, base64: 'False'
 Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177:
 Path: '/eyJ2YWxpZFRvIjoiMjAxNDA3MjkxNTIx [...]
 
 192.168.1.53 is the hypervisor host I used
 
 Now the point is maybe I did some mistakes or overlooked some configuration
 steps
 (maybe blindly hit return instead of changing a default), but I suggest to
 improve
 the docs/wiki to document how to fix common gotchas and/or to reconfigure
 things.

ok, I'll do.

 Bests,
 
 --
 Francesco Romani
 RedHat Engineering Virtualization R  D
 Phone: 8261328
 IRC: fromani
 ___
 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

[ovirt-devel] oVirt 3.5 test day 2 results - spice-html5 button to show debug console/output window - 1108599

[Simone Tiraboschi]

Hi,
I had to test the presence of a button to show the debug output for the 
spice-html5 console.

I created a setup with two host (the first with the engine in all-in-one 
fashion and the second with just a websocket proxy).
I launched a VM and I tried to open the spice-html5 console.

The new button is present and it's able to toggle an element with some text.

The main issue is that also if everything is ok, it shows a lot of noise 
warnings about unimplemented functions and similar stuff (see fig_ok.png).
If I enable a firewall to isolate the websocket proxy instead I can read only 
Websocket.onerror and, at least on my perception, it's not so useful to debug 
the cause (see fig_fault.png).

So the button is there but we should double check what to show on errors.

ciao,
Simone

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Yum repo file page

[Simone Tiraboschi]

Yes and no, resources is basically only a view over a file tree: we cannot add 
comments and notes as in the wiki.

Simone


- Original Message -
From: Brian Proffitt bprof...@redhat.com
To: Simone Tiraboschi stira...@redhat.com
Cc: Sandro Bonazzola sbona...@redhat.com, devel@ovirt.org
Sent: Friday, July 11, 2014 5:06:47 PM
Subject: Re: [ovirt-devel] Yum repo file page

Is there anywhere in resources that this information can be found?

BKP

- Original Message -
 From: Simone Tiraboschi stira...@redhat.com
 To: Sandro Bonazzola sbona...@redhat.com
 Cc: devel@ovirt.org, Brian Proffitt bprof...@redhat.com
 Sent: Friday, July 11, 2014 6:36:52 AM
 Subject: Re: [ovirt-devel] Yum repo file page
 
 It's not linked to any other page but is the first results that I get if I
 search ovirt yum repo and so it can be useful for some users.
 
 Maybe instead of showing there the content of the repo file we can just show
 a link to more stable content like http://resources.ovirt.org/pub/yum-repo/
 or something similar with a minimal comment. So we can reduce the chance we
 need to update it but at the same time we still provide a quick link for who
 just need that.
 
 ciao,
 Simone
 
 
 - Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: devel@ovirt.org, Brian Proffitt bprof...@redhat.com
 Sent: Friday, July 11, 2014 9:14:37 AM
 Subject: [ovirt-devel] Yum repo file page
 
 Hi,
 I propose deletion of http://www.ovirt.org/Yum_repo_file
 It's not linked by other pages[1] and keeping it will means that for each
 change in ovirt-release project the wiki page must be updated accordingly.
 Any objection?
 
 [1]
 http://www.ovirt.org/index.php?title=Special%3AWhatLinksHeretarget=Yum_repo_filenamespace=
 
 --
 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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Yum repo file page

[Simone Tiraboschi]

It's not linked to any other page but is the first results that I get if I 
search ovirt yum repo and so it can be useful for some users.

Maybe instead of showing there the content of the repo file we can just show a 
link to more stable content like http://resources.ovirt.org/pub/yum-repo/ or 
something similar with a minimal comment. So we can reduce the chance we need 
to update it but at the same time we still provide a quick link for who just 
need that.

ciao,
Simone


- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: devel@ovirt.org, Brian Proffitt bprof...@redhat.com
Sent: Friday, July 11, 2014 9:14:37 AM
Subject: [ovirt-devel] Yum repo file page

Hi,
I propose deletion of http://www.ovirt.org/Yum_repo_file
It's not linked by other pages[1] and keeping it will means that for each 
change in ovirt-release project the wiki page must be updated accordingly.
Any objection?

[1] 
http://www.ovirt.org/index.php?title=Special%3AWhatLinksHeretarget=Yum_repo_filenamespace=

-- 
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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [test day] day 1 results

[Simone Tiraboschi]

Hi,
during the test day I should test 
https://bugzilla.redhat.com/show_bug.cgi?id=1108599 - OVIRT35 - [RFE] 
[spice-html5] spice-html5 js client is dumb: no error about network connection 
issue

However I wasn't able to get a working test plant due to network troubles.
I'm on fully virtualized setup with two fedora 19 VM on KVM with nested 
virtualization.
Engine got installed correctly on the first host but I wasn't able to add the 
second VM as an hypervisor.
Trying to do that network connectivity get lost on the second VM.
I tried more than once always with the same result.

I opened a bug for that:
https://bugzilla.redhat.com/show_bug.cgi?id=1115420

Still not comment on the spice-html5 feature cause I'm still not able to test 
it.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel