On 24/10/11 at 09:04 +0200, Stefano Zacchiroli wrote: > For instance, given we're generalizing the code, it'd be nice to have it > not too much tied to Amazon-specific technologies. 60 full rebuilds are > quite a bit, but won't last forever and I'd oppose betting on the fact > that Amazon will be kind to Debian forever in the future. I bet that > targeting Amazon's API would make it possible to run the rebuilds also > on Eucalyptus private clouds, is that correct? Having a simple > indirection layer that enables to use other infrastructures > (e.g. OpenStack) would be lovely.
I agree, but I'm not too worried about that. AWS provides two things: - a IaaS cloud: provisioning of virtual machines (Amazon EC2) - additional services to ease application development: storage (S3), distributed nosql DB (SimpleDB), SQL DB (RDS), distributed cache (ElastiCache), queueing (SQS), etc. In that sense, it's in the middle between a IaaS cloud and a PaaS cloud. Free Software Cloud stacks such as Eucalyptus and OpenStack are usually restricted to replacing EC2 and S3. However, we have plenty of packages that could replace the other Amazon services. Sometimes they are even API-compatible with Amazon services: ElastiCache uses the same API as memcached. I agree that it would be a bad thing to design an infrastructure that relies deeply AWS services. But I think that it's fine to use them as long as it's not too hard to replace them by services provided by Debian packages. I know that this is also a compromise between efficiency of development and freeness of the resulting infrastructure. In the end, it should probably be a decision that is taken by the one writing the code. Lucas -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111024103523.ga8...@xanadu.blop.info
