-
Notifications
You must be signed in to change notification settings - Fork 0
Image_Management_Engine
Rails Engine for management of cloud images
Martyn Taylor
- Targeted release: 1.2
- Last update: n\a
[[V2ConductorAPIImageManagement]]
Image Factory aim to make significant improvements and changes to its underlying model and its API. These changes will remove any conductor specific content from image factory altogether. See: https://www.aeolusproject.org/redmine/projects/image-factory/wiki/V2_REST_API and https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactory_API__Conductor_Work
In order to allow conductor API implementation and new imagefactory API integration to work in parallel we will we can implement image management functionality as a rails engine: http://guides.rubyonrails.org/engines.html
Using an engine for the integration gives us other benefits such as a standalone UI for factory and also a pluggable engine that can be used in other rails applications. It keeps a loose coupling between conductor and factory. Which means there should be minimal disruption to conductor on major releases of factory and the image management back end service (factory) could be swapped in/out if we ever needed to do it.
The effort will involve implementing the features outlined in the Conductor API Image Management page. We shall treat the dummy application that is used for integrated testing as a mock of conductor. This means that all the extra model information and relationships, needed by conductor shall be added to the dummy application. This serves as an example of how to integrate with the engine also. Doing it in this way should mean that integration with conductor takes minimal effort and that we meet all requirements from conductor.
We will be waiting on factory API implementation. Therefore all factory API interaction will be initially mocked, this also serves as a good testing module and will allow development to continue in parrallel with imagefactory as well as conductor. We will use the cucumber features as the requirements from conductor, and also use RSpec for unit testing.
Initial implementation will focus on a skeleton application that mocks factory and offers simple CRUD operations on resources. If at this point we are able to start integration with imagefactory API then we can do so. Otherwise we shall spend some effort on making the the engine work better standalone (such as adding more usable controllers/views/styling) as well as creating better generators for models and tests (to be used in the host application). At any point during the last phase we can stop improvements to integrate with factory. Since we have factory API deffinition up front and given we do a good job of mocking it. This should just be a case of swapping the mock module with active ActiveResource models.
[[IMEConductorIntegration]]
[[ImagefactoryAPI**ConductorWork]]
[[V2RESTAPI]]
http://guides.rubyonrails.org/engines.html