On 4/4/17, 12:06 AM, "Clark Boylan" <[email protected]> wrote:
> After some thought I think my preferred method of rolling this out would
> be to blacklist libvirt-python from our wheel mirror building entirely
> and force installs to happen from source so that we are base Xenial and
> $UCA_version independent (local testing of these builds show it only
> takes a few seconds). Then have specific jobs (like devstack) explicitly
> opt into the UCA repo appropriate for them (if any). This last bit is
> from feedback from OpenStack Ansible that having the base images be
> fairly clean is desirable, but it would also be hard to know which
> version of UCA is appropriate for our Xenial images (this likely differs
> based on the job).
An approach that could be taken here is to bake the repo config (and install
packages from that repo) for the UCA version that’s the earliest version we
support for that OS. For example – the earliest version that supports Xenial is
Newton, so pre-configure and install packages into the image from UCA
Xenial/Newton. Then in any jobs which care about which version of UCA is used
the repo config can be changed and the packages updated. This potentially saves
a little gate time.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
________________________________
Rackspace Limited is a company registered in England & Wales (company
registered number 03897010) whose registered office is at 5 Millington Road,
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
contain confidential or privileged information intended for the recipient. Any
dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by
e-mail at [email protected] and delete the original message. Your cooperation
is appreciated.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev