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

2016-03-21 Thread Evgeniy L 
Hi Roman,

>> reasonable to just install it from PyPi (first we need to release
Nailgun to PyPi)

Yes there will be dependencies, but there should be a way to test core
extensions (those which go to standard Fuel build) from master (or any
other branch), so installing from pypi is not always an option.

>> Master of Nailgun can run its own non-voting job to check compatibility
with the existing extensions ...

Yes, when patch is submitted to Nailgun, it should run extensions gates to
test compatibility, and when patch to extension is submitted it should test
it with specific version of Nailgun.

Thanks,

On Mon, Mar 21, 2016 at 4:12 PM, Roman Prykhodchenko  wrote:

> 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 
> написав(ла):
>
> 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
> [1] 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-03-21 Thread Roman Prykhodchenko 
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  
> написав(ла):
> 
> 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 
> 
> [1] 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-03-19 Thread Sylwester Brzeczkowski 
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
[1] 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev