Open Stack

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 <rakhmerov at mirantis.com>wrote:

>
> On 13 Mar 2014, at 10:40, W Chan <m4d.coder at 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 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/20140313/21313f24/attachment.html>