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
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
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.
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
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:
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
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
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
- I can write a method in base test to start local executor. I will do
that as a separate bp.
- 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
I want to propose the following changes to implement the local executor and
removal of the local engine. As mentioned before, oslo.messaging includes
a fake driver that uses a simple queue. An example in the use of this
fake driver is demonstrated in test_executor. The use of the fake driver
On 12 Mar 2014, at 06:37, W Chan m4d.co...@gmail.com wrote:
Here're the proposed changes.
1) Rewrite the launch script to be more generic which contains option to
launch all components (i.e. API, engine, executor) on the same process but
over separate threads or launch each individually.
Thanks. I will do that today and follow up with a description of the
proposal.
On Mon, Feb 24, 2014 at 10:21 PM, Renat Akhmerov rakhme...@mirantis.comwrote:
In process is fine to me.
Winson, please register a blueprint for this change and put the link in
here so that everyone can see what
As I understand, the local engine runs the task immediately whereas the
scalable engine sends it over the message queue to one or more executors.
In what circumstances would we see a Mistral user using a local engine
(other than testing) instead of the scalable engine?
If we are keeping the
On 25 Feb 2014, at 07:12, W Chan m4d.co...@gmail.com wrote:
As I understand, the local engine runs the task immediately whereas the
scalable engine sends it over the message queue to one or more executors.
Correct.
In what circumstances would we see a Mistral user using a local engine
I agree with Winson's points. Inline.
On Feb 24, 2014, at 8:31 PM, Renat Akhmerov rakhme...@mirantis.com wrote:
On 25 Feb 2014, at 07:12, W Chan m4d.co...@gmail.com wrote:
As I understand, the local engine runs the task immediately whereas the
scalable engine sends it over the message
“In process” is fine to me.
Winson, please register a blueprint for this change and put the link in here so
that everyone can see what it all means exactly. My feeling is that we can
approve and get it done pretty soon.
Renat Akhmerov
@ Mirantis Inc.
On 25 Feb 2014, at 12:40, Dmitri Zimine
16 matches
Mail list logo
