canonical-ci-engineering team mailing list archive

[Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx>]

>>>>> Ursula Junque <ursula.junque@xxxxxxxxxxxxx> writes:

    > On Mon, Dec 2, 2013 at 8:38 PM, Andy Doan <andy.doan@xxxxxxxxxxxxx> wrote:
    >> On 12/02/2013 02:41 PM, Francis Ginther wrote:
    >> 
    >>> We do still need to perform a clean. For example: If we have a package
    >>> 'foo' on our build ppa with version 20131201.1, it will be promoted to
    >>> the archive PPA if it passes testing and used to create the golden
    >>> image. The next time a new 'foo' is attempted, it will have a higher
    >>> version, 20131201.2. If the testing for 'foo' fails, we need to delete
    >>> it so that when the build PPA is reused, the failed version of 'foo'
    >>> never gets integrated into a golden image. If the build PPA were not
    >>> cleaned, the 20131201.2 version would be selected instead of the
    >>> correct one in the archive PPA.
    >>> 
    >> 
    >> Since PPA cleaning seems to be a long non-deterministic thing, does it
    >> makes sense to try and clean the PPA when its returned back to the pool?
    >> This would allow the call to ppa.reserve to be synchronous. The place I see
    >> this simplification being suboptimal is if we have are low on unreserved
    >> PPA's and most of our users don't care if the PPA is clean or not.
    >> 

    > Are we allowing users to choose their own PPAs so this would be an issue?

Well, if they want to chose their own PPAs, that's not the PPA assigner
responsibility anymore IMHO.

I still think that pool is working around a launchpad limitation, so
let's keep this component as simple as possible.

    > I was assuming the PPA assigner would be the one in charge to
    > ensure PPAs are clean before returning to the pool.

Agreed.

That seems to be the most intuitive.

     Vincent