Hello Adrian,
thanks for the quick reply, and sorry for my delayed response.
On 09/03/2014 04:42 PM, Adrian Otto wrote:
We have noticed lately that our devstack setup does not always work.
[...] We have discussed ways to mitigate this. One idea was to
select a particular devstack from a prior OpenStack release to help
cut down on the rate of change. [...] We also considered additional
functional tests for devstack to run when new code is submitted. I
suppose we could run testing continuously in loops in attempts to
detect non-determinism. [...] All of the above are opportunities for
us to improve matters going forward. There are probably even better
ideas we should consider as well.
I'm currently toying with the following approach: Clone all necessary
repos locally (staging repos), and configure devstack to use them (via
GIT_BASE). At fixed intervals, automatically update the staging repos,
and start the provisioning of a dev env. If that goes well, run the
Solum tests with it. If that is also successful, the state in the
staging repos gets pulled into a second set of local repos (setup
repos), which I can use for actual dev env provisioning. If things fail,
we could give it a couple of retries (for the non-determinism you
mentioned), or just wait for the next interval.
So there should (hopefully) always be a fairly recent and usable state
in the setup repos. How well this works will mostly depend on the
interval, I guess. I.e., the shorter the interval, the higher the chance
for filtering out a usable state. Of course, if things get broken
permanently, the state in the setup repos would no longer advance and
we'd need to look into the cause and take actions (see example below).
This approach doesn't really solve the root cause, but could make
setting up a dev env a bit more reliable. I got the first part in place,
i.e. provisioning from staging repos. I'll now experiment with the
second part, and let you know.
For now, we would like to help you get past the friction you are
experiencing so you can get a working environment up.
I could resolve the two problems I mentioned manually and get the dev
env working. However, this brings up a question:
after devstack provisioned OS, q-dhcp and q-l3 were not running.
The former refused to start due to an updated version requirement
for dnsmasq (see
https://bugs.launchpad.net/openstack-manuals/+bug/1347153) that
was not met
This problem is also described here:
http://netapp.github.io/openstack/2014/08/15/manila-devstack/
While I installed dnsmasq 2.63 manually, they used Ubuntu 14.04 to get
around the problem. Is it maybe time to upgrade the base for the dev env
to 14.04, or would that cause many other problems? Have you tried that
out? If you have a pointer to an appropriate 14.04 image I can configure
in Vagrant, I'd like to play with that a bit. Maybe that would also
solve the problem with openvswitch.
Kind regards,
Alex
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
