The problem
So in a recent post i mentioned that we are running an Openstack staging environment that should reflect the production environment in every way possible. However, that is not the case at the moment.
Every time I redeploy the staging environment Juju updates all the packages to the latest versions. What i would like to achieve is to force Juju in some way to install the exact same versions of all the packages as in production, or find another solution with the same outcome.
My plan:
I cannot find a way to ensure this with Juju so i was looking into APT version pinning. The plan was to create a /etc/apt/preferences with all the packages listed from the production environment. This could be inserted into the machine by MAAS before Juju begins the installation and deployment, ensuring the exact same versions.
+1 to doing the apt pinning by using a cache/proxy to help maintain that. There’s config for using that in Juju. If you go the pinning route you might find that you need either custom cloud-init bits that can be passed in or it might be better to go the route of a subordinate charm that maintains the setup on the machines, though that’s a bit trickier as you need to get the subordinate on the machines ahead of time and it complicates the setup a bit.
Regarding the Proxy you are referring to the apt-http-proxy, apt-https-proxy in the model config. It looks like you can set that config in the juju environment aswell. I have never set one up myself, but will take a look at it.
However it looks like that solution should have been implemented at the beginning.
So my plan for using version pinning in the preferences file was to extract a list of all packages from the production environment and then populate this file in the staging environment during deployment using MAAS curtin.
This method is a bit more work, but as i have not prepared an APT proxy beforehand i think i’m stuck.
Do you know if Landscape could provide something similar?
We are looking into using aptly.info that has the ability to snapshot repositories and publish them separately which would solve our issue perfectly. We could choose to snapshot the production environment repository and share the same with our staging environment.
Thus knowing that both environment are exactly the same
I will update this post if we can get it up and running as planned.
Awesome, that sounds like a good path and I can’t wait to hear how that goes. If you find it working I think it would be a great discourse tutorial for other users
