On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant <ishant.ty...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev