[Openstack-operators] How do you keep your test env sync'ed to production?

Jonathan Proulx jon at jonproulx.com
Wed Jan 8 21:28:22 UTC 2014


Hi All,

My test environment is a couple of instances within my production
cloud.  Mostly I've used this to test my config management (puppet
community modules) in a sandbox especially around upgrades.

In my first attempt at Grizzly -> Havana upgrade this worked fine in
the clean empty sandbox, but tripped over a know and patched bug
related to DB migrations on systems that had originally been installed
pre-Grizzly (mine started as Essex).

By pulling my production DB into my test environment I managed to
prove the released patch worked for the first issue I saw and discover
three more I was able to over come (still working on defining where
the bugs are to report).

But now of course the test database is full of references to the
production compute nodes (though I did fix the endpoints to refer to
the test endpoints), so I can't *really* test launching new instances.
I'm also scratching my head over how to model our networking, but
that's pretty site specific and I haven't been thinking long.

An other issue I can't think how to reproduce in testing involves a
case from our essex->folsom upgrade.  I forget the details as it was
more than a year ago now, but it only involved instances that we
running through the transition period and only for one of our
projects/tenants.  That's likely an outlier that can never be
deterministically caught.

But these two really get me thinking about just how close I can get
testing to keep step with production.

Do you have a test environment?

Is it in your cloud or dedicated hardware?

How do you keep it close to production and how close do you manage?

-Jon



More information about the OpenStack-operators mailing list