On Thu, 2018-12-20 at 09:58 -0800, Chris Hoge wrote:
On Dec 17, 2018, at 9:44 PM, Tony Breeds <tony@bakeyournoodle.com> wrote:
On Thu, Dec 13, 2018 at 09:43:37AM -0800, Chris Hoge wrote:
There is a need for us to work out whether Loci is even appropriate for stable branch development. Over the last week or so the CentOS libvirt update has broken all stable branch builds as it introduced an incompatibility between the stable upper contraints of python- libvirt and libvirt.
Yup, as we've seen on https://review.openstack.org/#/c/622262 this is a common thing and happens with every CentOS minor release. We're working the update to make sure we don't cause more breakage as we try to fix this thing.
libvirt. If we start running stable builds, it might provide a useful gate signal for when stable source builds break against upstream distributions. It's something for the Loci team to think about as we work through refactoring our gate jobs.
That's interesting idea. Happy to discuss how we can do that in a way that makes sense for each project. How long does LOCI build take?
Loci makes one build for each OpenStack project you want to deploy. The requirements container takes the most time, as it does a pip wheel of every requirement listed in the openstack/requirements repository, then bind-mounts the complete set of wheels into the service containers during those builds to ensure a complete and consistent set of dependencies. Requirements must be done serially, but the rest of the builds can be done in parallel.
What I'm thinking is if we do stable builds of Loci that stand up a simplified all-in-one environment we can run Tempest against, we would both get a signal for the Loci stable build (as well as master) and a signal for requirements. Co-gating means we can check that an update to requirements to fix one distrubution does not negatively impact the stability of other distributions.
I have some very initial work on this in a personal project (this is how I like to spend some of my holiday down time), and we can bring it up as an agenda item for the Loci meeting tomorrow morning.
-Chris
I like the idea of having REAL testing of the loci images. Currently we just install software, and it's up to deployment tools to configure the images to match their needs. Doing a real test for all distros would be very nice, and a positive addition. I am curious about how we'd do this though. I suppose though it might require a new job, which will take far more time: After doing a building of the necessary images (more than one project!), we need to deploy them together and run tempest on them (therefore ensuring proper image building and co-installability). Or did you mean that you wanted to test each image building separately by running the minimum smoke tests for each image? What about reusing a deployment project job that's using loci in an experimental pipeline? Not sure to understand what you have written :) Regards, JP