aeolus-devel July 2012

aeolus-devel@lists.fedorahosted.org

49 participants
179 discussions

presenting Aeolus at the OLF
by Mo Morsi 20 Sep '12

20 Sep '12

I just was offered a slot to present Aeolus at The Ohio LinuxFest [1]. The OLF is one of the biggest community-run Linux conferences in the States so it'll be a great opportunity to share / promote the project to a wide / diverse audience. The conference is at the end of September, so besides my usual security and other work up to then, I'm going to be taking some time to throw together and send around a quality presentation for the event. I would like to heavily lean on a demo, using the wui and cli tools to deploy to the cloud using a hosted instance of Aeolus (even if that is non-public at the time being). I'd like to skip over the configure / setup stuff and just demonstrate the meat and bones of using the application to deploy to the cloud. Any thoughts, comments, presentation material, etc would be appreciated, -Mo [1] http://ohiolinux.org/

3 10

[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] RM#3508 - Ensure that all sessions expire, that DB session objects are cleaned up correctly and that auto-refresh in the UI doesn't keep renewing sessions.
by Tomas Hrcka 15 Aug '12

15 Aug '12

--- src/config/initializers/session_store.rb | 2 +- src/public/javascripts/application.js | 7 +++++- src/spec/requests/sessions_spec.rb | 37 ++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+), 2 deletions(-) create mode 100644 src/spec/requests/sessions_spec.rb diff --git a/src/config/initializers/session_store.rb b/src/config/initializers/session_store.rb index 8ff62fa..5fd69a1 100644 --- a/src/config/initializers/session_store.rb +++ b/src/config/initializers/session_store.rb @@ -28,4 +28,4 @@ Conductor::Application.config.session = { # Use the database for sessions instead of the cookie-based default, # which shouldn't be used to store highly confidential information # (create the session table with "rake db:sessions:create") -Conductor::Application.config.session_store :active_record_store +Conductor::Application.config.session_store :active_record_store, :expire_after => 15.minutes diff --git a/src/public/javascripts/application.js b/src/public/javascripts/application.js index 2162880..fa842b2 100644 --- a/src/public/javascripts/application.js +++ b/src/public/javascripts/application.js @@ -25,7 +25,12 @@ $.extend(Conductor, { $('#tab').html(data).show(); }) .error(function(data) { - $('#tab').html(data.responseText).show(); + // If our session has timed out, redirect to the login page: + if(data.status == 401) { + window.location = Conductor.PATH_PREFIX + "login"; + } else { + $('#tab').html(data.responseText).show(); + } }); Conductor.tabRemoveActiveClass(); diff --git a/src/spec/requests/sessions_spec.rb b/src/spec/requests/sessions_spec.rb new file mode 100644 index 0000000..4bd4611 --- /dev/null +++ b/src/spec/requests/sessions_spec.rb @@ -0,0 +1,37 @@ +require 'spec_helper' + +describe "Sessions" do + describe "User not logged in" do + + it "should not be authenticated" do + get pools_path + response.status.should be(302) + end + end + + describe "User logged in" do + before do + @user = FactoryGirl.create :tuser + end + + it "should be authenticated" do + + visit root_path + fill_in "Username", :with => @user.login + fill_in "password-input", :with => "secret" + click_button "Login" + page.status_code.should be(200) + end + + it "should have expired session" do + visit root_path + fill_in "Username", :with => @user.login + fill_in "password-input", :with => "secret" + click_button "Login" + visit pools_path + Timecop.travel(Time.now+16.minutes) + visit pools_path + page.body.should include "#login" + end + end +end -- 1.7.10.4

3 14

aeolus security - round 4 (rev 1)
by Mo Morsi 08 Aug '12

08 Aug '12

The same patchset as from last week plus a few additional fixes and the additional patch taking care of rm #3452

2 8

[PATCH conductor] BZ 843079 - set deployment's state to stopped when all instances are stopped
by Jan Provazník 08 Aug '12

08 Aug '12

From: Jan Provaznik <jprovazn(a)redhat.com> --- src/app/models/deployment.rb | 8 +++++- src/spec/models/deployment_spec.rb | 55 ++++++++++++++++++++++++++++++------ 2 files changed, 53 insertions(+), 10 deletions(-) diff --git a/src/app/models/deployment.rb b/src/app/models/deployment.rb index 277f9b3..fa8605f 100644 --- a/src/app/models/deployment.rb +++ b/src/app/models/deployment.rb @@ -660,13 +660,19 @@ class Deployment < ActiveRecord::Base def state_transition_from_running(instance) if instance.state != STATE_RUNNING - self.state = STATE_INCOMPLETE + if instances.all? {|i| i.state == Instance::STATE_STOPPED} + self.state = STATE_STOPPED + else + self.state = STATE_INCOMPLETE + end end end def state_transition_from_incomplete(instance) if instances.all? {|i| i.state == Instance::STATE_RUNNING} self.state = STATE_RUNNING + elsif instances.all? {|i| i.state == Instance::STATE_STOPPED} + self.state = STATE_STOPPED end end diff --git a/src/spec/models/deployment_spec.rb b/src/spec/models/deployment_spec.rb index 9b2a37e..8627169 100644 --- a/src/spec/models/deployment_spec.rb +++ b/src/spec/models/deployment_spec.rb @@ -376,17 +376,45 @@ describe Deployment do before :each do @deployment.state = Deployment::STATE_RUNNING @deployment.save! - @inst1 = Factory.create(:instance, :deployment => @deployment, :state => Instance::STATE_RUNNING) - @inst2 = Factory.create(:instance, :deployment => @deployment, :state => Instance::STATE_RUNNING) - @deployment.instances << @inst1 - @deployment.instances << @inst2 end - it "should be incomplete if only some instances are running" do - @inst1.state = Instance::STATE_ERROR - @inst1.save! - @deployment.reload - @deployment.state.should == Deployment::STATE_INCOMPLETE + describe "multi-instance deployment" do + before :each do + @inst1 = Factory.create(:instance, :deployment => @deployment, :state => Instance::STATE_RUNNING) + @inst2 = Factory.create(:instance, :deployment => @deployment, :state => Instance::STATE_RUNNING) + @deployment.instances << @inst1 + @deployment.instances << @inst2 + end + + it "should be incomplete if only some instances are running" do + @inst1.state = Instance::STATE_ERROR + @inst1.save! + @deployment.reload + @deployment.state.should == Deployment::STATE_INCOMPLETE + end + + it "should be stopped if all instances are stopped" do + @inst1.state = Instance::STATE_STOPPED + @inst1.save! + @inst2.state = Instance::STATE_STOPPED + @inst2.save! + @deployment.reload + @deployment.state.should == Deployment::STATE_STOPPED + end + end + + describe "single-instance deployment" do + before :each do + @inst1 = Factory.create(:instance, :deployment => @deployment, :state => Instance::STATE_RUNNING) + @deployment.instances << @inst1 + end + + it "should be stopped if all instances are stopped" do + @inst1.state = Instance::STATE_STOPPED + @inst1.save! + @deployment.reload + @deployment.state.should == Deployment::STATE_STOPPED + end end end @@ -544,6 +572,15 @@ describe Deployment do @deployment.reload @deployment.state.should == Deployment::STATE_RUNNING end + + it "should be stopped if all instances are stopped" do + @inst1.state = Instance::STATE_STOPPED + @inst1.save! + @inst2.state = Instance::STATE_STOPPED + @inst2.save! + @deployment.reload + @deployment.state.should == Deployment::STATE_STOPPED + end end end -- 1.7.10.4

2 1

[PATCH configure 0/1] Use conductor api for provider creation
by John Eckersberg 07 Aug '12

07 Aug '12

Make sure if testing this that you are testing against conductor from master. The versions currently present in f17 updates/updates-testing are missing some functionality of the providers api; specifically, creating a new provider will redirect to the provider html view. The version in master will return a 200, with the xml body containing the newly created provider. Configure validates this response body, so the old version will not work.

2 2

RFC: Sprint summary emails
by Matt Wagner 07 Aug '12

07 Aug '12

Hi folks, As I return from PTO and try to catch up, I wanted to propose an idea. I think it'd be swell if, at the beginning of each sprint, we sent out an email outlining what we hope to accomplish, with a little blurb on each story, a quick estimate, and who (if anyone yet) is taking it. It could also spell out the start and end dates, as well as any other notable dates (code freeze, etc.) It would help people like me get up to speed more quickly, but much more importantly, I think it would be interesting to people monitoring Aeolus development but not necessarily participating full-time. Picking a random example from the backlog that I'm semi-familiar with, we have #3499, which reads "As a user, I want a consistent, coherent UI" with no further explanation. There's been other discussion of this, so I happen to know what it means, but it's ultra-vague as published in Redmine. It seems like it would be quite helpful if it got a blurb in a beginning-of-sprint email like: -------%<---------- #3499 - As a user, I want a consistent, coherent UI We've been gathering a list of UI annoyances on the wiki: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/List_of_UI_Annoy… For this story, we plan to review that list and identify the "quick fixes" that don't require much discussion/consideration, and then implement them. This should make the Aeolus user experience much more satisfying. Jiri has volunteered to lead this; it is estimated at 13 points. -------%<---------- Admittedly, writing this up for each story is a decent bit of work. However, it's really nothing but a quick summary of what we discuss on sprint planning calls. I think this would have two benefits: 1.) It would be very useful as far as making it clear what we are doing, especially to outsiders. (It would have an incidental benefit for people like me, that miss a sprint planning call, but that's not the primary goal.) 2.) It would force us start to write decent descriptions for our tasks. If people agree that this is useful, I'd be happy to take a stab at writing it up next sprint during/after the planning call. What do you think? And should Conductor/Infra emails be separate, or combined? -- Matt

6 10

[PATCH conductor] RM 3396: Complex provider selection algorithms
by Imre Farkas 03 Aug '12

03 Aug '12

This patchset implements the initial framework

5 32

[PATCH conductor] Conductor extended with hwp functionality
by Samridh 02 Aug '12

02 Aug '12

This revised patchset adds Rspec tests for the templates (very basic). The mapping from /api/hardware_profiles to /hardware_profiles is temporary. It is needed to test the cli functionality. It can be removed later

2 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel July 2012