Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1572542 - argument vlan_tag is of type <type 'str'> and we were unable to convert to int: invalid literal for int() with base 10: '8000\\\\n1'\"}"
Summary: argument vlan_tag is of type <type 'str'> and we were unable to convert to in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: General
Version: 2.2.16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-4.2.4
: 2.2.21
Assignee: Ido Rosenzwig
QA Contact: Nikolai Sednev
URL:
Whiteboard:
Depends On:
Blocks: ovirt-hosted-engine-setup-2.2.22
TreeView+ depends on / blocked
 
Reported: 2018-04-27 09:43 UTC by Petr Balogh
Modified: 2018-06-26 08:41 UTC (History)
7 users (show)

Fixed In Version: ovirt-hosted-engine-setup-2.2.21
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-06-26 08:41:18 UTC
oVirt Team: Integration
rule-engine: ovirt-4.2+
rule-engine: exception+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 90929 0 master MERGED Ansible: search for vlan tag more accurately 2018-09-03 09:33:16 UTC
oVirt gerrit 90955 0 ovirt-hosted-engine-setup-2.2 MERGED Ansible: search for vlan tag more accurately 2018-05-07 08:11:16 UTC

Comment 1 Petr Balogh 2018-04-27 09:52:13 UTC
This appeared when we ran our job for he deployment for second time before before we failed with unclean HE SD. Now running from scratch again with provisioning of all our hosts. Will update if I will hit the same issue for first time of running deployment.

Comment 2 Yaniv Kaul 2018-04-28 18:44:51 UTC
Please refrain from pasting such long logs, only the relevant sections.
Can you describe the steps to reproduce, if any?

Comment 3 Petr Balogh 2018-04-28 18:58:13 UTC
As I told in previous comment it happened after second run of hosted-engine --deploy when in the first attempt we failed on uncleaned SD. When I ran our job from scratch where we cleaned HE storages before and provisioned all the machines I didn't didn't hit the issue again.  So most probably it will happen when you are running this command for second time.

Comment 4 Yaniv Lavi 2018-04-30 07:25:39 UTC
Did it work if you use the cleanup script?

Comment 5 Petr Balogh 2018-04-30 11:01:21 UTC
Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this SD manually and run everything from scratch with provisioning of machines and so.. and didn't hit this issue again.

Comment 6 Nikolai Sednev 2018-04-30 11:10:53 UTC
(In reply to Petr Balogh from comment #5)
> Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first
> attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this
> SD manually and run everything from scratch with provisioning of machines
> and so.. and didn't hit this issue again.

Following official documentation, SHE deployments should be made only on clean environment.

Comment 7 Ido Rosenzwig 2018-04-30 11:50:32 UTC
(In reply to Nikolai Sednev from comment #6)
> 
> Following official documentation, SHE deployments should be made only on
> clean environment.

True, although Hosted-engine can be redeployed successfully after a failed deployment using the ovirt-hosted-engine-cleanup tool.


(In reply to Petr Balogh from comment #5)
> Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first
> attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this
> SD manually and run everything from scratch with provisioning of machines
> and so.. and didn't hit this issue again.

The ovirt-hosted-engine-cleanup tool is essential for redeploying the Hosted-engine after a failed deployment. This might be the reason why you got an error on the second attempt in spite of the clean SD.

Comment 8 Nikolai Sednev 2018-04-30 12:00:04 UTC
(In reply to Ido Rosenzwig from comment #7)
> (In reply to Nikolai Sednev from comment #6)
> > 
> > Following official documentation, SHE deployments should be made only on
> > clean environment.
> 
> True, although Hosted-engine can be redeployed successfully after a failed
> deployment using the ovirt-hosted-engine-cleanup tool.
> 
And this is tested flow and worked fine on our latest tests.
> 
> (In reply to Petr Balogh from comment #5)
> > Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first
> > attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this
> > SD manually and run everything from scratch with provisioning of machines
> > and so.. and didn't hit this issue again.
> 
> The ovirt-hosted-engine-cleanup tool is essential for redeploying the
> Hosted-engine after a failed deployment. This might be the reason why you
> got an error on the second attempt in spite of the clean SD.

Comment 9 Petr Balogh 2018-04-30 12:02:35 UTC
I know that there were introduced a few similar bugs with move to ansible 2.5, so I thought that this one is related too.  From some reason vlan_tag is '8000\\\\n1' as I can see from error messages so I guess that someone should check this one in the code..  it can maybe cause another issues in different place later on? Once we will be able to reproduce it, I will try run clan script before.

Comment 10 Ido Rosenzwig 2018-05-01 08:30:58 UTC
Please provide your network configuration settings (output of 'ip a' command)

Comment 13 Nikolai Sednev 2018-06-05 14:15:08 UTC
Works for me on these components:
ovirt-hosted-engine-ha-2.2.13-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.22-1.el7ev.noarch
rhvm-appliance-4.2-20180601.0.el7.noarch
Linux 3.10.0-862.3.2.el7.x86_64 #1 SMP Tue May 15 18:22:15 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.5 (Maipo)


Moving to verified.

Comment 14 Sandro Bonazzola 2018-06-26 08:41:18 UTC
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.