<div dir="ltr"><div>Hello.</div><div><br></div><div><div class="gmail_extra">Cleber Rosa: thank you for RHEL6 Workstation Variant.</div></div><div><br></div><div><div>1. RPM.  There is a hidden pitfall for all testers. EPEL is supposed to be used on the latest RHEL/Centos. Yes. It is true.</div><div>Think about it as: EPEL should be installed on .Z stream.</div><div>It could be a problem for automation. For example. Some tester could be asked to run avocado tests for package from RHEL 7.1.  (Yes, QE teams runs test against old RHEL.) Where current RHEL is 7.3.  Than EPEL supposed to be installed on RHEL 7.3. It could be a problem to install EPEL on 7.1 (without updating packages to 7.3). Keep in mind that a tester is asked to test 7.1 not 7.3 package.</div><div>So. My point is: in future minimize EPEL dependency. LTS avocado should be easily installed on RHEL 7.0 7.1 7.2 7.3 7.3.</div><div><br></div><div>2. Maybe it is better to figure out how to install Avocado in Python Virtual Environment. This is more appropriate approach for me. As we can flexible change git repo. It is necessary to investigate this approach. <a href="https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe" target="_blank">https://<wbr>fedoraproject.org/wiki/<wbr>Changes/Making_sudo_pip_safe</a></div><div>Avocado should be usable from user&root accounts.<br></div><div><br></div><div><br></div><div>3. I think, our conversation should have some outcome. Some statement. QE teams must clearly understand how to use Avocado. QE teams should know where to report bugs related to Avocado installation. This should be specified on main page: <a href="https://github.com/avocado-framework/avocado/blob/master/README.rst" target="_blank">https://github.com/<wbr>avocado-framework/avocado/<wbr>blob/master/README.rst</a> . Something like: Officially supported OS is RHEL 6/x 7.x. Installation bugs report at: <a href="https://github.com/avocado-framework/avocado/issues" target="_blank">https://github.com/avocado-<wbr>framework/avocado/issues</a></div><div><br></div><div><br></div><div>4. I would like to mention a RPM packaging shortcoming. </div><div>After installation avocado should work with: /var/lib/<smth> </div><div>Currently it works with:</div><div><br></div><div>avocado bootstrap command:</div>/usr/share/avocado/data/<wbr>avocado-vt/test-providers.d/<wbr>downloads/io-github-spiceqa-<wbr>spice/spice/cfg/run.cfg</div><div>-- fetched from git</div><div><br></div><div>avocado run command:<br>/usr/share/avocado/data/<wbr>avocado-vt/backends/spice/cfg/<wbr>run.cfg<br><br>Please look at: <a href="https://fedoraproject.org/wiki/Archive:PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions" target="_blank">https://fedoraproject.org/<wbr>wiki/Archive:PackagingDrafts/<wbr>RPMMacros_sharedstatedir_<wbr>optflags_and_admonitions</a><br>Avocado should use for dynamic data:  %{_sharedstatedir}    /var/lib<div class="gmail_extra">Files inside /usr/share should be known to RPM.</div><div class="gmail_extra">Again. It is like a proposal. A right way to do. Future roadmap.</div><div class="gmail_extra"><br></div><div class="gmail_extra">5. Fresh RHEL7.3 + EPEL + RPM packages from: <a href="https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo" target="_blank">https://repos-<wbr>avocadoproject.rhcloud.com/<wbr>static/avocado-el.repo</a></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">repoquery --location 'avocado*'</div><div class="gmail_extra"><a href="https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-45.0-0.el7.centos.noarch.rpm" target="_blank">https://repos-avocadoproject.<wbr>rhcloud.com/static/epel-<wbr>7Server-noarch/avocado-45.0-0.<wbr>el7.centos.noarch.rpm</a></div><div class="gmail_extra"><a href="https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-examples-45.0-0.el7.centos.noarch.rpm" target="_blank">https://repos-avocadoproject.<wbr>rhcloud.com/static/epel-<wbr>7Server-noarch/avocado-<wbr>examples-45.0-0.el7.centos.<wbr>noarch.rpm</a></div><div class="gmail_extra"><a href="https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-output-html-45.0-0.el7.centos.noarch.rpm" target="_blank">https://repos-avocadoproject.<wbr>rhcloud.com/static/epel-<wbr>7Server-noarch/avocado-<wbr>plugins-output-html-45.0-0.<wbr>el7.centos.noarch.rpm</a></div><div class="gmail_extra"><a href="https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-vt-45.0-0.el7.centos.noarch.rpm" target="_blank">https://repos-avocadoproject.<wbr>rhcloud.com/static/epel-<wbr>7Server-noarch/avocado-<wbr>plugins-vt-45.0-0.el7.centos.<wbr>noarch.rpm</a></div><div><br></div><div><div># avocado list</div><div>Failed to load plugin from module "avocado_vt.plugins.vt_list": ImportError('No module named netaddr',)</div><div>Failed to load plugin from module "avocado_vt.plugins.vt": ImportError('No module named netaddr',)</div></div><div><br></div><div>So, there is some lack of dependency on python-netaddr.<br></div><div><br></div></div><div class="gmail_extra">What do you think?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:04 AM, Lukáš Doktor <span dir="ltr"><<a href="mailto:ldoktor@redhat.com" target="_blank">ldoktor@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dne 2.2.2017 v 22:36 Cleber Rosa napsal(a):<span class="m_8248429158590873781gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
From: "Andrei Stepanov" <<a href="mailto:astepano@redhat.com" target="_blank">astepano@redhat.com</a>><br>
To: "avocado-devel" <<a href="mailto:avocado-devel@redhat.com" target="_blank">avocado-devel@redhat.com</a>><br>
Sent: Wednesday, February 1, 2017 11:48:11 AM<br>
Subject: [Avocado-devel] What is a right way to install avocado?<br>
<br>
Hello.<br>
<br>
We are currently experiencing some issues with avocado / avocado-vt.<br>
<br>
Our automation can be described in next steps:<br>
<br>
0. Install RHEL 6/7.<br>
1. Clone "master" branches for avocado/avocado-vt from github.<br>
</blockquote>
<br>
Hi Andrei,<br>
<br>
Do you need specific features of Avocado not present in the LTS version?  I would strongly recommend that for "production testing", you'd use a more stable version of Avocado.  If you're willing to take a look at this suggested approach, let me if the fix for the Workstation version of EPEL6 works for you.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. In avocado dir:<br>
<br>
make requirements<br>
python setup.py install<br>
<br>
3. In avocado-vt dir:<br>
make link<br>
pip install sphinx<br>
pip install -r requirements.txt<br>
python setup.py install<br>
<br>
</blockquote>
<br>
For avocado-vt, an RPM package is also available (non-LTS, but designed to work with avocado LTS).  Most dependencies would be solved by the package install alone.  Then, dependencies for the test provider, say tp-qemu, could also be installed alongside it (but manually specified).<br>
</blockquote>
<br></span>
Well actually let's cc some Avocado-vt maintainers. I'm wondering what version of Avocado are you using to run Avocado-vt. We try to keep the backward compatibility (avocado-vt -> avocado) but it's always better to use what the mainstream uses as it is more tested. Maybe, if the version is not changing frequently, it'd make sense to mention the "known-to-work" Avocado version in the Avocado-vt GetStarted documentation.<br>
<br>
As for the RPM IIRC we do not provide them, but you can use `make rpm` to produce one. Anyway to install it you need RPMs. I think Autotest and Aexpect one is in one of our repos, other dependencies can be obtain from EPEL but only for primary architectures and I'm not sure they are all no-arch. Still you could use `src.rpm` to rebuild it for your architecture and push it into your repository.<br>
<br>
Overall I think the correct approach would be just to get a machine somewhere and create a script to periodically check for the latest deps RPMs, rebuild them and publish them in you repo. For Avocado I'd freeze the version mainstream is using and update occasionally. For Avocado-vt I think you need the master, which means you could either build the RPM on test machine or just be fine with weekly updates from your custom repo script. Bonus points would be for sharing (internally) this repo with other teams.<span class="m_8248429158590873781gmail-HOEnZb"><font color="#888888"><br>
<br>
Lukáš</font></span><div class="m_8248429158590873781gmail-HOEnZb"><div class="m_8248429158590873781gmail-h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. Run tests.<br>
<br>
Above commands are run from root account.<br>
We cannot use this approach any more.<br>
It doesn't work with RHEL7.3.<br>
<br>
I have opened a bug: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1417613" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1417613</a><br>
Than I had discussion with Tomas Orsava.<br>
<br>
The problem is, running pip as root in Fedora/EPEL is not supported and<br>
will break your system.<br>
<br>
<a href="https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe" rel="noreferrer" target="_blank">https://fedoraproject.org/wiki<wbr>/Changes/Making_sudo_pip_safe</a><br>
<br>
My question is: what is official way to install avocado/avocado-vt?<br>
<br>
Invoking pip commands from root account is a bad approach.<br>
<br>
Is there a safe way to install avocado & avocado-vt?<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br></div></div></div>