Gents,
I've already sent this stuff around. Writing it up as an RFC: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Image_Management_...
In the next iteration 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_AP... andhttps://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactory_API_...
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 engine itself similar to a rails application which supplies all the controllers, views, routes and generators for creating image factory models. A prototype can be found here: git@github.com mailto:git@github.com:aeolus-incubator/image-management-engine.git
The prototype includes generators for creating the image management models, controllers and views for managing CRUD operations on the models and also the routes. Under the test folder is a dummy app that shows how this engine could be integrated with conductor. Showing a simple example on how to extend the engine models.
The testing structure should consist of integration tests as well as unit/behaviour. enginex (the tool that creates the skeleton engine - now included in rails >3.1) creates an integration set test environment using the dummy application. I suggest we stick to the testing structure already in place in the prototype. However, we should use RSpec as the testing framework for consistency.
We also have a feature page that outlines the expected behaviour here: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/V2_Conducot_API_I...
Regards
Martyn
Hi all,
We have a wiki page or two talking about using git, but one is fairly out of date (it, for example, warns that you shouldn't ever push to master). Another one was written by me some time ago, and needs some changing.
What I'd really like is to write up some super-clear documentation allowing those new to the project and/or git to get up to speed pretty quickly. I'd like to send some draft content here, based on my workflow. But I was hoping for feedback on it, both in terms of technical suggestions and advice on wording/ordering/etc.
For setup, I'd like to recycle some of the content from https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Git_Workflow (but without the erratic indentation that exists today).
For normal workflow, I think something like the following:
1.) Update master, with "git pull master".
2.) Check out a local topic branch for your work, with "git checkout -b my_new_feature"
3.) Do your work, commit your changes to your branch. (Maybe a section on "git add", "git commit" practices, etc.)
4.) With your changes committed on your branch, rebase against master to pull in any updates since you started -- "git rebase master" (I normally run "git checkout master; git pull" first)
5.) Format your patches, with "git format-patch HEAD..master" (or the 500 different ways you can express something equivalent). Send them to the list with git send-email.
6.) Do other work on other branches, perhaps, until you receive an ACK.
7.) Switch back to your branch (if needed), and rebase against master again.
8.) Switch to master, and run "git merge my_new_feature" to merge in your changes.
9.) Push with "git push"
I'd also like to have a section on*applying* patches from the list, but I'm not sure how other people do this. I create a topic branch from master, and then use mutt to pipe the message body to "git am -s". How do other people handle this?
-- Matt
I just want to jump in before this discussion gets too deep and let it be known that I'm currently writing up a proposal for some pretty drastic changes in our git/release workflow. I don't have anything to share yet; I want to make sure to thoroughly explain and justify why I think it should work this way. Hopefully tomorrow afternoon I'll have my first draft up.
Carry on
aeolus-devel@lists.fedorahosted.org