[openstack-dev] A daily life of a dev in ${name_your_fav_project}

Joshua Harlow harlowja at fastmail.com
Fri Aug 26 17:31:14 UTC 2016


<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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list