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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev