--archive_dir will now serve existing update.gz

When updates are pre-generated outside of the Dev Server, there is currently no easy and efficient way to serve them. 

With this change, the --archive_dir option no longer supports image.zip updates and relies exclusively on pre-generated update.gz and stateful.tgz files.

Change-Id: Ibe15f7517ded375140c33f83d92a17283e827dc6

BUG=chromium-os:9775
TEST=Running in production in Kirkland test lab.

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=723ec47

[DaleCurtis, 2010-11-23 03:40:52]

git cl finally cooperated so I could get this up.

[sosa, 2010-11-23 19:50:36]

http://codereview.chromium.org/5297002/diff/1/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode25
autoupdate.py:25: serve_only: Serve updates from a pre-built image.zip file. If
an update.gz
is newer*

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode26
autoupdate.py:26: newer than the extracted image exists in the static_dir, it
will be
This is a little confusing.  Can you make another pass at this docstring.

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode554
autoupdate.py:554: os.path.getmtime(image_path) <
os.path.getmtime(update_path)):
Can you fold this into GenerateImageFromZip and remove Don's TODO?  That seems
like the better place.  Also, why not use MD5 hash's versus timestamps?

[DaleCurtis, 2010-11-23 20:11:20]

http://codereview.chromium.org/5297002/diff/1/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode554
autoupdate.py:554: os.path.getmtime(image_path) <
os.path.getmtime(update_path)):
I can if you really want to. I think it's confusing to put it into
GenerateImageFromZip though unless we want to change the method.

Alternatively, does anyone actually use the ZIP generation? If not lets just
remove it and change serve_only to actually mean serve_only. Meaning, update.gz
and stateful.tgz must always be in the static_dir. No more 0-byte
chromiumos_test_image.bin's or hard to explain time stamp/md5 checks.

Going this route would also remove any of the caching concerns noted in Don's
TODO.

On 2010/11/23 19:50:36, sosa wrote:
> Can you fold this into GenerateImageFromZip and remove Don's TODO?  That seems
> like the better place.  Also, why not use MD5 hash's versus timestamps?

[sosa, 2010-11-23 20:45:57]

http://codereview.chromium.org/5297002/diff/1/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode554
autoupdate.py:554: os.path.getmtime(image_path) <
os.path.getmtime(update_path)):
I'm ok with removing the logic but you many want to email chromium-os-dev in
case.  I don't know of anyone who uses it as it was specifically added to
support test automation.

On 2010/11/23 20:11:20, dalec wrote:
> I can if you really want to. I think it's confusing to put it into
> GenerateImageFromZip though unless we want to change the method.
> 
> Alternatively, does anyone actually use the ZIP generation? If not lets just
> remove it and change serve_only to actually mean serve_only. Meaning,
update.gz
> and stateful.tgz must always be in the static_dir. No more 0-byte
> chromiumos_test_image.bin's or hard to explain time stamp/md5 checks.
> 
> Going this route would also remove any of the caching concerns noted in Don's
> TODO.
> 
> On 2010/11/23 19:50:36, sosa wrote:
> > Can you fold this into GenerateImageFromZip and remove Don's TODO?  That
seems
> > like the better place.  Also, why not use MD5 hash's versus timestamps?
>

[DaleCurtis, 2010-11-23 21:02:37]

http://codereview.chromium.org/5297002/diff/1/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode554
autoupdate.py:554: os.path.getmtime(image_path) <
os.path.getmtime(update_path)):
Sent, I'll give it until next week before making any changes. We've already got
a patch in place to keep our Dev Server running.

On 2010/11/23 20:45:57, sosa wrote:
> I'm ok with removing the logic but you many want to email chromium-os-dev in
> case.  I don't know of anyone who uses it as it was specifically added to
> support test automation.
> 
> On 2010/11/23 20:11:20, dalec wrote:
> > I can if you really want to. I think it's confusing to put it into
> > GenerateImageFromZip though unless we want to change the method.
> > 
> > Alternatively, does anyone actually use the ZIP generation? If not lets just
> > remove it and change serve_only to actually mean serve_only. Meaning,
> update.gz
> > and stateful.tgz must always be in the static_dir. No more 0-byte
> > chromiumos_test_image.bin's or hard to explain time stamp/md5 checks.
> > 
> > Going this route would also remove any of the caching concerns noted in
Don's
> > TODO.
> > 
> > On 2010/11/23 19:50:36, sosa wrote:
> > > Can you fold this into GenerateImageFromZip and remove Don's TODO?  That
> seems
> > > like the better place.  Also, why not use MD5 hash's versus timestamps?
> > 
>

[DaleCurtis, 2010-11-30 19:05:10]

PTAL. I didn't get any pings back about --archive_dir usage by anyone else, so
I've made the changes to remove ZIP support.

On 2010/11/23 21:02:37, dalec wrote:
> http://codereview.chromium.org/5297002/diff/1/autoupdate.py
> File autoupdate.py (right):
> 
> http://codereview.chromium.org/5297002/diff/1/autoupdate.py#newcode554
> autoupdate.py:554: os.path.getmtime(image_path) <
> os.path.getmtime(update_path)):
> Sent, I'll give it until next week before making any changes. We've already
got
> a patch in place to keep our Dev Server running.
> 
> On 2010/11/23 20:45:57, sosa wrote:
> > I'm ok with removing the logic but you many want to email chromium-os-dev in
> > case.  I don't know of anyone who uses it as it was specifically added to
> > support test automation.
> > 
> > On 2010/11/23 20:11:20, dalec wrote:
> > > I can if you really want to. I think it's confusing to put it into
> > > GenerateImageFromZip though unless we want to change the method.
> > > 
> > > Alternatively, does anyone actually use the ZIP generation? If not lets
just
> > > remove it and change serve_only to actually mean serve_only. Meaning,
> > update.gz
> > > and stateful.tgz must always be in the static_dir. No more 0-byte
> > > chromiumos_test_image.bin's or hard to explain time stamp/md5 checks.
> > > 
> > > Going this route would also remove any of the caching concerns noted in
> Don's
> > > TODO.
> > > 
> > > On 2010/11/23 19:50:36, sosa wrote:
> > > > Can you fold this into GenerateImageFromZip and remove Don's TODO?  That
> > seems
> > > > like the better place.  Also, why not use MD5 hash's versus timestamps?
> > > 
> >

[sosa, 2010-11-30 19:38:48]

Nit also please remove the unittest for this funciton in autoupdate_unittest.py

LGTM once those are done

http://codereview.chromium.org/5297002/diff/7001/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/7001/autoupdate.py#newcode56
autoupdate.py:56: # Caching is enabled if we are not doing serve_only
Remove part of this comment

[DaleCurtis, 2010-11-30 21:44:18]

Fixed. After talking with dgarrett, decided to remove caching_enabled flag
completely since serve_only code path doesn't touch it anymore.

Unit tests and in production testing passed.

http://codereview.chromium.org/5297002/diff/7001/autoupdate.py
File autoupdate.py (right):

http://codereview.chromium.org/5297002/diff/7001/autoupdate.py#newcode56
autoupdate.py:56: # Caching is enabled if we are not doing serve_only
On 2010/11/30 19:38:48, sosa wrote:
> Remove part of this comment

Done.

[sosa, 2010-11-30 22:04:40]

LGTM!