RFC: Component Diagram

Dan Macpherson dmacpher at redhat.com
Tue Mar 20 01:13:57 UTC 2012


Hi Matt,

Certainly, I can take care of the changes.

As for the other bit regarding providers, I had an idea: Still use two icons, but one to represent Public Cloud Providers (and list examples such as EC2, Rackspace, etc) and one to represent Private Cloud Providers (examples such as RHEVM/ovirt and vSphere). That way we show not only that we support a variety of providers, but we demonstrate that we support providers both public and private.

- Dan

----- Original Message -----
> 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