[PATCH] distgit: Upload files to both the new and old path

Pierre-Yves Chibon pingou at pingoured.fr
Fri Jun 12 14:52:50 UTC 2015


On Fri, Jun 12, 2015 at 09:18:53AM -0500, Dennis Gilmore wrote:
> On Thursday, June 11, 2015 04:59:22 PM Mathieu Bridon wrote:
> > On Wed, 2015-06-10 at 10:33 -0500, Dennis Gilmore wrote:
> > > I think we should be linking to the old location and a sha512sum
> > > location not md5 but the general idea is okay
> > 
> > Doing the new location for md5 as well has a pretty big benefit though:
> > it means we can update fedpkg to make it download from the new location
> > independently from the move to sha512.
> > 
> > Decoupling the two makes for an easier migration:
> I strongly want a flag day for the migration. because there is other things 
> that need to be coupled with it. such as the changes to ca setup to use our ca 
> for logins but a well known ca for koji.fp.o I want to decouple thekoji hub 
> and web interface also, which will mean we need a new hostname for the hub.  
> all of these changes have a hard requirement of a flag day as end users will 
> need to make changes on the client side.
... 
> > All in all, that makes for a pretty smooth migration, with no flag day
> > or outage during which we'd need to cut uploads temporarily.
> This is not even close to the only reason for a flag day. we have to have one 
> and we had a plan to roll it all into one, please do not go changing that.

Reading your reply appears to have quite a negative tone to me, might be because
it's the end of the week or because I'm not a native speaker, but I feel some
negativity which I do not understand.

I'm not seeing how Mathieu's work allowing to not have a flag day is a problem.
We're speaking about one change here and that change does not require a flag
day. I mean we should all be happy about this: "cool, less work, more backward
compatibility, easier transition". I can only see benefits.
If other changes do require a flag day, so be it, but that's then unrelated to
the changes made here.

 
> >   $ fedpkg sources
> >   Downloading libcangjie-1.3.tar.xz
> >   ######################################################### 100.0%
> >   Download failed, falling back to the old URL
> >   Downloading libcangjie-1.3.tar.xz
> >   ######################################################### 100.0%
> > 
> > But for a source file uploaded **after** the changes to the upload.cgi
> > scrip, we'd get this:
> > 
> >   $ fedpkg sources
> >   Downloading libcangjie-1.3.tar.xz
> >   ######################################################### 100.0%
> > 
> > Which means at that point, the migration to the new path would be
> > pretty much done.
> > 
> > <optional step>
> > I have a script ready, to be run on the server, which will hardlink all
> > existing uploads from their old to their new path.
> 
> this is not optional. we have to link all the tarballs to the sha512 
> locations. 

Could you expand on why this is in fact a required step? fedpkg will be able to
handle both locations, right?


Thanks,
Pierre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20150612/6a45e3e6/attachment.sig>


More information about the infrastructure mailing list