maas-builds team mailing list archive

[Scott Moser <scott.moser@xxxxxxxxxxxxx>]

On Fri, 11 Apr 2014, Diogo Matsubara wrote:

> On Fri, Apr 11, 2014 at 10:49 AM, Raphaël Badin <raphael.badin@xxxxxxxxxxxxx
> > wrote:
>
> > On 04/11/2014 01:34 PM, Gavin Panella wrote:
> >
> >> On 11 April 2014 11:06, Raphaël Badin <raphael.badin@xxxxxxxxxxxxx>
> >> wrote:
> >>
> >>> There seem to be a problem with the proxy used in the lab: it's caching
> >>> the
> >>> simplestreams index too aggressively and the result is that the cluster
> >>> doesn't get the new simplestream data which contains reference to
> >>> Trusty's
> >>> 'rc' images.
> >>>
> >>> I imported the images manually (not going through the proxy), ran the
> >>> tests,
> >>> and got all the nodes enlisted and commissioned all right.  I saw on the
> >>> nodes' consoles that the 'rc' Trusty images was being used.
> >>>
> >>> I don't have permission to clean the proxy's cache so I'll ask Diogo to
> >>> help
> >>> me with that when he comes online.
> >>>
> >>
> >> I wonder if this might not be a cache problem:
> >>
> >
> > Actually, I think you're right.
> >
> > I'm getting different responses depending on which cache I hit:
> > http://paste.ubuntu.com/7234955/
> >
> > I assume the lab's caching proxy just hit the "wrong" cache.
> >
> >
> I asked Larry to re-validate the cache we use in the lab and he removed the
> swap.state file and restarted squid. It seems to have helped since I'm
> running a manual run and the tests passed over the failing point.
> Thanks Raphaël for diagnosing the issue.

Yeah, so this should be the last time this is a problem.
I trashed data, removing old stuff.  So if you got the old index, and went
looking, the stuff wasnt there.  That was an explicit design point of
simplestreams.  Datafiles are immutable, metadata files change.

In the future this is addressed by only removing files 3 days (or X time)
after metadata references them.  Ie, the same thing apt does.

We won't do that again, but I wanted to start fresh.

>
> Cheers,
> --
> Diogo M. Matsubara
>