RFC: Component Diagram

Matt Wagner matt.wagner at redhat.com
Mon Mar 19 14:20:12 UTC 2012


On Thu, Mar 15, 2012 at 01:43:52AM -0400, Dan Macpherson wrote:
> Hi guys,
> 
> Based upon Máirín's feedback, I put together a graphical version of Matt's image using Inkscape. See attached.

Hi Dan,

We spoke on IRC, though I never replied here. This looks fantastic!
Thanks for this.

> All comments and suggestions are welcome.

The initial diagram I had sent out was a bit of a rough draft, besides
being hideously ugly. In collecting feedback from various people, I've
identified a number of changes we'd like to make. Is this something
you're able to do, or should I make the changes? (I don't want to dump
work on you after you so graciously put this together!)

Here are changes that we have identified:

* Image Factory writes to Image Warehouse, so there should be an arrow
 extending from Factory -> Warehouse.

* "Postgre" should read "Postgres"

* The arrow between dbomatic and deltacloud-client is backwards --
 it should show dbomatic -> deltacloud-client (gem). (dbomatic uses
 deltacloud-client to get status from cloud providers, and writes that
 information to Conductor, so really, both arrows should be 'leaving'
 dbomatic.)

* I had left out Audrey entirely. From talking to a few people, I think
 simplest way to represent it accurately would be to show:
 Conductor -> Config Server <- Cloud Instances. Audrey Config Server
 receives configuration information from Conductor, and then agents in
 cloud instances call back to Config Server. (Does this make sense to
 everyone?)

* Martyn pointed out that incoming connections to httpd use HTTPS :443,
 not HTTP :80. In addition, I realized that I used a comma in the HTTP
 examples ("HTTP, :80"), but didn't use the comma elsewhere ("REST
 :9090"). For consistency, we should probably just drop the comma for
 the two HTTP steps.

* Image Factory writes images directly to clouds. It's probably
 important to show this, although I fear that we're going to start to
 get to the point where the diagram is just lines everywhere.

Martyn also pointed out that Mongo listens on :27015, but it wasn't
clear what protocol it used. I'm inclined to stay we shouldn't show
this, if only because we don't show it for Postgres. (Although I think
Postgres might be listening on a socket?) The port numbers were sort of
incidental, but I thought they were helpful to show. While people might
want to connect directly to, say, Deltacloud server, I'm not sure anyone
is ever going to try to telnet to the mongo port for debugging. (And if
they do, they're probably not going to need this diagram.)

One additional thing -- I happened to show EC2 and RHEV as cloud
providers, since they're commonly-used examples, and I wanted to show
(a) that we support multiple providers with their native APIs, and (b) a
mix of public clouds and private clouds. Do you think it's clear enough
that are examples, as opposed to the only two providers we support?

-- Matt



More information about the aeolus-devel mailing list