Here is the proposal for a Dashboard feature planned for this iteration.
The general idea is to have a two separate dashboards for each section
(Monitor, Administer), as the Overview (Pools#index pretty view) already
works as Dashboard for Monitor section.
It already contains:
* ribbon with basic statistics of Pools, Deployments, Instances, Alerts,
Updates and global Quota overview
* list of latest alerts
* Overview on Pools their status and status of its Deployments and
Instances with direct access to manage them.
* possibility to get to detailed list view with a single click
Pools Overview section also has links to basic operation as launching or
Managing deployments from within its Pool.
Having a separate Dashboard would mean duplicating of this information
unless Pools Overview section would have been redesigned.
Administer section does not have an Overview section so the idea is to
create similar Overview/Dashboard section as the Monitor section has
which resembles it graphically by using slightly changed UI elements
used in Monitor section as we dont have any wireframes or design
guidelines for it.
The main part of proposed Administer section Overview utilizes the Admin
subsections navigation as a table of boxes for each subsection (similar
to Instances display in Deployment detail pretty view) which contains:
* subsection icon
* title - linking to given subsection
* information about elements count or other relevant info (current
* link to most used function for given subsection (create new user, add
suggested deployable, ...)
Subsections: Users, Roles, Providers, Provider Accounts, Hardware
Profiles, Realms, Pool Families, Suggested Deployables, Settings
Based on the amount of data we want to display the box can have
different size (e.g. Settings subsection box section with current
settings summary can use twice as big box than other)
Navigating back from a subsection to Overview can be done via Breadcrumb
leading to it or by clicking the Administer tab. Current controll panel
select should be put in each subsection to provide navigation among
subsections without returning to Overview.
Other relevant info like last 5 items from user related Action History
(similar to Alerts section in Pools Overview) can be included when its
Administer section Overview simplyfies the navigation for administrator
and speeds up the access to most of the tasks he want to perform in
Administer section. It should be relatively easy to implement as the
current UI elements could be used and it doesnt require changes to
application structure or logic.
Having two separate Dashboards or Overviews simplifies the problem with
having to deal with displaying different amount of information based on
Creating Administer section Overview largely depends on Admin section UX
which is about to be discussed.
Features and Tasks:
As an admin I want to have an Overview in Administer section
* prepare UI design and elements for Subsections boxes
* implement Subsection box navigation with subsection info and links
* remove controll panel select
As an admin I want to navigate around Administer section
* Implement Breadcrumbs to navigate from Admin subsection to Overview
* Add Controll panel select to each subsection to enable navigation
among subsections without returning to Overview
As an admin I want to see last 5 events in Action history (depends on
Action history implementation)
* Implement Action history overview based on Pools pretty view Alerts
section with last 5 events and link to Action history page, placed under
Subsections box navigation.
While testing aeolus I've found that aeolus is mainly conceived for
stateless instances (https://www.aeolusproject.org/redmine/issues/1059).
Will additional functionalities for stateful images be added in aeolus?.
I guess support for stateful instances would require:
- Differentiate between stopped and deleted (or terminated).
- Being able to re-start an stopped instance.
- Being able to delete an stopped instance (to destroy the underlying vm)
- Being able to modify an existing instance (for example, assigning a
different hardware profile)
I think statefull instances will be mainly required in private clouds
using RHEV or VMware providers, i.e.
As deltacloud support both start/stop/destroy vms, I guess this is
doable, is it in current roadmap plan?
Providing a formal deffinition of the XML for an API, makes using the API, in particular creating and maintaining client applications that utilise the API much simpler, and far clearer for a developer.
There are an array of tools that provide class generation, and automatic marshalling and unmarshalling of objects, generated straight from a formally defined XML Document, for ruby, this project looks to offer these functions: https://github.com/rubyjedi/soap4r .
In my experience writing Java and Android clients, I have found that the time spent creating an XSD or other formal XML definition, repays 10 fold in development time, and also makes keeping clients up to date alot simpler. For DC Client I ended up writing my own: https://github.com/mtaylor/deltacloud-tools/blob/master/DeltaCloudClient/...
But, I think it would be better as a whole to adopt this approach from the start. It would not only benefit the creation of the CLI but also anyone else who needs to utilise these APIs
deltacloud-devel mailing list
As we plan the next iteration, I've been asked to organize our work
around the ability to launch an image without having to manually craft
an XML file and host it on a webserver. Instead, Conductor users should
be able to use a tool in Conductor to browse images stored in Image
Warehouse, click one of them, select a hardware profile and maybe a
pool, and launch it.
There's a semi-related feature to be able to import images. I've
proposed treating it as a separate feature so as to not confuse the
discussion, but it's also in scope for this next iteration so I'll
mention it here.
My plan, if I haven't misunderstood the request, is to start a
discussion here, and then create a wiki page once the discussion
stabilizes a bit.
The work required is something like this:
* Figure out how this should interface with the UI. I think the actual
"launch an instance" form can be very simple, but it's not abundantly
clear to me where we should place the listing of images in Warehouse.
We should solve this before we dive in on implementation.
* Interface with Image Warehouse. We're already doing this to some
extent, but two major areas came up on the call today. The first is
that a lot of what we're doing is already supported in the
aeolus-image command-line tool. To avoid code duplication and
reinventing the wheel, we'd like to break out a common library we can
both use. (This also applies to image importation.) Obviously, we'll
want to work with the Infrastructure team around aeolus-image. Second,
we endeavor to switch from our custom-written WarehouseModel code
using rest-client and nokogiri to ActiveResource.
* Actually implement it once we know where it goes, how it should look,
and have a better layer to connect to Warehouse. We'll collect the
user data, probably within the context of a pool, create a deployable
behind the scenes with this image in it, and then launch it like it's
a normal deployable.
This task should convey the following advantages:
* The workflow will be simplified for users who do not need multi-image
deployable. They will not need to create an XML file, and will not be
required to have a webserver running to host the deployable XML. I
know from experience that the whole notion of pasting UUIDs into XML
files and pushing them to webservers was not entirely popular among
* It will provide an interface for browsing Image Warehouse. Right now
(as far as I'm aware), you're resigned to either getting XML back from
Warehouse, or using the command-line tools if you want to know what
images are stored in Conductor. Both are perfectly valid, but we'll
implicitly provide a GUI.
* Ideally, we will incidentally improve the responsiveness of our
interface to Warehouse as we switch to ActiveResource, though this
remains to be seen.
* Although it's not an intentional goal, this may make it easier down
the road if we ever decide that we want to provide a GUI for creating
Let the discussion commence!
One of the proposed features for this iteration is Status Reporting.
There are four main components to it:
* Handling changes that happen on the backend provider
* Storing & displaying user actions
* Generating and exporting reports
* API to notify and get notified by external services (Matahari)
Below, I'll go over each of these and comment on what we have and what
needs to happen. At the end I wrote some features and tasks that I think
should go into Redmine.
Please, do speak your mind and write your suggestions and feedback in
Most of the functionality is already in place: when an instance crashes
or is stopped outside of Conductor, Condor picks it up and updates the
Additionally, we calculate instance's uptime and as far as I could tell,
it's as accurate as we can reasonably get without running an agent
directly on the instance (hello, Matahari).
What's missing here is mostly the UI: Instance's uptime is not displayed
at all. We do show uptime for Deployments, but that one is not
calculated correctly, so that needs to be fixed.
It would also improve the user experience, if we updated these values
automatically -- without having to reload the page.
So when you launched a deployment, you'd get the deployment-details page
that shows its status as 'pending'. Once the deployment is running, the
status would change to 'running' automatically and the uptime would
start to count.
Doing this consistently across the app would be great but isn't trivial.
would soon became a mess. Libraries like Backbone.js should help, but
it takes some time and effort getting them in. Backbone in particular
isn't a drop-in solution. Others may be. Suggestions?
Again, some of it is in place already: we have a model called Event that
is hooked to the `after_save` callback of Instance and it writes a
timestamped entry every time an instance changes.
What needs to be done here:
* Better UI
- Right now we show instance's history in the ugly & forgotten
instance#show page. It would make sense to make it look prettier, and
possibly display the events on the Deployment page for all its
* Make the event log persistent
When an instance gets deleted now, all events get deleted with it. What
we want to do instead is to hide the instance from the UI but keep it
and the events around so that we can still generate correct reports.
Matt Wagner suggested a couple of gems that should handle this
pretty transparently. They're worth looking into as doing this by
ourselves could get tricky.
* More events as needed
Generating And Exporting Status Reports
Right now, this will mean creating a simple CSV file that can be downloaded.
Possibly something like:
plus a way of accessing that from the UI.
The first implementation of this will be for admins only, thus no
permission checking is needed. Same goes for showing a history on a
single object: if you can see the instance, you should be able to see
its history as well.
However, we'll probably end up more granular ways of displaying the
data: for instance a user will want to see what happened with their
resources. Similarly, an admin may want to check history of a particular
user or a pool. Or seeing just the last moth's activity.
For this we'll need to add permission checks and some querying
capability + UI. That's out of this iteration's scope, though.
Matahari And Other External Services
Again, this is outside of this iteration's scope.
As we'll want to get notification from Matahari (and maybe other
services) we'll need a way to get notified about events that should be
logged but that Conductor itself cannot detect.
From talking to Matahari folks, it seems they need Conductor to let
them know when an instance was started and stopped.
If I understand it correctly, the whole notion of Config Server is to
have something that communicates with the in-instance agents (matahari).
Thus, we may want to hijack that and send the messages through Config
Server rather than directly.
This will save us the trouble of creating yet another communication
interface and discovering the matahari agents. Rather, we'll piggyback
on something that's already planned anyway.
As for other services notifying Conductor, this can be as simple as:
So, like, fyi, that thingy over over here has changed.
Possibly with a timestamp in the request body so that we can log when
the event happened vs. when it was received.
However, this must be tied into whatever way we implement cross-module
authentication and authorization, otherwise everyone will be able to
create phoney events.
Features & Tasks
As a user, I want to see the uptime of my instances and deployments
* Display uptime of instances in the UI
* Fix the uptime calculation for deployments
As a user, I want to see Conductor always show the current status
without having to press <F5> every time
* Implement Backbone.js or some other system that will make this easy for us
* Dynamically update the instance/deployment status across Conductor
* Dynamically update the scoreboards in the Monitor section
* Dynamically show/hide errors as they unfold happen on the backend
* Periodically update uptime values so that they're always semi up-to-date
As an admin, I want to see a report of everything that happened to instances
* Generate a report of all the Events in a machine-processable format
* Add a download link for the report into the UI
* Make this available to administrators only
As an admin, I want to get the full reports even when the instances have
* Make the event logs persistent even on instance deletion
* Preserve the data associated with the deleted object for events/reports
As an admin, I want to be able to query the status report to get to the
info I need
- note: this is probably out of scope for the Iteration 4.
* Filter by a specific timeframe
* Filter by a specific user
* Filter by a specific pool
As a user, I want to be notified on changes that happen inside of an
- note: this is out of scope for the Iteration 4.
* Implement a way of communicating with Matahari
* Provide an API for getting event notifications from external services
As a user, I want to be able to see and query events of objects that I
have access to
- note: this is out of scope for the Iteration 4.
* Display the status reports filtered by user's permissions
We just finished pushing the last of the Aeolus components into Fedora.
As soon as they propagate out to the mirrors, you should be able to
install Aeolus directly from Fedora via 'yum install aeolus-all'
As you are aware, the rails 3 port has been going on for some time. I'm
happy to report that I have now pushed the rails 3 port to the master branch.
This is going to cause some short term problems, but I'm hoping to get the
whole team involved in fixing those problems. In particular I know there is
With that said, if you want to run the new code on your existing setups,
you have 2 options:
1) Install a VM with rawhide, which will have all of the "known working"
packages already available.
2) Use gem to install the known working packages.
If you go for option 2), you'll need to know the list of gems. Attached to
this mail is the Gemfile and Gemfile.lock of the dependency list on rawhide.
The Gemfile is already in the git repository; I'll probably also be importing
the Gemfile.lock soon. You can use the attached files to "bundle install" in
Because aeolus-all won't currently work due to unmet dependencies, in addition
to the gems you need to install some packages:
yum install aeolus-configure condor-deltacloud-gahp iwhd imagefactory \
qpid-cpp-server mongodb-sever mod_ssl deltacloud-core ntp \
rubygem-aeolus-image rubygem-aws rubygem-rbvmomi
In the meantime, we'll be working to compile the necessary packages on
Fedora-14/Fedora-15/RHEL-6 so that 'yum install aeolus-all' will work again.
Let me know if you have questions about any of this.
Here's a revision of the 0.4.0 planning document that contains my
attempt to capture the many suggestions and comments thus far. I think
it's starting to look like a nice wish-list for a release, although I
want more detail on the Orchestrator bits.
Speaking of the whole Conductor/Orchestrator split. Mark and I got
very excited about this because it seemed like there would be room for
two smaller independent OSS projects there rather than one big hairy
one. I've heard privately from various people however that they
thought that split would leave Conductor as a not-all-that-interesting
piece by itself, concerned only with cloud resource allocation and
permissions (and some level of display of various things).
How do folks out there feel about this? Can we have some debate here,
Oh, and please feel free to comment further on the revision below.
== 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."
* 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
* Admin UX work
* We need to give the pool, pool family, and provider management
screens the same loving treatment we have given the instance
* 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
* Other UX work
* I think we should be able to launch single images from Conductor
without requiring a deployable XML.
* To facilitate launching single images, I think we need a UI that
shows the images that are available in the warehouse for the user
to launch. I also think we need a really, really easy way to
import existing images. I had proposed associating this UI with
pools in some way, since a pool is where you go to launch stuff,
but we need to work through the UX process to decide all that for
* We need to determine whether and how soon Katello will provide a
UI for defining images to build with Image Factory. If that UI is
a long way off, we should consider building a simple, serviceable
web UI that stands alone with Image Factory but could conceivably
be plugged into a common look-and-feel with Conductor. However I
don't advocate rushing into that unless there is a really strong
upstream need for such a thing.
* Status reporting
* We should reliably display the status of a running instance and
* We should start thinking about how we will handle the richer data
about instance health that we will get once Matahari is in place,
and about the API we'll need to provide the Cloud Policy Engine so
it can tell Conductor about events it generates or handles.
* 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
* 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.
* We need to make sure the Image Factory API is callable by
Katello. This may mean resurrecting Connector, as I'm certain
Katello is going to prefer a REST API to the QMF one.
* I'd like to see the community get into the habit of creating or
updating wiki how-to pages as we go along. I'm not sure exactly
how to promote this (free beer once a month to the best new
page?), but I am fairly sure we do need to make the infrastructure
a little easier to deal with for it. Like it would be good if the
wiki didn't become unreachable a lot, the way the Redmine wiki
seems to do.
* 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
* 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
* 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)
* 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
* Investigate how much assembly config can be stuffed into user-data
without requiring config server, since we now have a working
userdata mechanism on the three cloud back ends we really care
* 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.)
* Should there be some way of restricting the assemblies/deployables
that a user can launch on particular hardware?
One of the goals of this iteration is Encryption.
What do we have at disposal right now ?
- We're using Public Key Infrastructure(PKI), where now we store SSL
cert of Conductor (it's self-signed).
- We generate SSL cert/key for Conductor in puppet recipe.
- We can generate certs for other parts in the same way.
- Conductor run on HTTPS by default in production environment.
What would we like to achieve in this iteration ?
* encrypt traffic between IWHD, Conductor, DC-API:
We expect that IWHD and DC-API will run on remote machines, so we
need to encrypt communication between those machines.
Is it need to add some gem(s) ?
No it isn't. After discussion we don't assume that we need to add some
gem(s). Maybe it will be good to check Dmitri Pal suggestions (his
e-mail as reply to mmorsi's one w/ subject 'Iteration 4 Features')
What would we do to complete this goal ?
For Conductor side:
- revise the codes of communication with IWHD and DC-API.
For IWHD should be easy, now we are using hardcoded URL of this
service, thus we will fix it for HTTPS. We use RestClient for
communication with DC-API, so we will check how is possible (and it's
possible) to wrap RestClient request to secured mode.
For Infrastructure team:
- generate SSL certs/keys for IWDH and DC-API,
- decide how to change off public certificates between services that
will run on remote machines.
- Michal Fojtik will handle option for 'deltacloudd', when we want to
run DC-API on HTTPS.
Please check if I mentioned all services, that we need to run them on
HTTPS and encrypt the traffic between them.