Hello Solum Developers,
When we were designing the operator languagepack feature for Solum, we wanted
to make use of public urls to download operator LPs, such as those available
for CDN backed swift containers we have at Rackspace, or any publicly
accessible url. This would mean that when a user chooses to build applications
on to??p of a languagepack provided by the operator, we use a url to 'wget' the
LP image.
Recently, we have started noticing a number of failures because of corrupted
docker images downloaded using 'wget'. The docker images work fine when we
download them manually with a swift client and use them. The corruption seem to
be happening when we try to download a large image using 'wget' and there are
dropped packets or intermittent network issues.
My thinking is to start using the swift client to download operator LPs by
default instead of wget. The swift client already implements retry logic,
downloading large images in chunks, etc. This means we would not get the
niceties of using publicly accessible urls. However, the feature will be more
reliable and robust.
The implementation would be as follows:
* ?We'll use the existing service tenant configuration available in the
solum config file to authenticate and store operator languagepacks using the
swift client. We were using a different tenant to build and host LPs, but now
that we require the tenants credentials in the config file, it's best to reuse
the existing service tenant creds. Note: If we don't, we'll have 3 separate
tenants to maintain.
* ?Service tenant
* Operator languagepack tenant
* Global admin tenant
* I'll keep the option to download the operator languagepacks from a
publicly available url. I'll allow operators to choose which method they want
to use by changing a setting in the solum config file.
FYI: In my tests, I've noticed that downloading an image using the swift client
is twice as fast as downloading the same image using 'wget' from a CDN url.
Thanks,
Murali
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
