On the transport variable, the problem I see isn't with passing the variable to the engine and executor. It's passing the transport into the API layer. The API layer is a pecan app and I currently don't see a way where the transport variable can be passed to it directly. I'm looking at https://github.com/stackforge/mistral/blob/master/mistral/cmd/api.py#L50and https://github.com/stackforge/mistral/blob/master/mistral/api/app.py#L44. Do you have any suggestion? Thanks.
On Thu, Mar 13, 2014 at 1:30 AM, Renat Akhmerov <rakhme...@mirantis.com>wrote: > > On 13 Mar 2014, at 10:40, W Chan <m4d.co...@gmail.com> wrote: > > > - I can write a method in base test to start local executor. I will > do that as a separate bp. > > Ok. > > > - After the engine is made standalone, the API will communicate to the > engine and the engine to the executor via the oslo.messaging transport. > This means that for the "local" option, we need to start all three > components (API, engine, and executor) on the same process. If the long > term goal as you stated above is to use separate launchers for these > components, this means that the API launcher needs to duplicate all the > logic to launch the engine and the executor. Hence, my proposal here is to > move the logic to launch the components into a common module and either > have a single generic launch script that launch specific components based > on the CLI options or have separate launch scripts that reference the > appropriate launch function from the common module. > > Ok, I see your point. Then I would suggest we have one script which we > could use to run all the components (any subset of of them). So for those > components we specified when launching the script we use this local > transport. Btw, scheduler eventually should become a standalone component > too, so we have 4 components. > > > - The RPC client/server in oslo.messaging do not determine the > transport. The transport is determine via oslo.config and then given > explicitly to the RPC client/server. > > https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/engine.py#L31and > > https://github.com/stackforge/mistral/blob/master/mistral/cmd/task_executor.py#L63are > examples for the client and server respectively. The in process Queue > is instantiated within this transport object from the fake driver. For the > "local" option, all three components need to share the same transport in > order to have the Queue in scope. Thus, we will need some method to have > this transport object visible to all three components and hence my proposal > to use a global variable and a factory method. > > I'm still not sure I follow your point here.. Looking at the links you > provided I see this: > > transport = messaging.get_transport(cfg.CONF) > > So my point here is we can make this call once in the launching script and > pass it to engine/executor (and now API too if we want it to be launched by > the same script). Of course, we'll have to change the way how we initialize > these components, but I believe we can do it. So it's just a dependency > injection. And in this case we wouldn't need to use a global variable. Am I > still missing something? > > > Renat Akhmerov > @ Mirantis Inc. > > > _______________________________________________ > 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
