[Avocado-devel] What is a right way to install avocado?
Lucas Meneghel Rodrigues
lookkas at gmail.com
Fri Feb 3 16:42:42 UTC 2017
I'll try the whole setup from a virtualenv and report the results.
On Fri, Feb 3, 2017 at 5:12 PM Cleber Rosa <crosa at 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 <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 --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170203/dae1d838/attachment.htm>
More information about the Avocado-devel
mailing list