Reliability of Fedora infrastructure to download cloud images

[Kevin Fenzi]

On Thu, 19 Jun 2014 00:24:55 +0530
Kashyap Chamarthy <kchamart at redhat.com> wrote:

> [I'm not subscribed to this list, please keep me in CC.]
> 
> Heya,
> 
> A little while ago, we (Matthew Miller, myself, Attila Fazekas
> (upstream OpenStack developer) had an IRC discussion (on
> #openstack-qa, Freenode) with OpenStack upstream CI infrastructure
> folks about their concerns for continuing to have Fedora as a default
> to run as CI voting guest (Nova instance). They (mostly Sean Dague -
> a major upstream OpenStack contributor who voiced these) outlined a
> few issues:

I'm not famillar with the terminology, what does a 'voting guest' mean? 

>   1. It's not possible to download from the fedora infrastructure
>      reliably - 10% failure rate from their cloud providers (HP and
>      RAX).
>       - About this point, when mattdm inquired - "is the failure in
>         hitting the fedora mirrors or fedora core infrastructure?",
>         their response - "I don't fully know, I think going through
> the url we are using we get bounced to mirrors".

Yeah, more data would be very nice here... what url(s) they are using,
what error codes if any they get back? 

Are these the released cloud images? f19/20? Or nightlies or ?

How often do they download? Once a image is loaded, I am not sure why
they would re-download it unless it's changed? Or unless they are
grabbing nightly rawhide images?
 
>   2. There are possibly issues with the normal upstream fedora image
>      that could be fixed with custom respin.
>       - NOTE: I'm doubtful of this idea, as existing Fedora cloud
> images itself are not really extensively tested. I'd think focusing on
>         _official_ cloud images and having a solid set of tests so
> that it can be consumed by cloud projects (OpenStack, etc).
> 
>       - Having a custom respin means that we're off the main path for
>         testing of the image -- which again needs _some_ level of
>         assurance that it can be used in a higher-level cloud
> project's CI infr- which again needs _some_ level of assurance that
> it can be used in a higher-level cloud project's CI infra.

Yeah, I would think we would like to avoid that... and try and merge in
the changes they need for images instead of them going and making their
own that only they use. 

>   3. Another important point OpenStack infra folks emphasized is -
> these images will get 4000 test runs a week on them 

Cool. 
 
> Any suggestions to allay these are welcome.

Happy to try and solve any bottlenecks they are having...

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20140619/faacc9ee/attachment.sig>