Rails 3 update in your future
by Chris Lalancette
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
12 years, 9 months
FOSSCON presentation
by Mo Morsi
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
12 years, 9 months
Release 0.4.0 planning
by Hugh O. Brock
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
12 years, 9 months
RFC: What is Aeolus?
by Hugh O. Brock
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.
12 years, 9 months
[PATCH aeolus-image] Fixed Bug in checkbucket for list templates
by Martyn Taylor
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
12 years, 9 months
[PATCH conductor] Fixed broken provider account rspec test
by Jan Provazník
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
12 years, 9 months
[PATCH conductor] modified role.feature to use element ids
by Tomas Hrcka
---
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
12 years, 9 months
[PATCH] Remove more than one deployment at a time
by Jirka Tomasek
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)
12 years, 9 months
