incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: [RFC] CloudStack Architectural Refactor
Date Thu, 09 Aug 2012 15:37:13 GMT
On 08/09/2012 07:04 AM, John Kinsella wrote:
> I think this is a great conversation to have, but maybe we should wait until after the
4.0 release? Seems like it might be a bit of a distraction right now…
>

I have to agree on this. I'm not against this, but for me imho it's 
rather hard to keep up with everything and the upcoming 4.0 release.

Great ideas and great plans, but we might better move this to the second 
half of September?

Wido

> On Aug 8, 2012, at 9:38 PM, Alex Huang wrote:
>
>> CloudStack 3.x has quite a bit of baggage after years of development.  This makes
it difficult for new committers to join the project.  Even for existing committers, it is
easy to make mistakes.  We're looking to make some fundamental changes to CloudStack to overcome
these problems.  Please feel free to comment.
>>
>> Problems:
>>   - No clear separation between orchestration and the subsystems being orchestrated.
 We've done a lot of work in this area in networking.  However, storage and hypervisor  are
still missing.
>>   - No clear separation between orchestration and the ACL system.
>>   - No clear separation between orchestration and the extra services (read SSVM,
console proxy VM)
>>   - CloudStack believes it is the master of all physical resources when it is not.
>>
>> Goals:
>>   - Form a core orchestration engine that is free of unnecessary artifacts such as
ACL.
>>   - Clear definition of functionalities and how to contribute to different parts
of CloudStack.
>>   - Allow developers to write and deploy services on the CloudStack orchestration
server.
>>
>> Design:
>> CloudStack will be refactor into the following functional areas.  Details to follow
after the design.
>> Orchestration Platform will include the following:
>>   - Orchestration Framework:  Orchestration engine is key in cloud infrastructure.
>>   - Subsystem Plugins: Actual implementations in network, hypervisor, and storage
of the orchestration steps.
>>   - Services Framework: A framework for others developers to build additional services
that can be launched using the Orchestration Service.
>>   - Events Framework: Allow third-party components to integrate with Orchestration
Platform through events only.
>>
>> On top of the Orchestration Platform, CloudStack will come with the following Services
which can be enabled/disabled without affecting CloudStack orchestration functionalities.
 Each of these services can be deployed on bare metal, VM, or as a webapp.
>>   - ACL Service to provide advance ACL control to other services launched
>>   - End User API Service to provide orchestration of end user VMs
>>   - ConsoleProxy Service to provide console access
>>   - Template Service to provide template/ISO transport and access within a zone
>>   - Router Service to provide routing services to end user VMs
>>   - Object Store Service to provide object store functionality
>>   - EC2 API Service
>>
>> Details:
>> Orchestration Platform
>>   - Continues to manage hardware resources
>>   - Provide administrative API/UI
>>   - Minimal ACL provided
>>   - Provides a Services Directory for services to find each other
>>   - Includes the following components
>>
>> Orchestration Framework
>>   - Orchestrates VMs, Volumes, Templates, Networks operations within a data center
>>   - Ensures the operations are idempotent
>>   - Deals with hiccups and maintenances needs of the system administrator so that
services built on top do not have to.
>>   - Breaks down cloud operations into steps and pushes the steps to the subsystems
to be perform but does not actually perform the steps.
>>
>> Subsystem Plugins:
>>   - Plugins that knows how to perform different functionalities that the orchestration
framework needs.
>>   - Current Subsystem Planned: Deployment Planning, NetworkGuru, NetworkElement,
Storage, Snapshot, Backup (see Edison's RFC)
>>
>> Services Framework:  (RFC upcoming)
>>   - Leverages the current system VM to allow more services to be built.
>>
>> Events Framework: (RFC upcoming)
>>   - Publishes all Orchestration platform entity changes as events.
>>   - Allow other components outside of Orchestration Platform to interact with Orchestration
Platform only through event notifications.
>>
>> Design Thoughts:
>>   - In this design, end user API and end user VMs is one particular service provided.
 End User VM services can innovate independently from the Orchestration Platform.
>>   - Domains and Accounts will reside with the ACL service which can integrate with
Active Directory and LDAP services.
>>
>> --Alex
>>
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>


Mime
View raw message