[openstack-dev] [neutron][testing] How to modify DSVM tests to use a DevStack plugin?

Paul Michali pc at michali.net
Mon Jul 27 12:21:25 UTC 2015


Maybe I'm not explaining myself well (sorry)...

For VPN commits, there are functional jobs that (now) enable the devstack
plugin for neutron-vpnaas as needed (and grenade job will do the same).
>From the neutron-vpnaas repo standpoint everything is in place.

Now that there is a devstack plugin for neutron-vpnaas, I want to remove
all the VPN setup from the *DevStack* repo's setup, as the user of DevStack
can specify the enable_plugin in their local.conf file now. The commit is
https://review.openstack.org/#/c/201119/.

The issue I see though, is that the DevStack repo's jobs are failing,
because they are using devstack, are relying on VPN being set up, and the
enable_plugin line for VPN isn't part of any of the jobs shown in my last
post.

How do we resolve that issue?

Regards,

PCM


On Mon, Jul 27, 2015 at 8:09 AM Sean Dague <sean at dague.net> wrote:

> You would build variants of the jobs you want that specifically enable
> your plugin.
>
> That being said, you should focus on jobs that substantially test your
> component, not just the giant list of all jobs. Part of our focus in on
> decoupling so that for something like vpnaas you can start with the
> assumption that neutron base services are sufficiently tested elsewhere,
> and the only thing you should test is the additional function and
> complexity that your component brings to the mix.
>
>         -Sean
>
> On 07/27/2015 07:44 AM, Paul Michali wrote:
> > Yes, the plugin enables the service, and for the neutron-vpnaas DSVM
> > based jobs, I have the "enable_plugin" line added to the job so that
> > everything works.
> >
> > However, for the DevStack repo, which runs a bunch of other DSVM jobs,
> > this fails, as there is (obviously) no enable_plugin line.:
> >
> >   * gate-tempest-dsvm-full
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-full/98be491/>
> SUCCESS in
> >     58m 37s
> >   * gate-tempest-dsvm-postgres-full
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-postgres-full/85c5b92/>
> SUCCESS in
> >     50m 45s
> >   * gate-tempest-dsvm-neutron-full
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-neutron-full/0050bfe/>
> FAILURE in
> >     1h 25m 30s
> >   * gate-grenade-dsvm
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-grenade-dsvm/b224606/>
> SUCCESS in
> >     44m 23s
> >   * gate-tempest-dsvm-large-ops
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-large-ops/a250cf5/>
> SUCCESS in
> >     26m 49s
> >   * gate-tempest-dsvm-neutron-large-ops
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-neutron-large-ops/6faa1be/>
> SUCCESS in
> >     25m 51s
> >   * gate-devstack-bashate
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-devstack-bashate/65ad952/>
> SUCCESS in
> >     13s
> >   * gate-devstack-unit-tests
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-devstack-unit-tests/ccdbe4e/>
> SUCCESS in
> >     1m 02s
> >   * gate-devstack-dsvm-cells
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-devstack-dsvm-cells/a6ca00c/>
> SUCCESS in
> >     24m 08s
> >   * gate-grenade-dsvm-partial-ncpu
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-grenade-dsvm-partial-ncpu/744deb8/>
> SUCCESS in
> >     48m 36s
> >   * gate-tempest-dsvm-ironic-pxe_ssh
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-ironic-pxe_ssh/8eb4315/>
> FAILURE in
> >     40m 10s
> >   * gate-devstack-dsvm-updown
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-devstack-dsvm-updown/85f1de5/>
> SUCCESS in
> >     21m 12s
> >   * gate-tempest-dsvm-f21
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-f21/35a04c4/>
> FAILURE in
> >     51m 01s (non-voting)
> >   * gate-tempest-dsvm-centos7
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-centos7/b9c99c9/>
> SUCCESS in
> >     30m 23s (non-voting)
> >   * gate-devstack-publish-docs
> >     <
> http://docs-draft.openstack.org/19/201119/1/check/gate-devstack-publish-docs/f794b1c//doc/build/html/>
> SUCCESS in
> >     2m 23s
> >   * gate-swift-dsvm-functional-nv
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-swift-dsvm-functional-nv/13d2c58/>
> SUCCESS in
> >     27m 12s (non-voting)
> >   * gate-grenade-dsvm-neutron
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-grenade-dsvm-neutron/8675f0c/>
> FAILURE in
> >     47m 49s
> >   * gate-tempest-dsvm-multinode-smoke
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-multinode-smoke/bd69c45/>
> SUCCESS in
> >     36m 53s (non-voting)
> >   * gate-tempest-dsvm-neutron-multinode-smoke
> >     <
> http://logs.openstack.org/19/201119/1/check/gate-tempest-dsvm-neutron-multinode-smoke/01e1d45/>
> FAILURE in
> >     44m 16s (non-voting)
> >
> >
> > I'm wondering what's the best way to modify those jobs... is there some
> > common location where I can enable the plugin to handle all DSVM based
> > jobs, do I just update the 5 failing tests, do I update just the 3
> > voting tests, or do I update all 16 DSVM based jobs?
> >
> > Regards,
> > PCM
> >
> > On Fri, Jul 24, 2015 at 5:12 PM Clark Boylan <cboylan at sapwetik.org
> > <mailto:cboylan at sapwetik.org>> wrote:
> >
> >     On Fri, Jul 24, 2015, at 02:05 PM, Paul Michali wrote:
> >     > Hi,
> >     >
> >     > I've created a DevStack plugin for the neutron-vpnaas repo. Now,
> I'm
> >     > trying
> >     > to remove the q-vpn service setup from the DevStack repo (
> >     > https://review.openstack.org/#/c/201119/).
> >     >
> >     > However, I'm hitting an issue in that (almost) every test that uses
> >     > DevStack fails, because it is no longer setting up q-vpn.
> >     >
> >     > How should I modify the tests, so that they setup the q-vpn
> >     service, in
> >     > light of the fact that there is a DevStack plugin available for
> it. Is
> >     > there some common place that I can do the "enable_plugin
> >     > neutron-vpnaas..."
> >     > line?
> >     >
> >     Your devstack plugin should enable the service. Then in your jobs you
> >     just need to enable the plugin which will then enable the vpn
> service.
> >     There should be plenty of prior art with the ec2api plugin, glusterfs
> >     plugin, and others.
> >
> >     Clark
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20150727/3df366dc/attachment.html>


More information about the OpenStack-dev mailing list