P2P Packaging/Koji Cloud
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.
> 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
>> 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:
> 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.
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
More information about the devel