<div dir="ltr">Hi Jon,<div><br></div><div>Our test environment consists of 8 bare-metal servers. One server provides Cobbler and Puppet services and the other 7 are used for OpenStack. The entire OpenStack configuration is managed through Puppet.</div>
<div><br></div><div>In the past, we would re-provision the bare-metal servers with a fresh OS and then run Puppet to deploy OpenStack, but then we realized that we could do everything nested inside an OpenStack environment. So the bare-metal hardware is now a separate OpenStack environment which allows us to test several different projects' OpenStack configurations under one main test cloud.</div>
<div><br></div><div>To create a test environment, we have Vagrant profiles for cloud controllers, compute nodes, and swift nodes. Vagrant launches vms inside the test cloud, does any needed bootstrapping (basically emulating Cobbler's post-install hooks), the vms contact Puppet, and are then configured with the latest production configuration.</div>
<div><br></div><div><div>Our production network configurations have all been able to work in a nested OpenStack environment. Sometimes this creates nested VLANs, but we either ignore it or raise the MTU.</div></div><div><br>
</div><div>The only thing that we cannot reliably reproduce in this environment is the NetApp appliances that one production site runs. Unless NetApp would like to send us a free 3240? =)</div><div><br></div><div>The other caveat is that launching instances has to be done with qemu software virtualization. So far this has been fine. As long as an instance can boot, receive an IP, attach a volume, etc, then everything should be fine. We have not run into a case where an OpenStack configuration has caused a certain type of image to fail.</div>
<div><br></div><div>You make a good point about working with a production database dump. I'll look into this for our environment.</div><div><br></div><div><br></div><div>Each project's OpenStack configuration, like I mentioned, is stored in Puppet. The Puppet data is stored in a gitolite-based git repository. We use Hiera to separate the production and testing environment data (such as IP subnets, false passwords, etc).</div>
<div><br></div><div>Right now, our git workflow is very basic. We work out of the master branch and commit any changes once tested. We might try out r10k.</div><div><br></div><div>A side project of ours is to work on using Jenkins or a git hook to automatically provision a set of vms to test a commit. </div>
<div><br></div><div>Hope that helps. Let me know if you have any questions regarding a specific area.</div><div><br></div><div>Joe</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 8, 2014 at 2:28 PM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@jonproulx.com" target="_blank">jon@jonproulx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
My test environment is a couple of instances within my production<br>
cloud.  Mostly I've used this to test my config management (puppet<br>
community modules) in a sandbox especially around upgrades.<br>
<br>
In my first attempt at Grizzly -> Havana upgrade this worked fine in<br>
the clean empty sandbox, but tripped over a know and patched bug<br>
related to DB migrations on systems that had originally been installed<br>
pre-Grizzly (mine started as Essex).<br>
<br>
By pulling my production DB into my test environment I managed to<br>
prove the released patch worked for the first issue I saw and discover<br>
three more I was able to over come (still working on defining where<br>
the bugs are to report).<br>
<br>
But now of course the test database is full of references to the<br>
production compute nodes (though I did fix the endpoints to refer to<br>
the test endpoints), so I can't *really* test launching new instances.<br>
I'm also scratching my head over how to model our networking, but<br>
that's pretty site specific and I haven't been thinking long.<br>
<br>
An other issue I can't think how to reproduce in testing involves a<br>
case from our essex->folsom upgrade.  I forget the details as it was<br>
more than a year ago now, but it only involved instances that we<br>
running through the transition period and only for one of our<br>
projects/tenants.  That's likely an outlier that can never be<br>
deterministically caught.<br>
<br>
But these two really get me thinking about just how close I can get<br>
testing to keep step with production.<br>
<br>
Do you have a test environment?<br>
<br>
Is it in your cloud or dedicated hardware?<br>
<br>
How do you keep it close to production and how close do you manage?<br>
<br>
-Jon<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br></div>