1. Messages
  2. fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Re: fdio/release repository on packagecloud now contains 19900 with some odd artifacts

Luca Muscariello
 

Andrew,

The implementation of (3) is indeed safe and can be done quickly and
does not require any additional decision to be made right now.

Short term, we'll work on (3). There may be some ci-management updates
to force packagecloud to keep the N latest packages only as a FIFO cache
on the currently active release. N can be as small as, say, 5.
For previous releases only one set of packages is kept in the repo.


We are going to do some ci-management updates in any case because we
are currently in the process of catching up with VPP 20.05 so this may
be the right moment.

Thanks
Luca


On Wed, May 6, 2020 at 3:28 PM Andrew đź‘˝ Yourtchenko <ayourtch@...> wrote:
Dear Luca,

My opinion hasn’t changed - it’s possibly a combination of the below two approaches:

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.

I would suggest starting with the step (3) and the safest option to implement is the two stage process:

- moving outdated hicn project artifacts from fdio/release to fdio/attic (to be created if exists)

- deleting the hicn artifacts from fdio/atticthat were added in the previous cleanup cycle or before that.

This approach in itself is implementable in two phases, and the first phase (release=>attic) is reversible, should any glitch arise and should any unnecessary packages be archived.

Since that work will be useful to verify even after the testing, and since from experience we know we can go to bit higher quantify of packages before the wheels fall off, I would also suggest that you can use the current state of fdio/release repo as a verification that the implementation of step (3) works correctly.

We can then revisit the situation and assess whether the step (4) is even needed, or if (3) is good enough.

What do you think ?

--a

On 6 May 2020, at 14:45, Luca Muscariello <muscariello@...> wrote:

3 - we have no need to keep all these artifacts. So we could just keep the latest 
artifacts for each hicn release for archival reasons only. We do not backport anything 
in previous releases nor we support our user base with older releases. Packagecloud has a 
REST API to manage that well.

4 - as an alternative we could create an independent repo for the hicn project. Still we'd 
like to delete obsolete artifacts ad in option 3.
Join tsc@lists.fd.io to automatically receive all group messages.