<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 9:59 AM, Serg Melikyan <span dir="ltr"><<a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font face="arial, sans-serif">Doug, thank you for your response! </font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">With moving to </font><i style="font-family:arial,sans-serif">oslo.messaging </i><font face="arial, sans-serif">I think we need to carefully re-evaluate our communication patterns and try to either fit them to RPC/Notification, or work on extending </font><i style="font-family:arial,sans-serif">oslo.messaging </i><span style="font-family:arial,sans-serif">with </span><font face="arial, sans-serif">some new ideas</font><font face="arial, sans-serif">. Adopting a new library is always a challenge.</font></div>
</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That makes sense.</div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="im"><div>><span style="font-family:arial,sans-serif">The RPC modules expect a response and provide timeout behavior, but the notifications don't require that. Perhaps you could send those messages as notifications?</span></div>
</div><div><font face="arial, sans-serif">Yes, notifications can be used as replacement to sending messages, but I think this may be even broken design than try to replace messaging with RPC without actual communications re-design.</font></div>
<div class="im">
<div><br></div>><span style="font-family:arial,sans-serif">The library is meant to be reusable, so if the API does not support your use case please work with us to extend it rather than hacking around it or forking it</span></div>
<div>
<span style="font-family:arial,sans-serif">Sure, I</span><span style="font-family:arial,sans-serif"> have no intents to hack/change/extend/fork anything related to </span><span style="font-family:arial,sans-serif">oslo.messaging </span><span style="font-family:arial,sans-serif">without consulting with oslo team first. I understand that making tools used by OpenStack better is very important to all of us.</span></div>
</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">OK, great!</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><span style="font-family:arial,sans-serif">When talked about 'hacking' </span><span style="font-family:arial,sans-serif">I had in mind a quick way to move to <i>oslo.messaging</i> without losing any of existing functionality. </span><span style="font-family:arial,sans-serif">Since oslo.messaging meant to hide away underlying implementation and message queue related things I am not sure that adding such specific thing as queue-ttl for selected queues without extending some classes from driver layer is possible.</span></div>
</div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">As long as we can find a way to make it backwards-compatible, for the projects that don't use the feature, I don't see a problem in principle. Experimenting within the Murano repository maybe the easiest way to work out what those APIs need to be. I'm glad to hear you would contribute that work back upstream, though. :-)</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><span style="font-family:arial,sans-serif"><br></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 6:06 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Tue, Feb 11, 2014 at 8:05 AM, Serg Melikyan <span dir="ltr"><<a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><a href="http://github.com/openstack/oslo.messaging" target="_blank">oslo.messaging</a> is a library that provides RPC and Notifications API, they are part of the same library for mostly historical reasons. One of the major goals of <i>oslo.messaging</i> is to provide clean RPC and Notification API without any trace of messaging queue concepts (but two of most advanced drivers used by oslo.messaging is actually based on AMQP: RabbitMQ and QPID). </div>
</div><div><br></div><div><div>We were designing Murano on messaging queue concepts using some AMQP/RabbitMQ specific features, like queue TTL. Since we never considered communications between our components in terms of RPC or Notifications and always thought about them as message exchange through broker it has influenced our components architecture. In Murano we use <a href="https://github.com/stackforge/murano-common/tree/master/muranocommon/messaging" target="_blank">simple wrapper</a> around <a href="https://github.com/majek/puka" target="_blank">Puka</a> (RabbitMQ client with most simple and thoughtful async model) that is used in all our components. We <a href="https://github.com/istalker2/puka" target="_blank">forked Puka</a> since we had specific requirements to SSL and could not yet merge <a href="https://github.com/majek/puka/pull/43" target="_blank">our work</a> back to master.</div>
</div><div><br></div><div>Can we abandon our <a href="https://github.com/stackforge/murano-common/tree/master/muranocommon/messaging" target="_blank">own wrapper</a> around our <a href="https://github.com/istalker2/puka" target="_blank">own fork of Puka</a> in favor of <i>oslo.messaging</i>? <i style="font-weight:bold">Yes</i>, but this migration may be tricky. I believe we can migrate to <i>oslo.messaging</i> in a week or so<i>.</i> </div>
<div><br></div><div>I had played with <i>oslo.messaging</i> emulating our current communication patterns with <i>oslo.messaging</i>, and I am certain that current implementation can be migrated to <i>oslo.messaging</i><i>. </i>But I am not sure that <i>oslo.messaging</i> may be easily suited to all future use-cases that we plan to cover in a few next releases without major contributions. Please, try to respond with any questions related to <i>oslo.messaging</i> implementation and how it can be fitted with certain use-case.</div>
<div><br></div><div>Below, I tried to describe our current use-cases and what specific MQ features we are using, how they may be implemented with <i>oslo.messaging </i>and with what limitations we will face. </div><div><br>
</div><div><font size="4">Use-Case</font></div>
<div>Murano has several components with communications between them based on messaging queue:<br></div><div><b>murano-api</b> -> <b>murano-conductor:</b> <br></div><div><ol><li><i>murano-api</i> sends deployment tasks to murano-conductor<br>
</li></ol></div><div><b>murano-conductor</b> -> <b>murano-api:</b></div><div><ol><li><i>murano-conductor</i> reports to <i>murano-api</i> task progress during processing<br></li><li>after processing, <i>murano-conductor</i> sends results to <i>murano-api</i><br>
</li></ol></div><div><b>murano-conductor </b>-><b> murano-agent:</b></div><div><ol><li>during task processing <i>murano-conductor</i> sends execution plans with commands to <i>murano-agent.</i> <br></li></ol><div>Note: each of mentioned components above may have more than one instance.</div>
</div><div><br></div><div>One of great messaging queue specific that we heavily use is a idea of queue itself, messages sent to component will be handled any time soon as at least one instance would be started. For example, in case of <i>murano-agent</i>, message is sent even before <i>murano-agent</i><b> </b>is started. Another one is queue life-time, we control life-time of <i>murano-agent</i> queues to exclude overflow of MQ server with queues that is not used anymore. </div>
<div><br></div><div>One thing is also worse to mention: <i>murano-conductor</i> communicates with several components at the same time: process several tasks at the same time, during task processing <i>murano-conductor</i> sends progress notifications to <i>murano-api</i> and execution plans to <i>murano-agent</i>. </div>
<div><br></div><div><font size="4">Implementation</font></div><div>Please, refer to <a href="https://wiki.openstack.org/wiki/Oslo/Messaging#Concepts" target="_blank">Concepts</a> section of <i>oslo.messaging</i> Wiki before further reading to grasp key concepts expressed in <i>oslo.messaging</i> library. In short, using RPC API we can 'call' server synchronously and receive some result, or 'cast' asynchronously (no result is returned). Using Notification API we can send Notification to the specified Target about happened event with specified event_type, importance and payload.</div>
<div><br></div><div>If we move to <i>oslo.messaging</i> we can only primarily rely on features provided by RPC/Notifications model:</div><div><ol><li>We should not rely on message delivery without other side is properly up and running. It is not a message delivery, it is <i>Remote Procedure Call;</i></li>
</ol></div></div></blockquote></div><div><div style="font-size:small">The RPC modules expect a response and provide timeout behavior, but the notifications don't require that. Perhaps you could send those messages as notifications?</div>
<br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li><br>
</li><li>To control queue life-time as we do now, we may be required to 'hack' <b>oslo.messaging</b> by writing own driver.<br></li></ol></div></div></blockquote></div><div><div style="font-size:small">
The library is meant to be reusable, so if the API does not support your use case please work with us to extend it rather than hacking around it or forking it.</div><br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><ol><li></li></ol></div><div><div><b>murano-api</b> -> <b>murano-conductor:</b> <br></div>
<div>
<ol><li><i>murano-api</i> sends deployment tasks to murano-conductor: <i>May be replaced with RPC Cast</i><br></li></ol></div><div><b>murano-conductor</b> -> <b>murano-api:</b></div><div><ol><li><i>murano-conductor</i> reports to <i>murano-api</i> task progress during processing: <i>May be replaced with Notification</i> or <i>RPC Cast</i></li>
</ol></div></div></div></blockquote></div><div style="font-size:small">Progress updates fit the notifications pattern nicely.</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><ol><li><br>
</li><li>after processing, <i>murano-conductor</i> sends results to <i>murano-api: </i><i>May be replaced with RPC Cast</i><br></li></ol></div><div><b>murano-conductor </b>-><b> murano-agent:</b></div><div><ol><li>during task processing <i>murano-conductor</i> sends execution plans with commands to <i>murano-agent</i>: <i>May be replaced with two way RPC Cast</i> (murano-agent Cast to murano-conductor with message like 'I am running', than murano-conductor Call to murano-agent with execution plan)</li>
</ol><div>Our code going to be became less clean and readable with moving to <i>oslo.messaging</i> since code that received or sends message will need to be replaced with many servers/clients and so. Communications with <i>murano-agent</i> would became more failure in-tolerant. On other hand <i>oslo.messaging </i>has very simple <a href="https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_drivers/base.py" target="_blank">Base API</a>, so we always may implement own driver with all required functionality (and underlying tricky implementations), but I think this is should be a last resort.</div>
</div></div></div></blockquote><div><br></div></div><div><div style="font-size:small">The drivers in oslo.messaging are meant to support different platforms for delivering messages, rather than message delivery semantics. If you need different semantics, extending the higher-level API to support them, and adding what is needed to the driver layer, will allow deployers to continue to choose their deployment platforms without being locked into a particular type of broker or protocol.</div>
<div style="font-size:small"><br></div><div style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr"><div><div><span><font color="#888888">
</font></span></div></div><span><font color="#888888"><div><br></div><div>-- <br><div dir="ltr">
<div>Serg Melikyan, Senior Software Engineer at Mirantis, Inc.<br></div><div><a href="http://mirantis.com/" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a><br>
<div><br><a href="tel:%2B7%20%28495%29%C2%A0640-4904" value="+74956404904" target="_blank">+7 (495) 640-4904</a>, 0261</div><div><a href="tel:%2B7%20%28903%29%20156-0836" value="+79031560836" target="_blank">+7 (903) 156-0836</a></div>
</div></div>
</div></font></span></div>
<br></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Serg Melikyan, Senior Software Engineer at Mirantis, Inc.<br></div><div><a href="http://mirantis.com/" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com" target="_blank">smelikyan@mirantis.com</a><br>
<div><br><a href="tel:%2B7%20%28495%29%C2%A0640-4904" value="+74956404904" target="_blank">+7 (495) 640-4904</a>, 0261</div><div><a href="tel:%2B7%20%28903%29%20156-0836" value="+79031560836" target="_blank">+7 (903) 156-0836</a></div>
</div></div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>