On Thu, 19 Jun 2014 00:24:55 +0530
Kashyap Chamarthy <kchamart(a)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