Planning for AutoQA 0.7.0

[Tim Flink]

Now that 0.6.0 has been released and we haven't seen any new issues,
it's time to start looking at 0.7.0. Since we're all working on getting
Fedora 16 Alpha out the door, I think that we're going to hold off on
some of the major work for the time being but that doesn't mean we
can't start planning.

I'd like to schedule a teleconference for Thursday but before I do,
let's get a list together of the proposed features. Once we have a
list, I'll schedule a meeting.

My proposals are holdovers from 0.6.0 that didn't get finished:
 * #347 - Test results are sometimes linked incorrectly in bodhi
   - https://fedorahosted.org/autoqa/ticket/347

 * #355 - Determine Use Cases for Functional Self Tests
   - https://fedorahosted.org/autoqa/ticket/355

 * #353 - Create AutoQA Functional Self Test Cases
   - https://fedorahosted.org/autoqa/ticket/353

Any other proposals?

Tim

[Kamil Paral]

>  I'd like to schedule a teleconference for Thursday but before I
> do,
>  let's get a list together of the proposed features. Once we have a
>  list, I'll schedule a meeting. 
Let's do an email discussion this time. I don't see any topic we need to discuss
at real-time and I think emails are more convenient in this case.

>  
>  My proposals are holdovers from 0.6.0 that didn't get finished:
>  * #347 - Test results are sometimes linked incorrectly in bodhi
>  - https://fedorahosted.org/autoqa/ticket/347 
Definitely, I'd like to see this ticket at 0.7.

>  
>  * #355 - Determine Use Cases for Functional Self Tests
>  - https://fedorahosted.org/autoqa/ticket/355
>  
>  * #353 - Create AutoQA Functional Self Test Cases
>  - https://fedorahosted.org/autoqa/ticket/353 
This is #352. Which one do you have on mind?

I believe the above-mentioned tickets will take time. We can put it into the milestone, or
we don't have to, it doesn't matter, as long as we know we want to work on that
continuously. 

>  
>  Any other proposals? 
I was contacted by hongqing. He wants to provide a new test mediakit_sanity into 0.7,
which will check ISO images of Branched composes. He needs to download those images. Now
he uses a two stages method, first downloading the iso from remote to a local dir, then
another watcher monitoring the dir. He says implementing this ticket would reduce the
complexity.

#350 Add support for using file proxy
https://fedorahosted.org/autoqa/ticket/350

I'm willing to work on this ticket. But as I've written this down, I realized I
don't know the reason why hongqing needs to cache those ISOs. We need to cache those
files only if:
a) we run multiple tests on it
b) we run the same test several times of the same ISO

Can you clarify, hongqing? Thanks.


My other thoughts:
I believe our two major tests are in a fairly-good shape. Upgradepath starts to be solid,
and depcheck will need to be re-written/modified in the future, but that's a large
task and it works good enough nowadays. I'd like to concentrate on the infrastructure
now. We need to create a solid base that will allow us to easily trigger tests, store
results, report them, and finally allow independent test writers in the far future.

That means working on:
1. staging server + continuous integration and testing
2. resultsdb
3. easy deployment of clients
4. easy maintenance of servers

Resultdb is a Josef's playground, I hope he will provide some proposals here. CI and
testing seems like your area of interest, Tim, and the two tickets you mentioned match
that theme.

I am interested to work on:
#254 Transfer autoqa library to autotest clients
https://fedorahosted.org/autoqa/ticket/254

#196 Use standard logging facilities
https://fedorahosted.org/autoqa/ticket/196

There are in "nice to have soon" milestone, so again we can but don't have
to put it to 0.7 milestone directly.

Again I'd like to release 0.7 in about three to four weeks, what's done is done,
the rest is pushed to a later release.

Thoughts?

[Josef Skladanka]

Ad ResultsDB:

I'd like to add "store in resultsdb" option to our post_results process, so
I (we ;-)) can start to catch some bugs on that front.

For that, I need a box to run resultsdb. No huge requirements, just an IP accessible from
the test-clients, mysql and python >= 2.6 should be more than enough. For starters
I'll probably run the beast on my laptop, so I can react fast and test out new
versions during first week or two. Then I'd like to move it to either staging or
production autotest server, in order to be able to move my laptop :)

The initial coding for enabling resultsdb storage should not take more than a day or two.

J.

----- Original Message -----
>  From: "Kamil Paral" <kparal(a)redhat.com&gt;
>  To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org&gt;
>  Sent: Wednesday, August 10, 2011 2:03:06 PM
>  Subject: Re: Planning for AutoQA 0.7.0
>  > I'd like to schedule a teleconference for Thursday but before I do,
>  > let's get a list together of the proposed features. Once we have a
>  > list, I'll schedule a meeting.
>  
>  Let's do an email discussion this time. I don't see any topic we need
>  to discuss at real-time and I think emails are more convenient in this
>  case.
>  
>  >
>  > My proposals are holdovers from 0.6.0 that didn't get finished:
>  > * #347 - Test results are sometimes linked incorrectly in bodhi
>  > - https://fedorahosted.org/autoqa/ticket/347
>  
>  Definitely, I'd like to see this ticket at 0.7.
>  
>  >
>  > * #355 - Determine Use Cases for Functional Self Tests
>  > - https://fedorahosted.org/autoqa/ticket/355
>  >
>  > * #353 - Create AutoQA Functional Self Test Cases
>  > - https://fedorahosted.org/autoqa/ticket/353
>  
>  This is #352. Which one do you have on mind?
>  
>  I believe the above-mentioned tickets will take time. We can put it
>  into the milestone, or we don't have to, it doesn't matter, as long as
>  we know we want to work on that continuously.
>  
>  >
>  > Any other proposals?
>  
>  I was contacted by hongqing. He wants to provide a new test
>  mediakit_sanity into 0.7, which will check ISO images of Branched
>  composes. He needs to download those images. Now he uses a two stages
>  method, first downloading the iso from remote to a local dir, then
>  another watcher monitoring the dir. He says implementing this ticket
>  would reduce the complexity.
>  
>  #350 Add support for using file proxy
>  https://fedorahosted.org/autoqa/ticket/350
>  
>  I'm willing to work on this ticket. But as I've written this down, I
>  realized I don't know the reason why hongqing needs to cache those
>  ISOs. We need to cache those files only if:
>  a) we run multiple tests on it
>  b) we run the same test several times of the same ISO
>  
>  Can you clarify, hongqing? Thanks.
>  
>  
>  My other thoughts:
>  I believe our two major tests are in a fairly-good shape. Upgradepath
>  starts to be solid, and depcheck will need to be re-written/modified
>  in the future, but that's a large task and it works good enough
>  nowadays. I'd like to concentrate on the infrastructure now. We need
>  to create a solid base that will allow us to easily trigger tests,
>  store results, report them, and finally allow independent test writers
>  in the far future.
>  
>  That means working on:
>  1. staging server + continuous integration and testing
>  2. resultsdb
>  3. easy deployment of clients
>  4. easy maintenance of servers
>  
>  Resultdb is a Josef's playground, I hope he will provide some
>  proposals here. CI and testing seems like your area of interest, Tim,
>  and the two tickets you mentioned match that theme.
>  
>  I am interested to work on:
>  #254 Transfer autoqa library to autotest clients
>  https://fedorahosted.org/autoqa/ticket/254
>  
>  #196 Use standard logging facilities
>  https://fedorahosted.org/autoqa/ticket/196
>  
>  There are in "nice to have soon" milestone, so again we can but don't
>  have to put it to 0.7 milestone directly.
>  
>  Again I'd like to release 0.7 in about three to four weeks, what's
>  done is done, the rest is pushed to a later release.
>  
>  Thoughts?
>  _______________________________________________
>  autoqa-devel mailing list
>  autoqa-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/autoqa-devel

[Tim Flink]

On Wed, 10 Aug 2011 08:03:06 -0400 (EDT)
Kamil Paral <kparal(a)redhat.com&gt; wrote:

>  Let's do an email discussion this time. I don't see any topic
> we need
>  to discuss at real-time and I think emails are more convenient in
>  this case. 
Either way - I'm flexible.

>  > 
>  > My proposals are holdovers from 0.6.0 that didn't get finished:
>  > * #347 - Test results are sometimes linked incorrectly in bodhi
>  > - https://fedorahosted.org/autoqa/ticket/347
>  
>  Definitely, I'd like to see this ticket at 0.7. 
Especially since it got re-reported yesterday.

>  > 
>  > * #355 - Determine Use Cases for Functional Self Tests
>  > - https://fedorahosted.org/autoqa/ticket/355
>  > 
>  > * #353 - Create AutoQA Functional Self Test Cases
>  > - https://fedorahosted.org/autoqa/ticket/353
>  
>  This is #352. Which one do you have on mind? 
Whoops, my bad. I was trying to keep the number of tickets down since I
don't think that 355, 353 and 352 are going to be practical in 2-3
weeks.

To be honest, I'm all for 355 and pull in 353 and/or 352 as time
permits.

>  I believe the above-mentioned tickets will take time. We can put it
>  into the milestone, or we don't have to, it doesn't matter, as long
>  as we know we want to work on that continuously.  
Yeah, let's just pull in 355 for 0.7.0.

>  > 
>  > Any other proposals?
>  
>  I was contacted by hongqing. He wants to provide a new test
>  mediakit_sanity into 0.7, which will check ISO images of Branched
>  composes. He needs to download those images. Now he uses a two stages
>  method, first downloading the iso from remote to a local dir, then
>  another watcher monitoring the dir. He says implementing this ticket
>  would reduce the complexity.
>  
>  #350 Add support for using file proxy
>  https://fedorahosted.org/autoqa/ticket/350
>  
>  I'm willing to work on this ticket. But as I've written this down, I
>  realized I don't know the reason why hongqing needs to cache those
>  ISOs. We need to cache those files only if: a) we run multiple tests
>  on it b) we run the same test several times of the same ISO
>  
>  Can you clarify, hongqing? Thanks. 
Yeah, I'd like to get more information on this one. I'm unclear on why
a file proxy would be a good solution for caching ISOs but I also don't
pretend to understand everything that is being done in the ISO tests.

>  My other thoughts:
>  I believe our two major tests are in a fairly-good shape. Upgradepath
>  starts to be solid, and depcheck will need to be re-written/modified
>  in the future, but that's a large task and it works good enough
>  nowadays. I'd like to concentrate on the infrastructure now. We need
>  to create a solid base that will allow us to easily trigger tests,
>  store results, report them, and finally allow independent test
>  writers in the far future.
>  
>  That means working on:
>  1. staging server + continuous integration and testing
>  2. resultsdb
>  3. easy deployment of clients
>  4. easy maintenance of servers
>  
>  Resultdb is a Josef's playground, I hope he will provide some
>  proposals here. CI and testing seems like your area of interest, Tim,
>  and the two tickets you mentioned match that theme. 
Yeah, I agree that its time to start working on resultsdb again.

I actually think that 1, 3 and 4 are going to tie in together assuming
that we go with what I have planned. I'm putting proposals together
that will make that more clear since I haven't talked a whole lot about
what I'd like to do.

>  I am interested to work on:
>  #254 Transfer autoqa library to autotest clients
>  https://fedorahosted.org/autoqa/ticket/254 
I'm wondering if this could be solved with one of the proposals I have
in mind but I'm not sure which would be a better solution. I'll get
that done today and start the discussion.

>  #196 Use standard logging facilities
>  https://fedorahosted.org/autoqa/ticket/196 
This would be nice to have done.

Tim

[James Laska]

On Wed, 2011-08-10 at 08:00 -0600, Tim Flink wrote:
>  On Wed, 10 Aug 2011 08:03:06 -0400 (EDT)
>  Kamil Paral <kparal(a)redhat.com&gt; wrote:
>  
>  > Let's do an email discussion this time. I don't see any topic we need
>  > to discuss at real-time and I think emails are more convenient in
>  > this case.
>  
>  Either way - I'm flexible.
>  
>  > > 
>  > > My proposals are holdovers from 0.6.0 that didn't get finished:
>  > > * #347 - Test results are sometimes linked incorrectly in bodhi
>  > > - https://fedorahosted.org/autoqa/ticket/347
>  > 
>  > Definitely, I'd like to see this ticket at 0.7.
>  
>  Especially since it got re-reported yesterday.
>  
>  > > 
>  > > * #355 - Determine Use Cases for Functional Self Tests
>  > > - https://fedorahosted.org/autoqa/ticket/355
>  > > 
>  > > * #353 - Create AutoQA Functional Self Test Cases
>  > > - https://fedorahosted.org/autoqa/ticket/353
>  > 
>  > This is #352. Which one do you have on mind?
>  
>  Whoops, my bad. I was trying to keep the number of tickets down since I
>  don't think that 355, 353 and 352 are going to be practical in 2-3
>  weeks.
>  
>  To be honest, I'm all for 355 and pull in 353 and/or 352 as time
>  permits.
>  
>  > I believe the above-mentioned tickets will take time. We can put it
>  > into the milestone, or we don't have to, it doesn't matter, as long
>  > as we know we want to work on that continuously. 
>  
>  Yeah, let's just pull in 355 for 0.7.0.
>  
>  > > 
>  > > Any other proposals?
>  > 
>  > I was contacted by hongqing. He wants to provide a new test
>  > mediakit_sanity into 0.7, which will check ISO images of Branched
>  > composes. He needs to download those images. Now he uses a two stages
>  > method, first downloading the iso from remote to a local dir, then
>  > another watcher monitoring the dir. He says implementing this ticket
>  > would reduce the complexity.
>  > 
>  > #350 Add support for using file proxy
>  > https://fedorahosted.org/autoqa/ticket/350
>  > 
>  > I'm willing to work on this ticket. But as I've written this down, I
>  > realized I don't know the reason why hongqing needs to cache those
>  > ISOs. We need to cache those files only if: a) we run multiple tests
>  > on it b) we run the same test several times of the same ISO
>  > 
>  > Can you clarify, hongqing? Thanks.
>  
>  Yeah, I'd like to get more information on this one. I'm unclear on why
>  a file proxy would be a good solution for caching ISOs but I also don't
>  pretend to understand everything that is being done in the ISO tests. 
Hongqing can correct me of course.  The challenge is to find a simple
method to avoid having test clients always re-downloading test ISO
images (boot.iso isn't so bad, but constantly downloading the DVD.iso
stinks).  More specifically, it seemed to me that having our install
testsuite saturate the download servers was a bad idea.

The ideas that came to mind where to either support a multi-stage event
watcher where stage#1 would download the ISO images to the autoqa
server, and then stage#2 would expose the downloaded images to test
clients (either via http/ftp/nfs).  Another thought was to use a proxy
on the autoqa server to accomplish the same thing behind the scenes.
I'm sure we can come up with some additional ideas to either reduce ISO
downloads outside the autoqa network. 

Thanks,
James

[Hongqing Yang]

----- Original Message -----
>  From: "James Laska" <jlaska(a)redhat.com&gt;
>  To: autoqa-devel(a)lists.fedorahosted.org
>  Sent: Thursday, August 11, 2011 10:20:28 PM
>  Subject: Re: Planning for AutoQA 0.7.0
>  On Wed, 2011-08-10 at 08:00 -0600, Tim Flink wrote:
>  > On Wed, 10 Aug 2011 08:03:06 -0400 (EDT)
>  > Kamil Paral <kparal(a)redhat.com&gt; wrote:
>  >
>  > > Let's do an email discussion this time. I don't see any topic we
>  > > need
>  > > to discuss at real-time and I think emails are more convenient in
>  > > this case.
>  >
>  > Either way - I'm flexible.
>  >
>  > > >
>  > > > My proposals are holdovers from 0.6.0 that didn't get finished:
>  > > > * #347 - Test results are sometimes linked incorrectly in bodhi
>  > > > - https://fedorahosted.org/autoqa/ticket/347
>  > >
>  > > Definitely, I'd like to see this ticket at 0.7.
>  >
>  > Especially since it got re-reported yesterday.
>  >
>  > > >
>  > > > * #355 - Determine Use Cases for Functional Self Tests
>  > > > - https://fedorahosted.org/autoqa/ticket/355
>  > > >
>  > > > * #353 - Create AutoQA Functional Self Test Cases
>  > > > - https://fedorahosted.org/autoqa/ticket/353
>  > >
>  > > This is #352. Which one do you have on mind?
>  >
>  > Whoops, my bad. I was trying to keep the number of tickets down
>  > since I
>  > don't think that 355, 353 and 352 are going to be practical in 2-3
>  > weeks.
>  >
>  > To be honest, I'm all for 355 and pull in 353 and/or 352 as time
>  > permits.
>  >
>  > > I believe the above-mentioned tickets will take time. We can put
>  > > it
>  > > into the milestone, or we don't have to, it doesn't matter, as
>  > > long
>  > > as we know we want to work on that continuously.
>  >
>  > Yeah, let's just pull in 355 for 0.7.0.
>  >
>  > > >
>  > > > Any other proposals?
>  > >
>  > > I was contacted by hongqing. He wants to provide a new test
>  > > mediakit_sanity into 0.7, which will check ISO images of Branched
>  > > composes. He needs to download those images. Now he uses a two
>  > > stages
>  > > method, first downloading the iso from remote to a local dir, then
>  > > another watcher monitoring the dir. He says implementing this
>  > > ticket
>  > > would reduce the complexity.
>  > >
>  > > #350 Add support for using file proxy
>  > > https://fedorahosted.org/autoqa/ticket/350
>  > >
>  > > I'm willing to work on this ticket. But as I've written this down,
>  > > I
>  > > realized I don't know the reason why hongqing needs to cache those
>  > > ISOs. We need to cache those files only if: a) we run multiple
>  > > tests
>  > > on it b) we run the same test several times of the same ISO
>  > >
>  > > Can you clarify, hongqing? Thanks.
>  >
>  > Yeah, I'd like to get more information on this one. I'm unclear on
>  > why
>  > a file proxy would be a good solution for caching ISOs but I also
>  > don't
>  > pretend to understand everything that is being done in the ISO
>  > tests.
>  
>  Hongqing can correct me of course. The challenge is to find a simple
>  method to avoid having test clients always re-downloading test ISO
>  images (boot.iso isn't so bad, but constantly downloading the DVD.iso
>  stinks). More specifically, it seemed to me that having our install
>  testsuite saturate the download servers was a bad idea.
>  
>  The ideas that came to mind where to either support a multi-stage
>  event
>  watcher where stage#1 would download the ISO images to the autoqa
>  server, and then stage#2 would expose the downloaded images to test
>  clients (either via http/ftp/nfs). Another thought was to use a proxy
>  on the autoqa server to accomplish the same thing behind the scenes.
>  I'm sure we can come up with some additional ideas to either reduce
>  ISO
>  downloads outside the autoqa network.
>  
>  Thanks,
>  James 
I have modified the watchers/iso/watcher.py, James wrote before, to monitor and download
the images 
from http://dl.fp.org/alt/stage to directory /var/cache/autoqa/install-isos,  this will
not trigger
the event, and I also created watchers/iso/watcher.py to monitor
/var/cache/autoqa/install-isos, 
which will trigger the event. 
I have discussed this with Kamil, we both do not have any experience to use squid, Kamil
would like
to explore it, I will also test it on my machine. 
And if we solved the downloading issue, I would like to add Ticket #186 Automate media kit
sanity tests
into AutoQA 0.7.0.

Hongqing

[Kamil Paral]

>  >
>  > Hongqing can correct me of course. The challenge is to find a simple
>  > method to avoid having test clients always re-downloading test ISO
>  > images (boot.iso isn't so bad, but constantly downloading the
>  > DVD.iso
>  > stinks). More specifically, it seemed to me that having our install
>  > testsuite saturate the download servers was a bad idea.
>  >
>  > The ideas that came to mind where to either support a multi-stage
>  > event
>  > watcher where stage#1 would download the ISO images to the autoqa
>  > server, and then stage#2 would expose the downloaded images to test
>  > clients (either via http/ftp/nfs). Another thought was to use a
>  > proxy
>  > on the autoqa server to accomplish the same thing behind the scenes.
>  > I'm sure we can come up with some additional ideas to either reduce
>  > ISO
>  > downloads outside the autoqa network.
>  >
>  > Thanks,
>  > James
>  
>  I have modified the watchers/iso/watcher.py, James wrote before, to
>  monitor and download the images
>  from http://dl.fp.org/alt/stage to directory
>  /var/cache/autoqa/install-isos, this will not trigger
>  the event, and I also created watchers/iso/watcher.py to monitor
>  /var/cache/autoqa/install-isos,
>  which will trigger the event.
>  I have discussed this with Kamil, we both do not have any experience
>  to use squid, Kamil would like
>  to explore it, I will also test it on my machine.
>  And if we solved the downloading issue, I would like to add Ticket
>  #186 Automate media kit sanity tests
>  into AutoQA 0.7.0.
>  
>  Hongqing
>   
My question is different. Do we need to use those DVD images multiple times? Because if we
test every image just *once* (we run mediakit_sanity test and that's all) there's
no reason to complicate it (at the moment), the mediakit_sanity test can download the ISO.
The bandwidth si the same, regardless whether it's downloaded by watcher or by a
test.

[Hongqing Yang]

----- Original Message -----
>  From: "Kamil Paral" <kparal(a)redhat.com&gt;
>  To: "AutoQA development" <autoqa-devel(a)lists.fedorahosted.org&gt;
>  Sent: Friday, August 12, 2011 7:05:46 PM
>  Subject: Re: Planning for AutoQA 0.7.0
>  > >
>  > > Hongqing can correct me of course. The challenge is to find a
>  > > simple
>  > > method to avoid having test clients always re-downloading test ISO
>  > > images (boot.iso isn't so bad, but constantly downloading the
>  > > DVD.iso
>  > > stinks). More specifically, it seemed to me that having our
>  > > install
>  > > testsuite saturate the download servers was a bad idea.
>  > >
>  > > The ideas that came to mind where to either support a multi-stage
>  > > event
>  > > watcher where stage#1 would download the ISO images to the autoqa
>  > > server, and then stage#2 would expose the downloaded images to
>  > > test
>  > > clients (either via http/ftp/nfs). Another thought was to use a
>  > > proxy
>  > > on the autoqa server to accomplish the same thing behind the
>  > > scenes.
>  > > I'm sure we can come up with some additional ideas to either
>  > > reduce
>  > > ISO
>  > > downloads outside the autoqa network.
>  > >
>  > > Thanks,
>  > > James
>  >
>  > I have modified the watchers/iso/watcher.py, James wrote before, to
>  > monitor and download the images
>  > from http://dl.fp.org/alt/stage to directory
>  > /var/cache/autoqa/install-isos, this will not trigger
>  > the event, and I also created watchers/iso/watcher.py to monitor
>  > /var/cache/autoqa/install-isos,
>  > which will trigger the event.
>  > I have discussed this with Kamil, we both do not have any experience
>  > to use squid, Kamil would like
>  > to explore it, I will also test it on my machine.
>  > And if we solved the downloading issue, I would like to add Ticket
>  > #186 Automate media kit sanity tests
>  > into AutoQA 0.7.0.
>  >
>  > Hongqing
>  >
>  
>  My question is different. Do we need to use those DVD images multiple
>  times? Because if we test every image just *once* (we run
>  mediakit_sanity test and that's all) there's no reason to complicate
>  it (at the moment), the mediakit_sanity test can download the ISO. The
>  bandwidth si the same, regardless whether it's downloaded by watcher
>  or by a test.
>   
Yes,  for mediakit_sanity test, we only need run once to test all the images,
but considering we will merge other tests, such as installation from dvd, upgrade.
etc. If we do not use squid or the two stages download methodology, the isos will be
downloaded many times.  Of course,  I will not encounter this problem if only
mediakit_sanity test is added into AutoQA.

Hongqing

[Kamil Paral]

>  Yes, for mediakit_sanity test, we only need run once to test all the
>  images,
>  but considering we will merge other tests, such as installation from
>  dvd, upgrade.
>  etc. If we do not use squid or the two stages download methodology,
>  the isos will be
>  downloaded many times. Of course, I will not encounter this problem if
>  only
>  mediakit_sanity test is added into AutoQA.
>  
>  Hongqing 
OK, that means that #350 "Add support for using file proxy" is nice to have soon
ticket, but it isn't hard requirement for 0.7 or for mediakit_sanity. Just write the
test to download that ISO image. If we implement the ticket soon, the download will be
cached, otherwise it won't be cached. Doesn't matter as long as we have just one
test working with that image.

Thoughts?

[Kamil Paral]

>  > Yes, for mediakit_sanity test, we only need run once to test all
> the
>  > images,
>  > but considering we will merge other tests, such as installation from
>  > dvd, upgrade.
>  > etc. If we do not use squid or the two stages download methodology,
>  > the isos will be
>  > downloaded many times. Of course, I will not encounter this problem
>  > if
>  > only
>  > mediakit_sanity test is added into AutoQA.
>  >
>  > Hongqing
>  
>  OK, that means that #350 "Add support for using file proxy" is nice to
>  have soon ticket, but it isn't hard requirement for 0.7 or for
>  mediakit_sanity. Just write the test to download that ISO image. If we
>  implement the ticket soon, the download will be cached, otherwise it
>  won't be cached. Doesn't matter as long as we have just one test
>  working with that image.
>  
>  Thoughts? 
I just realized that ISO download caching is useful even when we have just a single test
using it. It is useful for development, when you need to run the test over and over again
with the same input data (ISO). From some reason it didn't cross my mind before.
I'll try to have a look at the proxy ticket once I finish my current work.

Kamil