We have access to all configuration parameters in the context of api.py. May be you don't pass it but just instantiate it where you need it? Or I may misunderstand what you're trying to do...
DZ> PS: can you generate and update mistral.config.example to include new oslo messaging options? I forgot to mention it on review on time. On Mar 13, 2014, at 11:15 AM, W Chan <[email protected]> wrote: > 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#L50 and > 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 <[email protected]> > wrote: > > On 13 Mar 2014, at 10:40, W Chan <[email protected]> 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#L31 >> and >> https://github.com/stackforge/mistral/blob/master/mistral/cmd/task_executor.py#L63 >> are 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
