Re: [Avocado-devel] What is a right way to install avocado?

[Lucas Meneghel Rodrigues]

I'll try the whole setup from a virtualenv and report the results.

On Fri, Feb 3, 2017 at 5:12 PM Cleber Rosa  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  > > 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 mock97K Feb  1 07:35
> > avocado-plugins-output-html-45.0-0.fc25.noarch.rpm
> > -rw-rw-r--. 1 cleber mock19K Feb  1 07:35
> > avocado-plugins-runner-docker-45.0-0.fc25.noarch.rpm
> > -rw-rw-r--. 1 cleber mock27K Feb  1 07:35
> > avocado-plugins-runner-remote-45.0-0.fc25.noarch.rpm
> > -rw-rw-r--. 1 cleber mock23K 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 ins

Re: [Avocado-devel] What is a right way to install avocado?

[Cleber Rosa]

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  > 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 mock97K Feb  1 07:35
> avocado-plugins-output-html-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock19K Feb  1 07:35
> avocado-plugins-runner-docker-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock27K Feb  1 07:35
> avocado-plugins-runner-remote-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock23K 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
> > 

Re: [Avocado-devel] What is a right way to install avocado?

[Lucas Meneghel Rodrigues]

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)
2) Full PIP install on a virtualenv (it should be mostly clean, except for
the external dependencies of avocado-vt)

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.

On Fri, Feb 3, 2017 at 3:32 PM Cleber Rosa  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 mock97K Feb  1 07:35
> avocado-plugins-output-html-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock19K Feb  1 07:35
> avocado-plugins-runner-docker-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock27K Feb  1 07:35
> avocado-plugins-runner-remote-45.0-0.fc25.noarch.rpm
> -rw-rw-r--. 1 cleber mock23K 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
> > 
> > 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
> > 
> >
>
> 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.

Re: [Avocado-devel] What is a right way to install avocado?

[Cleber Rosa]

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 mock97K Feb  1 07:35
avocado-plugins-output-html-45.0-0.fc25.noarch.rpm
-rw-rw-r--. 1 cleber mock19K Feb  1 07:35
avocado-plugins-runner-docker-45.0-0.fc25.noarch.rpm
-rw-rw-r--. 1 cleber mock27K Feb  1 07:35
avocado-plugins-runner-remote-45.0-0.fc25.noarch.rpm
-rw-rw-r--. 1 cleber mock23K 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
> 
> 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 
> 
> . Something like: Officially supported OS is RHEL 6/x 7.x. Installation
> bugs report at: 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/ 
> 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
> 
> Avocado should use for dynamic data:  %{_sharedstatedir}/var/lib
> Files inside /usr/share shou

Re: [Avocado-devel] What is a right way to install avocado?

[Andrei Stepanov]

Hello.

Cleber Rosa: thank you for RHEL6 Workstation Variant.

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.

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
Avocado should be usable from user&root accounts.


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 . Something like: Officially supported OS is RHEL
6/x 7.x. Installation bugs report at: https://github.com/avocado-
framework/avocado/issues


4. I would like to mention a RPM packaging shortcoming.
After installation avocado should work with: /var/lib/
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
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.

5. Fresh RHEL7.3 + EPEL + RPM packages from: 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-
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-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?


On Fri, Feb 3, 2017 at 7:04 AM, Lukáš Doktor  wrote:

> Dne 2.2.2017 v 22:36 Cleber Rosa napsal(a):
>
>>
>> - Original Message -
>>
>>> From: "Andrei Stepanov" 
>>> To: "avocado-devel" 
>>> 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 

Re: [Avocado-devel] What is a right way to install avocado?

[Lukáš Doktor]

Dne 2.2.2017 v 22:36 Cleber Rosa napsal(a):


- Original Message -

From: "Andrei Stepanov" 
To: "avocado-devel" 
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
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

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?







signature.asc
Description: OpenPGP digital signature

Re: [Avocado-devel] What is a right way to install avocado?

[Cleber Rosa]

- Original Message -
> From: "Andrei Stepanov" 
> To: "avocado-devel" 
> 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).

> 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
> 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
> 
> 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?
> 

Re: [Avocado-devel] What is a right way to install avocado?

[Cleber Rosa]

Hi Andrei,

I missed the "Workstation" variant for RHEL6. This is an easy fix, that should 
already be online.

Thanks for reporting.
- Cleber.

- Original Message -
> From: "Andrei Stepanov" 
> To: "avocado-devel" 
> Sent: Thursday, February 2, 2017 11:03:07 AM
> Subject: Re: [Avocado-devel] What is a right way to install avocado?
> 
> When I add https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo
> to RHEL6 I get:
> 
> https://repos-avocadoproject.rhcloud.com/static/epel-6Workstation-noarch/repodata/repomd.xml:
> [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not
> Found"
> 
> 
> 
> On Wed, Feb 1, 2017 at 5:48 PM, Andrei Stepanov  wrote:
> 
> > 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.
> > 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
> >
> > 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
> > 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
> >
> > 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?
> >
> 

Re: [Avocado-devel] What is a right way to install avocado?

[Lukáš Doktor]

Hello Andrei,

I was not aware of that. I'm using 
https://www.redhat.com/archives/avocado-devel/2017-January/msg00020.html 
(with some additions) so I'll take a look into what can be done to 
improve this. We partially dived into this area with Jan Sčotka who is 
using Avocado and is looking for RPMs for dependencies and we don't have 
the capacity to maintain a repo of them, but if pip should not be used 
as root then we'll have to probably create a script to fetch the latest 
versions from brew, rebuild it on all needed archs and publish it into 
some downstream repo. Ideally we should share this effort among multiple 
teams.


Lukáš

Dne 1.2.2017 v 17:48 Andrei Stepanov napsal(a):

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.
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

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
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

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?




signature.asc
Description: OpenPGP digital signature

Re: [Avocado-devel] What is a right way to install avocado?

[Lukáš Doktor]

Hello Andrei,

this is unfortunate, let's CC Cleber who has access to this server (but 
he is currently traveling from Brno therefor the reply might take a while)


Lukáš

Dne 2.2.2017 v 17:03 Andrei Stepanov napsal(a):

When I
add https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo to
RHEL6 I get:

https://repos-avocadoproject.rhcloud.com/static/epel-6Workstation-noarch/repodata/repomd.xml:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not
Found"



On Wed, Feb 1, 2017 at 5:48 PM, Andrei Stepanov mailto:astep...@redhat.com>> wrote:

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.
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

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

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


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?






signature.asc
Description: OpenPGP digital signature

Re: [Avocado-devel] What is a right way to install avocado?

[Lukáš Doktor]

Hello Andrei,

this is unfortunate, let's CC Cleber who has access to this server (but 
he is currently traveling from Brno therefor the reply might take a while)


Lukáš

Dne 2.2.2017 v 17:03 Andrei Stepanov napsal(a):

When I
add https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo to
RHEL6 I get:

https://repos-avocadoproject.rhcloud.com/static/epel-6Workstation-noarch/repodata/repomd.xml:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not
Found"



On Wed, Feb 1, 2017 at 5:48 PM, Andrei Stepanov mailto:astep...@redhat.com>> wrote:

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.
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

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

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


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?






signature.asc
Description: OpenPGP digital signature

Re: [Avocado-devel] What is a right way to install avocado?

[Andrei Stepanov]

When I add https://repos-avocadoproject.rhcloud.com/static/avocado-el.repo
to RHEL6 I get:

https://repos-avocadoproject.rhcloud.com/static/epel-6Workstation-noarch/repodata/repomd.xml:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not
Found"



On Wed, Feb 1, 2017 at 5:48 PM, Andrei Stepanov  wrote:

> 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.
> 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
>
> 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
> 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
>
> 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?
>