aeolus-devel July 2011

aeolus-devel@lists.fedorahosted.org

47 participants
216 discussions

Rails 3 update in your future
by Chris Lalancette 25 Jul '11

25 Jul '11

All, A group of us are working on updating the conductor codebase. Not only will this move us onto the new hotness of Rails 3, it will also make it so that we can get Aeolus into Fedora. What does this mean for you? Since Rails 2 and Rails 3 are incompatible, it means that we are going to have to have a "flag day" where we push the Rails 3 code to master, and everyone will have to switch over. Now that we have branched off for 0.3.0, we can do this at any time. Note, however, that the only place we have the RPM dependency situation completely (or mostly) sorted is in Fedora rawhide. Fedora 14, Fedora 15, and RHEL-6 have not yet been evaluated for packages. My suggestion is to merge the rails 3 code into master sooner rather than later. That way, we can get the whole team to help in flushing out the Rails 3 bugs, and it will go much faster that way. What do people think about this approach? In the very short-term it may stall development as we get it back up and running, but I think it will lead to a much shorter recovery time. -- Chris Lalancette

4 7

FOSSCON presentation
by Mo Morsi 25 Jul '11

25 Jul '11

Attached is my presentation on Aeolus that I gave at FOSSCON. I thought the talk went really well (even though it was over a 100 degrees in the room! 0_o) and hopefully I drummed up more interest in the project! -Mo

1 0

[PATCH conductor/rails3] Fix viewstate for Rails3
by Tomas Sedovic 25 Jul '11

25 Jul '11

This patch is supposed to go on the `rails3` branch.

1 1

Release 0.4.0 planning
by Hugh O. Brock 24 Jul '11

24 Jul '11

Hello all. With release 0.3.0 about ready to ship it seems like a good time to start talking about features we'd like to see for 0.4.0. I'd like to continue the three-month release cycle we've been on, so that puts our next one around mid-October. Below are some obvious buckets, please feel free to suggest additional features large or small. Finally, note I'm not making any claim that the list below is achievable in the timeframe we're talking about (although I would hope it's not that far from what is achievable). I'm more thinking in terms of what would make our 0.4.0 release seem like a coherent whole, and make the largest number of upstream users interested and happy. I'll start with Conductor features: * Authorization. We have a fair amount of authorization checking in place, but no way to actually set who can do what. Given that a central Conductor feature is the ability to control access to cloud resources, this seems like an important feature. Things we'll need to put this in place: * UX around setting permissions * UX around displaying appropriate "You can't do that" messages where required, or showing/hiding controls as appropriate * Good tests * Not much model code -- I think it's all mostly in place. Correct me if I'm wrong. * Identity and encryption. Authorization doesn't do a lot of good if anyone can bumble along and impersonate anyone else, so it would be pretty nice to have at least a workaday identity and encryption setup. Conversations with potential users have suggested the following minimum features, feel free to suggest your own: * Conductor will authenticate against an LDAP server. Since most LDAP servers in the real world are Windows Active Directory, we should probably include AD in the set of servers we test against. * Fall back to local user data store, maybe? You can imagine needing a local admin user that isn't in LDAP, for example * Be able to proxy identity when talking to other things that need to know it. Checking identity when saving things to/retrieving things from Image Warehouse is the main requirement for this. I think it's getting a GSSAPI library soon which should help. We will also probably need this for Katello, when we get to talking to it. FWIW Katello is currently using two-legged OAuth for this, so I would think this would be the primary candidate for us too. * A way to encrypt the traffic between Conductor, Deltacloud API, Warehouse, and Katello. The obvious solution for this is ssl certs that are created and signed by the installer, with some way to update/revoke them. * Admin UX work * We need to give the pool, pool family, and provider management screens the same loving treatment we have given the instance management screens. * We need to make sure self-service really is sane. A big part of self service is image visibility -- i.e. who can launch what where (VMWare's "Catalog" concept answers this requirement for them). A good self-service solution is going to take thinking through some use cases and some serious UX work as well. * I'd really like to see a front door to the Conductor app. I'm afraid to call it a "dashboard" because then it will never get built :). I'd love suggestions for what should appear on such a thing. * Other UX work * I think we should be able to launch single images from Conductor without requiring a deployable XML. To make that easier for users, it would be nice if there was some UI for displaying images that are available to launch. * Status reporting * We should reliably display the status of a running instance and its uptime * We should start thinking about how we will handle the richer data about instance health that we will get once Matahari is in place * Users should be able to view an audit trail of events for an instance or a set of instances * Users should be able to export those events * API * We've been saying for a very long time that we need a real API for managing Conductor and for doing instance stuff in Conductor. If we admit that we have to manage instances that are not part of deployments, then we can also just say that the Deltacloud API we expose only works for instances. I think this is good enough for the next release. Infrastructure-around-Conductor features: * Identity and encryption. In addition to the bits that go in Conductor proper, there's going to be a lot of work in the installer and in other projects nearby. * Better self-monitoring. I'd like to see a quick shell command that will give a meaningful report of the status of all the app components. * Way better logging and error reporting. * All components should be using syslog if at all possible * Logs should be timestamped * We should not be logging credentials or things that are potentially embarassing * Components can be distributed across multiple machines * RHEV-M 3.0 really works as a cloud provider. "Orchestrator" features (even though these aren't yet separate components, I've bracketed off stuff that concerns post-boot and multi-instance operations as conceptually different topics to work on) * Assemblies * Users can define assemblies that cause the post-boot config apparatus to install software and set config parameters on instances when they check in after booting * Deployables and deployments * Users can define deployables that contain multiple assemblies. * Users can specify parameters that should be collected from a user when the user launches the deployable. * Users can direct that parameters collected from a user be interpolated in arbitrary spots in the deployable descriptor. * There is a UI for collecting parameters from the launching user * There is a mechanism for passing all the assembly and deployable config information through to the post-boot agent. (I think this could use user-data, *or* a config server.) * Authorization * Should there be some way of restricting the assemblies/deployables that a user can launch on particular hardware? -- == Hugh Brock, hbrock(a)redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey

13 35

Refactored pools destroy and multi_destroy
by Jirka Tomasek 22 Jul '11

22 Jul '11

Pools destroy and multi_destroy to resemble deployments actions, added validation when no pool is selected and javascript is turned off.

2 2

RFC: What is Aeolus?
by Hugh O. Brock 22 Jul '11

22 Jul '11

I had one too many new hires ask me just what the purpose of Aeolus as an upstream project was, so I decided I would have a crack at writing it down. What I've done here is try to list the things we want Aeolus users to be able to accomplish by using the various pieces under our umbrella. I tried to hold it together with a draft of a "mission" at the top, although I'm afraid it still turned into a bit of a laundry list. This is a community project, so I shouldn't be the one dictating this stuff. Therefore I ask, nay beg each of you who have contributed code on this list (or nearby it, even): Please, read the list and tell me a. what I've left out, b. what should be reworded, or c. what we *shouldn't* be doing as part of Aeolus. I'm happy to add or consolidate points as needed to make the document better. Once folks are generally happy with it, I'll ask Justin to put it on the website. Hopefully it will be helpful... Thanks, --Hugh -- == Hugh Brock, hbrock(a)redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey What is Aeolus? =============== Aeolus mission: Give users tools to build and manage organized groups of virtual machines across multiple clouds. So, what does Aeolus need to provide a user to accomplish its mission? * The "manage" part, handled by Aeolus Conductor * We want a way to let a user launch a VM or a clump of VMs on a cloud, track them through their lifecycle, and clean them up when they are no longer needed. * We want the user to be able to wait to decide where to launch their clump until the very last minute, or even let us decide for them. * We want the user to be able to set runtime values for the VMs in their clump at launch-time * We want the user to be able to easily check how much cloud time they have burned up, set threshholds for alerting them when interesting things happen (a VM crashed, they're about to go over n hours of usage this month), and share access to their VMs with others. * We want an admin user to be able to group cloud resources for other users, so that they can track and control which resources are used and at what level. * We want all this to happen in a truly superior GUI. * The "build" part, handled by Aeolus Image Factory * We want to let a user create a template that we can build into images for each cloud they are interested in * We want to let the user, as part of building the image, specify arguments to pass into the build process to configure software installation, and also to specify values that will be passed back into the image metadata to be used later. * We want to let the user build images for multiple operating systems, including Windows and various Linux flavors. * We want to let the user rebuild images from the original template if needed. * The "Organized Groups" part, handled by Audrey (config) and Matahari (monitoring) * We want to give our users a way to specify a clump of images to launch. We want the user's specification to be human readable and portable. * We want the user to be able to specify values to collect at launch-time via the Conductor UI. The values will influence how the instances configure themselves, either by being interpolated into config snippets in the clump specification, or by being passed directly to the instance post-boot. * We want the user to be able to include config snippets for each instalce in their specification that will run after the instance boots, injected by Audrey. Config snippets can do anything including install software packages, set config values, or start and stop services. Config snippets can be in any form that the user's image supports -- Puppet manifest, bash script, powershell script are all fine. * We want the user to be able to monitor software and services on the guest, and the health of the guest. * The "Multiple Clouds" part, handled by Deltacloud * We want users to be able to connect to and use multiple clouds as seamlessly as possible. * We want users to be able to set up complex network and storage topology in multiple clouds just as they would in a bare-metal environment. So a user should be able to describe a subnet for his VM clump and the Conductor and the Deltacloud API should make appropriate calls into the back-end cloud to create that subnet and then launch the user's instances in it.

14 31

[PATCH aeolus-image] Fixed Bug in checkbucket for list templates
by Martyn Taylor 22 Jul '11

22 Jul '11

From: Martyn Taylor <mtaylor(a)redhat.com> --- lib/list_command.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/list_command.rb b/lib/list_command.rb index ac0bc17..062adbb 100644 --- a/lib/list_command.rb +++ b/lib/list_command.rb @@ -46,7 +46,7 @@ module Aeolus end def targetimages - check_bucket_exists("target-images") + check_bucket_exists("target_images") doc = Nokogiri::XML iwhd['/target_images'].get doc.xpath("/objects/object/key").each do |target_image| begin -- 1.7.4

2 1

[PATCH conductor] Fixed broken provider account rspec test
by Jan Provazník 22 Jul '11

22 Jul '11

From: Jan Provaznik <jprovazn(a)redhat.com> --- .../provider_accounts_controller_spec.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/spec/controllers/provider_accounts_controller_spec.rb b/src/spec/controllers/provider_accounts_controller_spec.rb index 503216b..d994c39 100644 --- a/src/spec/controllers/provider_accounts_controller_spec.rb +++ b/src/spec/controllers/provider_accounts_controller_spec.rb @@ -26,7 +26,7 @@ describe ProviderAccountsController do post :create, :provider_account => {:provider_id => @provider.id} response.should be_success response.should render_template("new") - response.flash[:error].should == "Credentials are invalid!" + response.flash[:error].should == "Cannot add the provider account." end it "should permit users with account modify permission to access edit cloud account interface" do -- 1.7.4.4

2 1

[PATCH conductor] modified role.feature to use element ids
by Tomas Hrcka 22 Jul '11

22 Jul '11

--- src/app/views/roles/_form.haml | 4 ++-- src/app/views/roles/show.haml | 4 ++-- src/features/role.feature | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/app/views/roles/_form.haml b/src/app/views/roles/_form.haml index a22b97c..0f60466 100644 --- a/src/app/views/roles/_form.haml +++ b/src/app/views/roles/_form.haml @@ -3,5 +3,5 @@ = form.label :name, 'Name' = form.text_field :name, :class => "em long" %fieldset.options - = form.submit "Save", :class => "submit button" - = link_to t(:cancel), roles_path, :class => 'button button' + = form.submit "Save", :class => "submit button", :id => 'role_submit_button' + = link_to t(:cancel), roles_path, :class => 'button button', :id => 'role_cancel_button' diff --git a/src/app/views/roles/show.haml b/src/app/views/roles/show.haml index a7804e3..debc487 100644 --- a/src/app/views/roles/show.haml +++ b/src/app/views/roles/show.haml @@ -4,8 +4,8 @@ #obj_actions.button-container = link_to 'New Role', new_role_url, :class => 'button primary', :id => 'new_role_button' .button-group - = link_to 'Edit', edit_role_path(@role), :class => 'button pill' - = button_to 'Delete', role_path(@role), :method => :delete, :class => 'button pill danger', + = link_to 'Edit', edit_role_path(@role), :class => 'button pill', :id => 'edit_role_button' + = button_to 'Delete', role_path(@role), :method => :delete, :class => 'button pill danger', :id => 'delete_role_button', :confirm => "Are you sure you want to delete this role?" .corner   diff --git a/src/features/role.feature b/src/features/role.feature index abd0157..c47e840 100644 --- a/src/features/role.feature +++ b/src/features/role.feature @@ -13,10 +13,10 @@ Feature: Manage Roles Given I am on the roles page And there should be a role named "Captain" When I follow "Captain" - And I follow "Edit" + And I follow "edit_role_button" Then I should see "Editing Role:" - When I fill in "role[name]" with "Admiral" - And I press "Save" + When I fill in "role_name" with "Admiral" + And I press "role_submit_button" Then I should see "Role updated successfully!" Scenario: Show role details @@ -37,7 +37,7 @@ Feature: Manage Roles And there are 2 more roles When I check "Admiral" role And I check "Captain" role - And I press "Delete" + And I press "delete_button" Then there should be 0 more roles And I should be on the roles page And I should see "These Roles were deleted: Captain, Admiral" -- 1.7.4.4

1 0

[PATCH] Remove more than one deployment at a time
by Jirka Tomasek 22 Jul '11

22 Jul '11

This patch fixes BZ723306. It implements multi_destroy feature for deployments and deployments/_list.haml is used for displaying deployments table thoughout the application (filter views)

1 3

← Newer
1
2
3
4
5
6
7
8
9
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel July 2011