I'll try the whole setup from a virtualenv and report the results. On Fri, Feb 3, 2017 at 5:12 PM Cleber Rosa <cr...@redhat.com> wrote:
> > On 02/03/2017 09:39 AM, Lucas Meneghel Rodrigues wrote: > > There is a tension between RPM being the one true way to install > > software in Fedora, RHEL and derivatives and installing from pip, which > > should be convenient and portable to any distro that has virtualenv. The > > following use cases should be covered IMHO: > > > > 1) Full distro packages (avocado + avocado-vt coming from .rpms or .debs > > or whatever else people would like to package avocado in) > > I believe Avocado-VT is a lot closer to their tests than Avocado itself > (just think of the small amount of core test APIs Avocado makes > available). I'd say it's much more common for tests to require changes > to Avocado-VT than Avocado tests require changes to Avocado. That's why > I believe Avocado-VT from GIT is quite common. > > Avocado, when used with Avocado-VT is much more a runtime of sorts. > That's why, in my understanding, it makes sense get it from more stable > sources. Either LTS packages or the LTS branch seem to be ideal. > > It should make no difference to Avocado-VT if Avocado comes from an RPM > package or from source (pip, setup.py, etc), just as for Avocado itself, > it should make no difference where the libraries it depends on came from. > > So yes, we're in sync when it comes to pip installs: it should work and > it's considered an official installation procedure. The issue is that > we've not being testing *Avocado-VT* on virtualenvs AFAICT. > > > 2) Full PIP install on a virtualenv (it should be mostly clean, except > > for the external dependencies of avocado-vt) > > > > Is anybody out there using such a deployment strategy for Avocado-VT? > I'd love to hear about it. > > > I'm not sure how interesting it would be supporting 'mixed' setups. > > Also, these days we have people experimenting with new ways to deploy > > software on Linux, such as Flatpak. Maybe avocado could jump into the > > gravy train as well. > > > > For Flatpak, it would be great to have something in "contrib". Any > volunteers? > > - Cleber. > > > On Fri, Feb 3, 2017 at 3:32 PM Cleber Rosa <cr...@redhat.com > > <mailto:cr...@redhat.com>> wrote: > > > > > > On 02/03/2017 09:03 AM, Andrei Stepanov wrote: > > > Hello. > > > > > > Cleber Rosa: thank you for RHEL6 Workstation Variant. > > > > > > > You're welcome. Actually, thank you for reporting it. > > > > > 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. > > > Think about it as: EPEL should be installed on .Z stream. > > > 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. > > > 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. > > > > > > > This (EPEL dependency) is essentially a trade off we had to decide > on, > > with the other options at the time being bundling libraries (a real > > problem) or dropping features that could only be delivered with the > help > > of external libraries. > > > > But, let me ensure you that we're working towards a much leaner (and > > eventually EPEL free) version of Avocado. As a matter of fact, this > is > > the goal of the plugin based architecture we've invested on. This, > for > > instance, is a WiP (close to being pushed upstream): > > > > ls -lh BUILD/RPM/ > > total 1.8M > > -rw-rw-r--. 1 cleber mock 404K Feb 1 07:35 > > avocado-45.0-0.fc25.noarch.rpm > > -rw-rw-r--. 1 cleber mock 704K Feb 1 07:32 > > avocado-45.0-0.fc25.src.rpm > > -rw-rw-r--. 1 cleber mock 228K Feb 1 07:35 > > avocado-examples-45.0-0.fc25.noarch.rpm > > -rw-rw-r--. 1 cleber mock 97K Feb 1 07:35 > > avocado-plugins-output-html-45.0-0.fc25.noarch.rpm > > -rw-rw-r--. 1 cleber mock 19K Feb 1 07:35 > > avocado-plugins-runner-docker-45.0-0.fc25.noarch.rpm > > -rw-rw-r--. 1 cleber mock 27K Feb 1 07:35 > > avocado-plugins-runner-remote-45.0-0.fc25.noarch.rpm > > -rw-rw-r--. 1 cleber mock 23K Feb 1 07:35 > > avocado-plugins-runner-vm-45.0-0.fc25.noarch.rpm > > > > It means that the "avocado" package will require as little as > possible > > external packages (with the goal being no packages outside base > RHEL), > > and the avocado-plugins-* packages with further requirements. > > > > > 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. > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > > <https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe> > > > Avocado should be usable from user&root accounts. > > > > > > > > > > Avocado itself should run just fine on a virtualenv. If there are > > problems, I'd love to hear about them. Also true with regards to > > running it as either a regular user or root. > > > > Avocado-VT, on the other hand, is to the best of my knowledge > UNTESTED > > in a virtualenv. I recommend testing it and reporting specific > > problems. > > > > > 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: > > https://github.com/avocado-framework/avocado/blob/master/README.rst > > <https://github.com/avocado-framework/avocado/blob/master/README.rst > > > > > . Something like: Officially supported OS is RHEL 6/x 7.x. > > Installation > > > bugs report at: > https://github.com/avocado-framework/avocado/issues > > > <https://github.com/avocado-framework/avocado/issues> > > > > > > > I agree. And this is a key point where the various QE teams can > help us > > (non-QE Avocado developers). We currently have the understanding > that > > most deployment scenarios are Avocado LTS from packages + Avocado-VT > > from GIT. > > > > About the packages, we do *officially* support the packages we build > and > > distribute. Those cover Fedora: > > > > > http://avocado-framework.readthedocs.io/en/45.0/GetStartedGuide.html#fedora > > > > And EL: > > > > > http://avocado-framework.readthedocs.io/en/45.0/GetStartedGuide.html#enterprise-linux > > > > Please keep in mind that: > > * For EL, as mentioned earlier, EPEL is (still) a requirement > > * We develop those packages on x86_64. This is what we can support > at > > this point. > > > > > > > > 4. I would like to mention a RPM packaging shortcoming. > > > After installation avocado should work with: /var/lib/<smth> > > > Currently it works with: > > > > > > avocado bootstrap command: > > > > > > > /usr/share/avocado/data/avocado-vt/test-providers.d/downloads/io-github-spiceqa-spice/spice/cfg/run.cfg > > > -- fetched from git > > > > > > avocado run command: > > > /usr/share/avocado/data/avocado-vt/backends/spice/cfg/run.cfg > > > > > > Please look at: > > > > > > https://fedoraproject.org/wiki/Archive:PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions > > > > > < > https://fedoraproject.org/wiki/Archive:PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions > > > > > Avocado should use for dynamic data: %{_sharedstatedir} > /var/lib > > > Files inside /usr/share should be known to RPM. > > > Again. It is like a proposal. A right way to do. Future roadmap. > > > > > > > This seems indeed an Avocado-VT packaging issue. Would you please > open > > a proper issue for that? Also, please understand that the Avocado-VT > > RPM packaging is seem as a convenience, and may not be suitable to > some > > users. This is related to our understanding of the "deployment > > scenarios" we believe are the most common. > > > > > 5. Fresh RHEL7.3 + EPEL + RPM packages > > > from: > https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo > > > <https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo> > > > > > > repoquery --location 'avocado*' > > > > > > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-45.0-0.el7.centos.noarch.rpm > > > > > < > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-45.0-0.el7.centos.noarch.rpm > > > > > > > > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-examples-45.0-0.el7.centos.noarch.rpm > > > > > < > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-examples-45.0-0.el7.centos.noarch.rpm > > > > > > > > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-output-html-45.0-0.el7.centos.noarch.rpm > > > > > < > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-output-html-45.0-0.el7.centos.noarch.rpm > > > > > > > > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-vt-45.0-0.el7.centos.noarch.rpm > > > > > < > https://repos-avocadoproject.rhcloud.com/static/epel-7Server-noarch/avocado-plugins-vt-45.0-0.el7.centos.noarch.rpm > > > > > > > > # avocado list > > > Failed to load plugin from module "avocado_vt.plugins.vt_list": > > > ImportError('No module named netaddr',) > > > Failed to load plugin from module "avocado_vt.plugins.vt": > > > ImportError('No module named netaddr',) > > > > > > So, there is some lack of dependency on python-netaddr. > > > > > > What do you think? > > > > > > > > > > This can (and should) indeed be added to the Avocado-VT SPEC file. > Care > > to send a patch? > > > > - Cleber. > > > > > On Fri, Feb 3, 2017 at 7:04 AM, Lukáš Doktor <ldok...@redhat.com > > <mailto:ldok...@redhat.com> > > > <mailto:ldok...@redhat.com <mailto:ldok...@redhat.com>>> wrote: > > > > > > Dne 2.2.2017 v 22:36 Cleber Rosa napsal(a): > > > > > > > > > ----- Original Message ----- > > > > > > From: "Andrei Stepanov" <astep...@redhat.com > > <mailto:astep...@redhat.com> > > > <mailto:astep...@redhat.com <mailto: > astep...@redhat.com>>> > > > To: "avocado-devel" <avocado-devel@redhat.com > > <mailto:avocado-devel@redhat.com> > > > <mailto:avocado-devel@redhat.com > > <mailto:avocado-devel@redhat.com>>> > > > Sent: Wednesday, February 1, 2017 11:48:11 AM > > > Subject: [Avocado-devel] What is a right way to > > install avocado? > > > > > > Hello. > > > > > > We are currently experiencing some issues with avocado > / > > > avocado-vt. > > > > > > Our automation can be described in next steps: > > > > > > 0. Install RHEL 6/7. > > > 1. Clone "master" branches for avocado/avocado-vt from > > github. > > > > > > > > > Hi Andrei, > > > > > > 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. > > > > > > 2. In avocado dir: > > > > > > make requirements > > > python setup.py install > > > > > > 3. In avocado-vt dir: > > > make link > > > pip install sphinx > > > pip install -r requirements.txt > > > python setup.py install > > > > > > > > > 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). > > > > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > Lukáš > > > > > > > > > > > > 4. Run tests. > > > > > > Above commands are run from root account. > > > We cannot use this approach any more. > > > It doesn't work with RHEL7.3. > > > > > > I have opened a bug: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1417613 > > > <https://bugzilla.redhat.com/show_bug.cgi?id=1417613> > > > Than I had discussion with Tomas Orsava. > > > > > > The problem is, running pip as root in Fedora/EPEL is > not > > > supported and > > > will break your system. > > > > > > > > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > > > > <https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe> > > > > > > My question is: what is official way to install > > > avocado/avocado-vt? > > > > > > Invoking pip commands from root account is a bad > approach. > > > > > > Is there a safe way to install avocado & avocado-vt? > > > > > > > > > > > > > > > > > > > -- > > Cleber Rosa > > [ Sr Software Engineer - Virtualization Team - Red Hat ] > > [ Avocado Test Framework - avocado-framework.github.io > > <http://avocado-framework.github.io> ] > > > > -- > Cleber Rosa > [ Sr Software Engineer - Virtualization Team - Red Hat ] > [ Avocado Test Framework - avocado-framework.github.io ] > >