I have the following murano-ci failure for my last patch set. https://murano-ci.mirantis.com/job/mistral_master_on_commit/194/ Since I modified the API launch script in mistral, is that the cause of this failure here? Do I have to make changes to the tempest test? Please advise. Thanks.
On Fri, Mar 21, 2014 at 3:20 AM, Renat Akhmerov <rakhme...@mirantis.com>wrote: > Alright, thanks Winson! > > Team, please review. > > Renat Akhmerov > @ Mirantis Inc. > > > > On 21 Mar 2014, at 06:43, W Chan <m4d.co...@gmail.com> wrote: > > I submitted a rough draft for review @ > https://review.openstack.org/#/c/81941/. Instead of using the pecan > hook, I added a class property for the transport in the abstract engine > class. On the pecan app setup, I passed the shared transport to the engine > on load. Please provide feedback. Thanks. > > > On Mon, Mar 17, 2014 at 9:37 AM, Ryan Petrello < > ryan.petre...@dreamhost.com> wrote: > >> Changing the configuration object at runtime is not thread-safe. If you >> want to share objects with controllers, I'd suggest checking out Pecan's >> hook functionality. >> >> >> http://pecan.readthedocs.org/en/latest/hooks.html#implementating-a-pecan-hook >> >> e.g., >> >> class SpecialContextHook(object): >> >> def __init__(self, some_obj): >> self.some_obj = some_obj >> >> def before(self, state): >> # In any pecan controller, `pecan.request` is a thread-local >> webob.Request instance, >> # allowing you to access `pecan.request.context['foo']` in your >> controllers. In this example, >> # self.some_obj could be just about anything - a Python >> primitive, or an instance of some class >> state.request.context = { >> 'foo': self.some_obj >> } >> >> ... >> >> wsgi_app = pecan.Pecan( >> my_package.controllers.root.RootController(), >> hooks=[SpecialContextHook(SomeObj(1, 2, 3))] >> ) >> >> --- >> Ryan Petrello >> Senior Developer, DreamHost >> ryan.petre...@dreamhost.com >> >> On Mar 14, 2014, at 8:53 AM, Renat Akhmerov <rakhme...@mirantis.com> >> wrote: >> >> > Take a look at method get_pecan_config() in mistral/api/app.py. It's >> where you can pass any parameters into pecan app (see a dictionary >> 'cfg_dict' initialization). They can be then accessed via pecan.conf as >> described here: >> http://pecan.readthedocs.org/en/latest/configuration.html#application-configuration. >> If I understood the problem correctly this should be helpful. >> > >> > Renat Akhmerov >> > @ Mirantis Inc. >> > >> > >> > >> > On 14 Mar 2014, at 05:14, Dmitri Zimine <d...@stackstorm.com> wrote: >> > >> >> 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 <m4d.co...@gmail.com> 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#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 >> >> >> >> _______________________________________________ >> >> 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 >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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