On 07/07/2016 12:26 PM, Christian Schwede wrote: > On 07.07.16 12:55, Fabien Boucher wrote: >>> Today, the story suggests to use mirror2swift[2], but I'm afraid this >>> tool doesn't address the repodata creation, it only mirrors >>> the rpm packages when available (and it doesn't work with elasticsearch >>> http mirror where rpm files are not web listed). > > Yes, creating repodata was never planned for this tool - it should > simply mirror an existing public repo on Swift. > Well, that's why I started this thread, we need repodata in the cache so that yum can use it :)
>> Does it deserves an improvement of that tool then ? >> repodata should be browsable so I think the tool could fetch them ? > > That's what the tool is doing right now; but I think what Tristan meant > is to actually take some rpms and create a missing repodata from them. > >> Also could we add an option to specify directly the link to >> the RPMs in the config file and by exception not rely on >> the list ? > > I didn't test that yet, but I think it already supports that because one > can define multiple repos - and if one just points to a single rpm, that > should be fine. If not, it should be fixed. > It seems like we should avoid, as much as possible, micro-managing rpm versions, so I wouldn't recommend that use case in SF. >> That's just ideas I haven't look into the details. >> >>> Moreover we also discussed about using spacewalk[3] which seems a >>> complete solution to manage our ci instances need. >> >> My feeling is that we should let a SF operator setup and run by >> himself this kind of tool. I don't see s strong need to integrate >> that in SF. Furthermore I'm concern about the difficulty to integrate >> it tightly (in term of configuration). > > Same for me. Spacewalk is great if you already have it, but if you > explicitly need it (or integrate it in SF) it becomes another burden to > start using SF. Every another dependency to run SF will lower the > adoption of SF IMO. > I agree, this is listed here for completeness. >>> Thus I wonder what to do now... From my understanding we need to rely on >>> yum utils to properly download a repository locally, and then use >>> createrepo to produces the required repodata. I'd like to finish the >>> original proposal and adds the missing swift publication code. > > Sounds good to me; anyways looking at the existing patch it seems to be > one step before having a local mirror? > >> So mirror2swift needs to be improve to handle that ? right ? >> Should we refine the story ? > > Could we use mirror2swift to actually upload the data created by > Tristans patch? Or just using the swift CLI? > > -- Christian > Based on this morning discussion, it seems like improving mirror2swift to support repodata fetching is a good middle ground solution. I went ahead and implemented[0] the missing bits so that we can benefit from both efforts: * the sf-mirror role takes care of config repo and calling mirror2swift * mirror2swift do the heavy lifting of fetching all rpms, including repodata, and push them to a swift container. If that works for you guys, I'll update my review. Cheers, -Tristan [0]: https://github.com/cschwede/mirror2swift/pull/1
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
