Open Stack

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 <pc at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/7916efa4/attachment.html>