[openstack-dev] [Fuel][Infra] Nailgun extensions testing

Roman Prykhodchenko me at romcheg.me
Mon Mar 21 13:12:16 UTC 2016


The idea is to write python (or shell) script which will:
> - clone all required repos (like fuel-web, extensions repos) using
>   probably zuul-cloner

Doesn’t nodepool automatically do that?

> - checkout to appropriate stable branches / will cherry-pick some
>   commit / stay on master

As far as I understand extensions have Nailgun as their Python requirement so it would be reasonable to just install it from PyPi (first we need to release Nailgun to PyPi). Master of Nailgun can run its own non-voting job to check compatibility with the existing extensions and notify authors about any compatibility issues.

> 17 бер. 2016 р. о 14:42 Sylwester Brzeczkowski <sbrzeczkowski at mirantis.com> написав(ла):
> 
> Hi everyone!
> 
> I’m looking for boilerplates/good practices regarding to testing
> extensions with core code.
> 
> Since we unlocked Nailgun extensions system [0] and now there
> is a possibility to install the extensions from external sources we
> want to also provide a way to test your own extensions against
> Nailgun and some other extensions. Here is the spec for this activity [1]
> 
> The idea is to write python (or shell) script which will:
> - clone all required repos (like fuel-web, extensions repos) using
>   probably zuul-cloner
> - checkout to appropriate stable branches / will cherry-pick some
>   commit / stay on master
> - run tests
> 
> This script will be used to:
> - test extension with different Nailgun versions (to check if it’s compatible)
>   locally and on extension’s jenkins gate jobs
> - test extension with different Nailgun versions and with other extensions
>   enabled (depending on needs)
> - test Nailgun with some core extensions locally and on fuel-web
>   jenkins gate jobs
> 
> The script will be placed in fuel-web repo as extensions will need
> to have Nailgun in its requirements anyway.
> 
> There will be new jenkins job which will consume names of
> extensions to test and the branches/commits/versions which
> the tests should be run against. The job will basically fetch fuel-web
> repo, and run the script mentioned above.
> 
> What do you think about the idea? Is it a good approach?
> Am I missing some already existing solutions for this problem?
> 
> Regards
> 
> [0] https://blueprints.launchpad.net/fuel/+spec/stevedore-extensions-discovery <https://blueprints.launchpad.net/fuel/+spec/stevedore-extensions-discovery>
> [1] https://review.openstack.org/#/c/281749/ <https://review.openstack.org/#/c/281749/>
> 
> 
> --
> Sylwester Brzeczkowski
> Python Software Engineer
> Product Development-Core : Product Engineering
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160321/1fafd81a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160321/1fafd81a/attachment.pgp>


More information about the OpenStack-dev mailing list