[Avocado-devel] What is a right way to install avocado?
Cleber Rosa
crosa at redhat.com
Fri Feb 3 16:12:04 UTC 2017
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 <crosa at redhat.com
> <mailto:crosa at 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 <ldoktor at redhat.com
> <mailto:ldoktor at redhat.com>
> > <mailto:ldoktor at redhat.com <mailto:ldoktor at redhat.com>>> wrote:
> >
> > Dne 2.2.2017 v 22:36 Cleber Rosa napsal(a):
> >
> >
> > ----- Original Message -----
> >
> > From: "Andrei Stepanov" <astepano at redhat.com
> <mailto:astepano at redhat.com>
> > <mailto:astepano at redhat.com <mailto:astepano at redhat.com>>>
> > To: "avocado-devel" <avocado-devel at redhat.com
> <mailto:avocado-devel at redhat.com>
> > <mailto:avocado-devel at redhat.com
> <mailto:avocado-devel at 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 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170203/977ea646/attachment.sig>
More information about the Avocado-devel
mailing list