aeolus-devel March 2012

aeolus-devel@lists.fedorahosted.org

35 participants
174 discussions

[PATCH conductor] BZ 801527: wrong error message when imagefactory is down
by Maros Zatko 06 Sep '12

06 Sep '12

From: Maros Zatko <mzatko(a)redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=801527 API: * new API exception ServiceUnavailable * rescue for ECONNREFUSED when imagefactory is down --- src/app/controllers/api/images_controller.rb | 14 +++++++++----- src/lib/exceptions.rb | 1 + 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/src/app/controllers/api/images_controller.rb b/src/app/controllers/api/images_controller.rb index 465a20b..2bcbeee 100644 --- a/src/app/controllers/api/images_controller.rb +++ b/src/app/controllers/api/images_controller.rb @@ -89,11 +89,15 @@ module Api :template => @tpl.uuid, :environment => @pool_family.name }) - @image = Aeolus::Image::Factory::Image.new(:id => iwhd_image.id) - @image.targets = req[:params][:targets] - @image.template = req[:params][:template] - @image.save! - respond_with(@image) + begin + @image = Aeolus::Image::Factory::Image.new(:id => iwhd_image.id) + @image.targets = req[:params][:targets] + @image.template = req[:params][:template] + @image.save! + respond_with(@image) + rescue Errno::ECONNREFUSED + raise(Aeolus::Conductor::API::ServiceUnavailable.new(503, 'Imagefactory is dead, Jim!')) + end elsif req[:type] == :import account = ProviderAccount.find_by_label(req[:params][:provider_account_name]) raise(Aeolus::Conductor::API::ProviderAccountNotFound.new(404, t("api.error_messages.provider_account_not_found", diff --git a/src/lib/exceptions.rb b/src/lib/exceptions.rb index d56ddb3..9b1edab 100644 --- a/src/lib/exceptions.rb +++ b/src/lib/exceptions.rb @@ -38,6 +38,7 @@ module Aeolus class ProviderImageDeleteFailure < Error; end class ProviderImageNotFound < Error; end class ProviderImageStatusNotFound < Error; end + class ServiceUnavailable < Error; end class TargetImageDeleteFailure < Error; end class TargetImageNotFound < Error; end class TargetImageStatusNotFound < Error; end -- 1.7.7.6

2 2

[PATCH conductor 0/1] #787280 - Get rid of fake links
by Matt Wagner 30 May '12

30 May '12

To Whom It May Concern, Whilst I was using the application, I came to the realization that some of the links in the footer served no purpose. They went nowhere, and there wasn't even an apparent place that they *should* go. I entered https://bugzilla.redhat.com/show_bug.cgi?id=787280 and proceeded to remove the links and the associated entries in en.yml. I thank you for your kind consideration of this matter. Good day, Matt

3 8

[PATCH aeolus-configure] Apache handles web fonts properly
by Matt Wagner 04 May '12

04 May '12

Our Apache config was invalid for /fonts, though the problem wasn't apparent because the current UI doesn't use them. As we work towards a unified UI, we're using a web font and it wasn't showing in RPM builds due to the invalid reference. This fixes the Alias, tells Apache to not proxy those requests to Rails, and also sets Cache-Control headers on the fonts. I had to add a MIME type for *.woff manually to appease Apache. This is not associated with a BZ. There is no need to carry this in the existing product release; it's only useful going forward when we add web fonts.

3 4

RFC Feature Planning: Deployment Activity History
by Tzu-Mainn Chen 20 Apr '12

20 Apr '12

https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Allow_Conductor_… The document talks about two possible approaches to keeping deployment activity; one is to use an archive table, and another is to use a soft_delete flag. I'd be interested in hearing people's thoughts on both. Oh, and the document also talks about potentially using dbomatic for periodic history purges. I know there's been some discussion around dbomatic, so if someone had an opinion about that as well. . . Mainn

4 13

Aeolus GSoC
by Mo Morsi 16 Apr '12

16 Apr '12

Fedora was accepted as one of the Google Summer of Code (GSoC) projects and I submitted a proposal to extend Aeolus support on Fedora [1] a few weeks back. We've gotten some interest in the project, and I've been helping various students install and get antiquated w/ the framework so that they can submit proposals of their own to work on some aspect of the project. Here is one of those [2] that Samridh (cc'd, student attending P.E.S. institute of tech in Bangalore, India ) is working on, and I'm sending it around for comments and thoughts. Will reply to this thread with updates and more proposals as time goes on. If anyone wants to expand upon my proposal with more specific items to work on and/or co-mentor it with me just shout out and we can make the necessary arrangements. -Mo [1] http://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Bringing_the_Clo… [2] https://fedoraproject.org/wiki/GSOC_2012/Student_Application_Samridh90/Brin…

2 4

RFC Feature Planning: User Groups
by Scott Seago 12 Apr '12

12 Apr '12

Rather than paste in the entire text, I'm just linking to the wiki writeup. Please read the whole thing first and if you want to comment on anything specific, quote it and comment on this thread. https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_User_Grou… Scott

6 11

RFC Feature Planning: Add Permission Grant list to User Profile and UserGroup details
by Scott Seago 05 Apr '12

05 Apr '12

5 11

RFC Feature Planning: Permissions Denormalization
by Scott Seago 04 Apr '12

04 Apr '12

3 3

RFC feature planning - robust instance launching
by Jan Provazník 04 Apr '12

04 Apr '12

Hi, sending proposal for "robust instance launching" scenario. Any thoughts or improvement ideas are welcomed. Cut&paste from https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Robust_instance_… Summary This page describes multi-instances deployment launch process Owner Jan Provaznik (jprovazn(a)redhat.com) Current status Targeted release: Last update: When launching a deployment, deployment object is created and saved, Then ‘launch’ method is called on this deployment which creates required instances in conductor DB and associates them w/ the deployment object. Then it tries to find suitable ‘match’ (combination of hwp, provider account, realm) where all instances of this deployment can be launched. If a match is found, launch params are computed for all instances. Finally we iterate through all instances and try to launch them. If any instance launch fails, we set create_failed state on this instance and continue with next. All of above steps are not in transaction, IOW if match is not found or launch params upload fails or instance launch fails, deployment and instances stay created. There is not retry or fallback plan if an error occurs (for example the provider of chosen match is not accessible). Screencast Demo 1) Successful deployment launch All instances should be launched in proper order 2) Launch on first provider account fails, succeeds on second provider account Launch two deployment's instances, third instance fails to launch Launch on the first account should be rolled back -the two launched instances should be stopped launch should be done on the second account and should be successful 3) Launch fails on both providers Launch two deployment's instances, third instance fails to launch Launch on the first account should be rolled back - the two launched instances should be stopped Same for second account Deployment should be destroyed Log for this launch should be created in a log Implementation tasks Tasks which were already in Redmine cover whole deployment launch process, though may be broken into smaller tasks soon: #3060 - Refactor the launch process to include better error reporting, retries, switching to alternate providers etc. #3061 - Ensure that the UI doesn't contain unlaunched instances #3062 - Ensure that multi-instance deployments always launch fully or not at all. Conductor should automatically clean-up partial deployments Detailed description whole deployment launch process can be split into 3 phases: 1) pre-launch: we prepare deployment and instances objects (in conductor db), prepare launch params and compute dependencies between instances in this phase - if anything goes wrong, we just call rollback, nothing is saved and user stays on launch page 2)launch of non-blocked instances: send dc-api create instance request for each instance which is not blocked. This step is done on foreground together with phase 1 when a user presses "launch" button (note: it’s possible to do this call from dbomatic too, if we decide it’s better). 3)launch instances on state change: instances which have not been launched in phase 2. because they depend on instanceX are launched when instanceX is running. This can be done from instance after_update callback - when instance’s state is changed to ‘running’, get list of instances which becomes unblocked and launch them. Phase 3 will be usually executed on background, because instances states are usually updated by dbomatic (though not always - in some cases instance’s state is updated directly on dc-api request call). If an instance launch fails for some reason, we try to deploy somewhere else: stop all instances which have been already launched, then find another match (skipping all matches which failed), reset state to NEW for all instances (or drop and recreate them) launch progress page (TBD) Angus suggested that there could be something like “launch progress page” where details of what’s being done w/ deployment would be showed. So if the user checks “show me details” checkbox before clicking “launch” button, he is redirected to this progress page where info which step is being done is displayed: "Selecting provider account... account_name" “Making launch request for instance... x” This could be probably just displaying of all events associated with this deployment. Showing of this page would be optional, alternatively it could be part of deployment’s show page where a user could redirected after launch. High-level implementation details Add 'state' attribute to Deployment model, states can be: new - deployment is created in Conductor DB, but no instance has been launched yet pending - at least one instance launch has been requested failed - final state, deployment launch/shutdown failed rollback_in_progress - an error occurred during launching an instance and there are already some launched instances which have to be stopped rollback_failed - stopping of already launched instances failed rollback_complete - stopping of already launched instances, now the deployment can be launched somewhere else running - all instances were successfully are in running state shutting_down - sthutdown was initiated stopped - all instances are stopped Allowed state transitions: new -> pending pending -> running|rollback_in_progress|failed rollback_in_progress -> rollback_complete|rollback_failed rollback_complete -> pending|failed running -> shutting_down shutting_down -> stopped Deployment state will be used to track deployment's history and decide what to do on a change - for example if last deployment's instance is stopped, deployment relaunch is done only if deployment was in rollback_in_progress state, otherwise the deployment stays stopped. State will be also used in UI for displaying deployment's state - currently we use only 3 states: pending, running and failed and these are computed "per request" by checking state of all instances in deployment. deployment_launch: in transaction do create deployment create deployment’s instances compute instances dependencies (covered by task 3054) find match where all instances can be launched (covered by task 3064) invoke instances_launch on error: deployment and instances are not created in conductor’s db user stays on deployment launch page proper error with reason why launch was not successful is displayed instances_launch: for each deployment’s instance which is not blocked do check quota send dc api launch request on error: initiate deployment rollback instance’s after update callback: if instance is in running state then invoke instances_launch elsif instance is in failed state then invoke deployment_rollback deployment_rollback: if all instances are stopped/failed invoke deployment_relaunch else send stop request to any instances in pending or running state deployment_relaunch find new match where all instances can be launched (skipping matches which we tried before) if match is found, invoke instances_launch elsif match is not found, retry for all matches -> use first match which failed before if match is not found, create log about failed launch in some history log (covered scenario 3037) and destroy this deployment Instance launch timeout On deployment launch when an instance is in pending state for X minutes, the launch is terminated and deployment rollback is initiated. This timeout should be configurable, default timeout could be 15 minutes? Future plan The above is short/mid-term solution how to improve instance launching, it doesn't add any new dependency/tool. Long-term solution is to integrate Heat (https://github.com/heat-api), which is expected to do all things we need (take care of deps between instances, launch instances in proper order, rollback of failed launch, monitoring...). We don't care about dependencies between instances when stopping a deployment. References Links and other references related to the feature. Mails, IRC logs, documentation for libraries used, links to other parts of project documentation, etc.

8 18

Merge / split controller for UI and API?
by Petr Blaho 02 Apr '12

02 Apr '12

Hi all, I am now working on preparing API for Provider and ProviderAccount resources so I want to ask some questions regarding controllers for API. At this moment there are some controllers in API namespace and so there is duplicated functionality between UI and API parts. In the future we will be adding features to API and CLI tool too. I think that we need to decide wheter keep UI and API controllers separated or merge them together. I think that best will be to merge them together. Controller should be as skinny as possible with minimum logic (parameters sanitizing, model call, render results - view or whatever). Controller should respond to html, js, json, xml, etc... All the logic now present in controllers should be moved to models or some other classes which will work with models (delegators, decorators, name it...) Please, write your thoughts and/or experience with this kind of problem. -- With regards Petr Blaho

9 22

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel March 2012