[rdo-list] Tempest Packaging in RDO

[Javier Pena]

----- Original Message -----
> Hi everyone,
> 
> As a follow-up from the conversations that we had on the irc, I wanted
> to summarize the current issues and possible actions. As we ran out of
> time during the meeting I'd really appreciate some feedback on this.
> 
> 1) Tempest Plugins
> 
> With the current situation (project package and project-test package) we
> do install the entry point with the main package, even if the
> sub-package is not installed. In this case, Tempest will discover the
> test entry point without the code and fail.
> 
> On this, I'd propose to integrate-back the -tests packages for the
> in-tree plugins, even if it would mean adding some more dependencies to
> them and remove tempest requirement as a dependency for out-tree ones
> (i.e. Designate[2] or tempest-horizon[3]), which will get rid of any
> circular dependency.

I'd really like to remove the tempest dependency for designate-tests and horizon-tests soon, at least to unblock part of the issues (not being able to properly test designate/horizon without pulling the whole Tempest lot with it).

> 
> This seems to breaks RPM logic. This is only to allow mixing packages
> and git/pip installations which is a source of troubles. At best, it
> could be a temporary measure. If it's about circular dependencies, RPM
> knows how to handle them, and the best way to break them would be
> plugins requiring tempest and not the reverse.
> 
> We could have a a subpackage tempest-all that requires all the plugins
> for an AIO install. (alternatively: tempest requires all plugins, and
> plugins would require a tempest-core packages. tempest package being
> empty and tempest-core containing the framework)
> 

If I understand it correctly, the main reason for having tempest depend on all test subpackages is to simplify the process for CI jobs, isn't it? If so, this tempest-all metapackage could be a good short-term solution, while we fix the bigger issues.

Javier

> Also, the plugin state is not really optimal, as some of those plugins
> would pin to an specific commit of tempest. All of this should be sorted
> out in the end by [1] but for now we'll need to find some solution on this.
> 
> 
> 2) Tempest Requirements
> 
>    As tempest is installed in the undercloud, it will use whatever
> plugins are installed there, so if checking every test from the
> overcloud is a must it'd need to have a lot of packages installed as
> dependencies (that's the current status).
> 
> Some ideas for this have been.
> 
> - Create a parent-package/metapackage called 'tempest-all-test' or
> similar, which will allow to install all the sub-componants packages.
> This would allow not to install all the tempest dependencies but rather
> only one component at a time. It would Requires: all test packages for
> anyone who needs to install them all.
> 
> - Puppet-Tempest: it will install tempest itself (albeit only from
> source right now, this can be addressed:
> https://bugs.launchpad.net/puppet-tempest/+bug/1549366) but it will also
> install tempest plugins based on the parameters that define the
> availability of services. For example, if "ceilometer_available" is set
> to true, it will install python-ceilometer-tests and set the config in
> tempest.conf "[service_available] ceilometer=True"
> 
> 
> 3) Tempest Config Tool
>     Right now is the only diff between upstream vanilla and our
> downstream fork, on here, our proposal could be to move it to its own
> repo and decouple it from tempest so we could use vanilla and not depend
> on the downstream fork. This will later on also integrated and used on
> RefStack/DefCore (WIP).
> 
> There has been quite some discussion around this, and there are
> duplicated projects doing the same work with some difference (basically
> to use or not api_discovery)
> 
> During the past summit and afterwards, we agreed on creating something
> that would depend on the installer (fetching the configuration from
> TripleO), as the tool as it is won't be accepted on upstream tempest.
> 
> This had been dropped dead since, so I'd like to resume the discussion.
> 
> Thanks for any ideas!
> 
> Daniel
> 
> ---
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101552.html
> [2] https://review.rdoproject.org/r/#/c/1820/
> [3]
> https://github.com/openstack/tempest-horizon/blob/master/requirements.txt#L11
> 
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>