aeolus-devel June 2012

aeolus-devel@lists.fedorahosted.org

48 participants
119 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

ACA Side Topic - Proposal: templates.aeolusproject.org
by Dan Macpherson 22 Aug '12

22 Aug '12

Hi guys, I've been following the Aeolus Community Assessment conversation and I though I might start a separate e-mail chain regarding an idea I had instead of railroading the original conversation. >From what I saw of the original conversation, we're looking to build our community and evangelize Aeolus' strengths. It's also been questioned as whether we'd recommend using Aeolus in it's current state in a production environment. This got me thinking... there's a difference between what we'd recommend to users, and what they'll actually do. By this, I mean that there might be a boffin or two somewhere who could devise some unique uses for Aeolus that we've never even thought of. And I think that what some might consider Aeolus's biggest weakness (it's still experimental) could end up being its biggest strength (experimental is fun and exciting!). My proposal ----------- We develop our own (for lack of a better word) "Apps Store" -- a place when users can share Image and Deployable templates for Aeolus, much along the same lines as addons.mozilla.org or extensions.gnome.org. And following these subdomain conventions, I suggest... templates.aeolusproject.org! How it works ------------ A user writes an image template and deployable for a particular application. For example, they might want to launch a base Drupal installation in EC2 using Fedora as an OS. So they write an Image Template that includes the relevant Apache and Postgres packages. They also write a Deployable Template that installs and configures Drupal (via Audrey) to an instance with httpd/db. Then the user thinks, "Hey, I bet there are others out there who want to install Drupal in the cloud. Maybe I should share these templates with the world." The user uploads the templates to templates.aeolusproject.org, tags them as an Image Template and Deployable Template respectively, and create an associates between the two (basically a way of signifying a relationship between an image/deployable pair that works well together). So then, I want to create a Drupal site on a standalone instance in my own RHEV environment. I search templates.aeolusproject.org and find someone has already created the templates I need. Perfect. (Plus I could substitute the Image template for one with a different distro if I prefer). I use both these template in Aeolus and install Drupal on EC2. It works great! I go back to templates.aeolusproject.org and give the template author a 5-star rating. Great job, everything went better than expected. Plus, the rating helps his Deployable Template becomes TOTM (Template of the Month). But I also leave a comment to say, "Hey, great templates, but I think you should include a param in the deployable that allows a user to input a comma-separated list of additional modules for their Drupal installation." This way I'm helping improve the content of templates.aeolusproject.org through feedback. Benefits -------- templates.aeolusproject.org does a couple of cool things: 1. Encourages people to join, contribute and collaborate to the Aeolus community 2. Encourages people to experiment with Aeolus and share their results 3. Helps new users wanting to learn more about TDL/Deployable XML 4. Provides users with a library of applications to launch into their cloud (and only needing two XML files to do so) 5. Gives us a better idea of how people are using Aeolus so that we can enhance the features they like and improve the features they don't like These are very rough ideas that I've come up with in a day, so please forgive me if they seem a little ill-thought. Regardless, I do think is an idea that can really enhance the Aeolus Community and the project too. If anyone has an ideas, suggestions, drawbacks or general comments, please share them. Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia e: dmacpher(a)redhat.com

13 25

[PATCH conductor] Fix aeolus user home directory on upgrade
by John Eckersberg 11 Jul '12

11 Jul '12

Previously the aeolus user's home directory was set to /var/aeolus. This was changed to /usr/share/aeolus-conductor in commit 923f894. However this only catches new installations; if the aeolus user previously existed (e.g. upgrade) then the home directory would not be updated. This catches that case and ensures that old installations using the old home directory are updated. --- aeolus-conductor.spec.in | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/aeolus-conductor.spec.in b/aeolus-conductor.spec.in index 6186651..15ace33 100644 --- a/aeolus-conductor.spec.in +++ b/aeolus-conductor.spec.in @@ -164,6 +164,10 @@ getent passwd aeolus >/dev/null || \ /usr/sbin/useradd -u 180 -g aeolus -c "aeolus" \ -s /sbin/nologin -r -d /usr/share/aeolus-conductor aeolus 2> /dev/null || : +# Previously ~aeolus was set to /var/aeolus +# If this is an upgrade scenario, fix the home directory +test ~aeolus == /usr/share/aeolus-conductor || usermod --home /usr/share/aeolus-conductor aeolus + %install %{__mkdir} -p %{buildroot} %{__mkdir} -p %{buildroot}%{app_root} -- 1.7.10.2

4 5

[PATCH 0/1 Conductor] Decoupling specs from deltacloud
by Jason Guiditta 02 Jul '12

02 Jul '12

This patch is intended to fix only the case listed in $subject, specifically in the non-bundler setup (though it should certainly cause far fewer fails with no services running under bundler as well). Note that I had to make somewhat of a temprary fix due to time constraints, which is noted as such in the spec_helper. If you run specs from system gems before this patch, and turns off the deltacloud service, you wil get in the vicinity of 180-some-odd failures. After the patch you should get 0. I plan to keep poking at this next week, but that will miss code freeze. My plan is to try to sneak in fixes for the 3 or so remaining fails that are caused when iwhd is not running, and to see why controllers fail without the above-mentioned temporary fix in spec_helper. I noticed a couple major issues that need some though (and hopefully will at least partly be covered by upcoming arch improvements, pending list discussion): * Our code is _really_ intertwined in a number of areas. This makes for a tough row to hoe with some of the tests. When a developer has to dig through 4-6 different models to figure out what needs to be stubbed to get a single model's tests passing, that is a _bad thing(tm)_. We need better encapsulation of our code. * A number of our controller tests are actually testing the model behavior, which is flat out wrong. Test models in model specs. Controller specs should _only_ be testing against mock_models and verifying things like 'method called', variable set, etc. Otherwise you are testing business logic in the wrong place. -j

2 2

[PATCH aeolus-cli] aeolus-cli extended with hwp functionality
by Samridh 02 Jul '12

02 Jul '12

This patch adds hwp creation, deletion and listing functionality to the cli. To test the functionality, please modify the :url entry in your ~/.aeolus-cli file to something like ":url: http://<host>/conductor" i.e, remove the /api from the :url entry. This is because all the conductor side funcitonality has been implemented by modifying the hardware_profile cotroller itself. You could also modify the routes.rb on the conductor side, but I personally found the former easier to do.

3 7

[PATCH 0/1 conductor] BZ803106 add pagination to images list on pool_families show page
by Tzu-Mainn Chen 29 Jun '12

29 Jun '12

This patch adds missing pagination to the images list on pool_families show Mainn

1 1

[Failed] aeolusproject/conductor#7 (aeolus-conductor-0.8.32-1 - 8ad6461)
by Travis CI 29 Jun '12

29 Jun '12

Build Update for aeolusproject/conductor ------------------------------------- Build: #7 Status: Failed Duration: 23 seconds Commit: 8ad6461 (aeolus-conductor-0.8.32-1) Author: Tzu-Mainn Chen Message: Automatic commit of package [aeolus-conductor] release [0.8.32-1]. View the changeset: https://github.com/aeolusproject/conductor/compare/1dcd95ee2952^...8ad6461a… View the full build log and details: http://travis-ci.org/aeolusproject/conductor/builds/1738967 -- You can configure recipients for build notifications in your .travis.yml file. See http://bit.ly/lCybCJ The delivery of this notification was kindly sponsored by Postmark. Send transactional email confidently using http://postmarkapp.com

1 0

[Failed] aeolusproject/conductor#6 (aeolus-conductor-0.8.33-1 - 9a2e314)
by Travis CI 29 Jun '12

29 Jun '12

Build Update for aeolusproject/conductor ------------------------------------- Build: #6 Status: Failed Duration: 18 seconds Commit: 9a2e314 (aeolus-conductor-0.8.33-1) Author: Steve Linabery Message: Automatic commit of package [aeolus-conductor] release [0.8.33-1]. View the changeset: https://github.com/aeolusproject/conductor/compare/1dcd95ee2952^...9a2e314f… View the full build log and details: http://travis-ci.org/aeolusproject/conductor/builds/1738965 -- You can configure recipients for build notifications in your .travis.yml file. See http://bit.ly/lCybCJ The delivery of this notification was kindly sponsored by Postmark. Send transactional email confidently using http://postmarkapp.com

1 0

[Failed] aeolusproject/conductor#5 (0.10.x - 68e19f8)
by Travis CI 29 Jun '12

29 Jun '12

Build Update for aeolusproject/conductor ------------------------------------- Build: #5 Status: Failed Duration: 46 seconds Commit: 68e19f8 (0.10.x) Author: Steve Linabery Message: Bump version, add changelog 0.10.5-1 View the changeset: https://github.com/aeolusproject/conductor/compare/b464bfb31f9b...68e19f84d… View the full build log and details: http://travis-ci.org/aeolusproject/conductor/builds/1738958 -- You can configure recipients for build notifications in your .travis.yml file. See http://bit.ly/lCybCJ The delivery of this notification was kindly sponsored by Postmark. Send transactional email confidently using http://postmarkapp.com

1 0

Thoughts on migrating www to pages.github
by Francesco Vollero 29 Jun '12

29 Jun '12

Hello list, I am documentating and research about the opportunity in $subj to migrate our static website from nanoc + few accounts able to access our www machine to the opportunity to have it hosted on github pages. Mainly the idea to suggest this method is because the current solution is: * Complex (deal with haml and nanoc) * Not everyone in the team can update the page (lack of permissions) * Usually is time wasting to update it (nanoc time + fix time + ɛ * rand() ) ( ɛ = epsilon) I did a small list of pro and cons about this migration: Pros: * Far more easy deploy phase * Reducing delays for website updates. * _Everyone_ within the team in github can update those pages. * Easy and _straightforward_ MarkDown syntax without tab/spaces weirdness Cons: * Migrate haml to md+liquid (isn't really complex) * Change a bit the layout + styling (e.g. [1,2]) Please let me know your thoughts about it, Cheers, Francesco Vollero

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel June 2012