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