<snip>
As someone that semi frequently has to reproduce gate results my current setup involves semi frequently building the infra test images locally using openstack-infra/project-config/tools/build-image.sh then booting this image on my workstation using kvm. With that I can easily run a devstack-gate reproduce.sh or tox -e whatever and have a high degree of confidence that my setup mirrors the gate's.
Cool, so that mirrors the gate, but say you want to go larger and have a mini-cluster with a router Y here, a lbaas of X type there and you are say testing a new feature in neutron (and that feature interacts with some hardware that isn't open); I'm wondering also how such kind of 'vendor' or people that integrate with 'vendors' (with physical things) do there kind of local dev or integration or <other feature/bug> work.
When I worked for HP I did similar on top of HPCloud. This actually worked very well as I could much more easily share the results. If I had my choice of setup I would just ask for a set of openstack cloud credentials with a reasonable amount of quota. Dogfooding has been a great way to understand how openstack works and I think it has produced valuable feedback helping openstack improve.
Agreed, no doubt; it works great when everything is software-defined (for better or worse everything doesn't appear there just quite yet, at some point things hit real hardware).
Granted this is much harder to hand out when you need specific hardware resources (network switches, server hardware, whatever), but with Ironic most of that should be doable with the "give devs cloud credentials" model.
Yup.
As for requesting an environment with nova version foo and neutron version bar and topology baz devstack does this a few thousand times per day. It may not be everyone's preferred tool, but my suggestion would be to not make another tool that does this and never gets tested. Instead use what is being tested.
Right, not suggesting another tool, just wondering/brainstorming/thinking about what others are using for this kind of stuff (especially in dev work that involves > 1 machine/instance/<whatever u want to call it> and more closely matches an actual deployment; because for better or worse some features and bugs can only be worked on or reproduced in more complicated setups).
TL;DR dogfood and use openstack, it solves this problem well. Clark __________________________________________________________________________ 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
