Open Stack

On Tue, Sep 09, 2014 at 10:15:04AM +1000, Angus Salkeld wrote:
> On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant <ishant.tyagi at hp.com> wrote:
(snip)
> >
> Great! Good to see something.

Indeed. These diagrams are very useful for those who read plain English
text very slow and those who do visual thinking, like me.  Thanks.

Some comments/questions below, following Angus's.
> 
> I was expecting something like:
> engine ~= like nova-conductor (it's the only process that talks to the db -
> make upgrading easier)
> observer - purely gets the actual state/properties and writes then to the
> db (via engine)
> worker - has a "job" queue and grinds away at running those (resource
> actions)

This looks much cleaner an overview. If I'm understanding this
correctly, an observer can be a pollster or just a consumer subscribing
to certain notifications on queue.  We are gonna have a lot of observers
dedicated to each sub-tree or even individual resource, right?  It would
be cool if we can depict how the observers coordinate their operations.

As for the workers, they appear to me like consumers to a (shared?) 'job'
queue. We are relying on the messaging backend to ensure the persistence of
jobs, right?  Or, we may persist the jobs in Heat DB so that an engine
restart will not cause confusions?

> Then engine then "triggers" on differences on goal vs. actual state and
> create a job and sends it to the job queue.
> - so, on create it sees there is no actual state so it sends a create job
> for the first resource to the worker queue
> - when the observer writes the new state for that resource it triggers the
> next resource create in the dependency tree.

It seems to me that the observers should observe and then calculate,
notify the differences?  I am also assuming that other stack operations
will fit into the big picture, but don't know how...

> - like any system that relies on notifications we need timeouts and each
> stack needs a periodic "notification" to make sure
>   that progress is been made or notify the user that no progress is being
> made.

Vote on this. 

> One question about the observer (in either my setup or the one in the
> diagram).
> - If we are relying on rpc notifications all the observer processes will
> receive a copy of the same notification
>   (say nova create end) how are we going to decide on which one does
> anything with it?
>   We don't want 10 observers getting more detailed info from nova and then
> writing to the db
> 
> In your diagram worker is communicating with observer, which seems odd to
> me. I thought observer and worker were very
> independent entities.

+1.

Things may get simplified if we use messaging only for notification's
purpose, not for RPC between observer and convergence workers.

  
> In my setup there are less API to worry about too:
> - RPC api for the engine (access to the db)
> - RPC api for sending a job to the worker
> - the plugin API
> - the observer might need an api just for the engine to tell it to
> start/stop observing a stack
> 
> -Angus

Regards,
  Qiming