P2P Packaging/Koji Cloud

Mo Morsi mmorsi at redhat.com
Wed Dec 7 18:57:51 UTC 2011


On 12/07/2011 01:40 PM, seth vidal wrote:
> On Wed, 07 Dec 2011 13:35:03 -0500
> Mo Morsi<mmorsi at redhat.com>  wrote:
>
>> On 12/07/2011 01:25 PM, seth vidal wrote:
>>   >
>>   >>
>>   >>  That would be very cool. Do you intend to use DeltaCloud (
>>   >>  http://deltacloud.apache.org/), or something like that?
>>   >  I'm using libcloud, actually. I'm interested in pursuing this in
>>   >  python, not ruby.
>>   >
>>
>>
>> Deltacloud's primary interface is REST based so you can use it from
>> any language. Additionally there are python specific bindings to the
>> REST interface that are pretty simple to use.
>>
>> https://github.com/mifo/deltacloud-python
>>
> The infrastructure to deal with deltacloud is much higher than just
> using libcloud. Having to have a daemon running just to do
> communication is, imo, not acceptable for something being spawned off
> like this. deltacloudd makes deltacloud a non-starter for me.

Yes this is being worked on. It'll be soon possible to run deltacloud 
like any other library, in process. Plus with the added benefit that 
you're using a project whose developers are highly involved with the 
Fedora community.


>> In any case, another nifty idea would be to use Snap to take
>> snapshots of the build environments on the cloud for local
>> replication on different Koji systems and/or local vms:
>>
>> https://github.com/movitto/snap
>>
> sapping them is going to involve a lot of bandwidth which costs money.
> Since we have a mirror inside the amazon ec2 network space snapping is
> likely to be MORE expensive than just installing from there.
>
> -sv

Not really, the snapshots are extremely optimized. Only the package list 
is saved plus any files modified outside of the package system. Plus you 
can restrict what exactly is backed up, only backing up your build root 
for example.

   -Mo




More information about the devel mailing list