Could use some consensus on how to proceed here... Can the cores weigh in here?
Regards, PCM On Thu, Aug 20, 2015 at 10:54 AM Paul Michali <p...@michali.net> wrote: > I'm trying to update the DSVM test for neutron client so that it uses the > new VPN devstack plugin. In this process, however, I want to have a > solution that will work for other advanced services and for networking-* > projects. I could use some guidance here please. > > The approach I'm taking (and I need some guidance here), is to create a > gate-hook for neutron client [1], so that we can apply any needed devstack > plugin enables (not just for VPN). Then, add a job template that takes > variable args, and define (experimental) jobs to project-config that use > the gate-hook [2]. Finally, modify neutron client to make use of the gate > hook to do the needed testing. > > There are several ways forward, and I'd like to here what the community > consensus is to handle this. > > The way I was originally heading, was to have a job that replaces the > original job to run the "core" test cases, and another job for running the > VPN test cases (enabling the VPN devstack plugin). Later, jobs could be > defined for LB and FW, as needed/desired. > > Another possibility, would be to just have two jobs, one that handles > "core" tests, and one that handles "non-core" (advanced services, etc) test > cases and which enables the needed plugin(s). > > A third, and maybe simple case, is to just have a single job that replaces > the original job and runs all the tests and enables all the needed devstack > plugins. > > The obvious difference here is in the granularity of what gets tested for > a job (and the isolation provided). > > Some questions... > > - Opinions on the approaches suggested? > - Do we need separate jobs? > - Do networking-* projects have their own CLI client or do they use > neutron client? > - If they use neutron client project for CLI, how do we handle enabling of > any devstack plugins (without causing dependencies on external projects)? > > Thanks in advance! > > Paul Michali (pc_m) > > [1] https://review.openstack.org/#/c/210021/ > <https://review.openstack.org/#/c/209887/> - upstreamed > [2] https://review.openstack.org/#/c/209887/ - in review > [3] https://review.openstack.org/#/c/214587/ > <https://review.openstack.org/#/c/209887/> - in review >
__________________________________________________________________________ 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