[openstack-dev] [Heat] convergence flow diagrams

Angus Salkeld asalkeld at mirantis.com
Tue Sep 9 00:15:04 UTC 2014


On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant <ishant.tyagi at hp.com> wrote:

>  Hi All,
>
>
>
> As per the heat mid cycle meetup whiteboard, we have created the
> flowchart and sequence diagram for the convergence . Can you please review
> these diagrams and provide your feedback?
>
>
>
> https://www.dropbox.com/sh/i8qbjtgfdxn4zx4/AAC6J-Nps8J12TzfuCut49ioa?dl=0
>
>
Great! Good to see something.


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)

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.
- 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.

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.

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


>
>
> Thanks,
>
> Ishant
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/e839ea61/attachment.html>


More information about the OpenStack-dev mailing list