Bug 1418392 - TripleO Validation fail due to required Scapy package [rhos-10.0]
Summary: TripleO Validation fail due to required Scapy package [rhos-10.0]
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-validations
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 10.0 (Newton)
Assignee: Martin André
QA Contact: nlevinki
Depends On:
Blocks: 1420632
TreeView+ depends on / blocked
Reported: 2017-02-01 17:40 UTC by Razique Mahroua
Modified: 2018-10-11 08:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1435319 (view as bug list)
Last Closed: 2018-10-11 08:28:19 UTC
Target Upstream Version:

Attachments (Terms of Use)
Workaround (1.11 KB, text/x-vhdl)
2017-02-01 17:43 UTC, Razique Mahroua
no flags Details
Workaround - second file (1022 bytes, text/x-vhdl)
2017-02-01 17:43 UTC, Razique Mahroua
no flags Details

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 430681 0 None None None 2017-04-07 12:36:51 UTC

Description Razique Mahroua 2017-02-01 17:40:57 UTC
Description of problem:
There are two checks, 'DHCP on the Provisioning Network' and 'DHCP on the Introspection Network'. These two checks fail (from scapy.all import BOOTP raises an exception), despite scapy installed on the system:
[root@director ~] # pip show scapy
Metadata-Version: 1.0
Name: scapy
Version: 2.3.2
Summary: Scapy: interactive packet manipulation tool
Home-page: http://www.secdev.org/projects/scapy
Author: Philippe BIONDI
Author-email: phil(at)secdev.org
License: GPLv2
Location: /usr/lib/python2.7/site-packages

I applied the following to workaround the issue.
1- Updated /usr/share/openstack-tripleo-validations/validations/dhcp-provisioning.yaml
by appending the following setting to the 'pip' line:

pip: name=scapy version=2.3.2 state=present virtualenv=/tmp/validations-venv virtualenv_site_packages=yes

2- Did the same for dhcp-introspection.yaml

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Launch the 'DHCP on the Provisioning Network' and 'DHCP on the Provisioning Network DHCP on the Provisioning Network'checks
2. Both will fail (from scapy.all import BOOTP raises an exception)

Actual results:
The virtual environment does not import the Scapy module

Expected results:
The virtual environment should import the Scapy module and the two checks should pass.

Additional info:
As a side node, the RPM package scapy 2.3.2 is non existing, thus preventing this feature to work in offline installations.

Comment 1 Razique Mahroua 2017-02-01 17:43:02 UTC
Created attachment 1246756 [details]

Comment 2 Razique Mahroua 2017-02-01 17:43:59 UTC
Created attachment 1246757 [details]
Workaround - second file

Comment 3 Jon Schlueter 2017-02-02 14:26:52 UTC
doing a bit of digging here is what I found for scapy references in OSP 10

[openstack-tripleo-validations]$ ag scapy
23:  - name: Install scapy
24:    pip: name=scapy version=2.3.2 state=present virtualenv=/tmp/validations-venv

17:# Disable scapy's warning to stderr:
23:from scapy.all import BOOTP
24:from scapy.all import conf
25:from scapy.all import DHCP
26:from scapy.all import Ether
27:from scapy.all import get_if_raw_hwaddr
28:from scapy.all import IP
29:from scapy.all import srp
30:from scapy.all import UDP

18:  - name: Install scapy
19:    pip: name=scapy version=2.3.2 state=present virtualenv=/tmp/validations-venv

Comment 4 Jon Schlueter 2017-02-02 14:30:33 UTC
how are we getting pip installed on the system?

Comment 15 Martin André 2017-03-22 17:23:28 UTC
I've pushed a patch both upstream [1] and downstream [2] that replaces the scapy script by one using raw sockets. The upstream patch received negative feedback asking to package scapy instead.

My suggestion would be to remove this validation if the patch is not going to be merged.

I don't know how much work is needed to get scapy packaged for RHEL, but this is not something I can commit to right now. Jason, can someone from the UI DFG take over these patches?

[1] https://review.openstack.org/#/c/430681/
[2] https://code.engineering.redhat.com/gerrit/#/c/97154/

Comment 16 Jason E. Rist 2017-04-10 14:59:51 UTC
Martin - yes

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