<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24/04/15 19:02, Joe Gordon wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco <<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>>> wrote:<br>
<br>
    Greetings,<br>
<br>
    I'd like my first action as Zaqar's PTL to be based on reflections and<br>
    transparency with regards to what our past has been, to what our<br>
    present is and to what our future could be as a project and community.<br>
    Therefore, I'm sending this call for adoption and support before<br>
    taking other actions (also mentioned below).<br>
<br>
    The summit is very close and the Zaqar team is looking forward to it.<br>
<br>
    The upcoming summit represents an important opportunity for Zaqar to<br>
    integrate with other projects. In the previous summits - since<br>
<br>
<br>
I get integration with Horizon etc. But to use the SQS/SNS analogy how<br>
would say Nova integrate with Zaqar?<br>
</span></blockquote>
<br>
Speaking very generally, anything where it makes sense for Nova to tell the user - or, more importantly, the application - when something is happening. The cloud can't afford to be making synchronous calls to the client-side, and applications may not be able to afford missing the notifications, so a reliable, asynchronous transport like Zaqar is a good candidate.<br>
<br>
So examples might be:<br>
 - Hey, your resize is done<br>
 - Hey, your [re]build is done<br>
 - Hey, your VM rebooted<br>
 - Hey, your VM disappeared<br>
<br>
Now, this is not to presuppose that having Nova put messages directly into Zaqar is the correct design. It may be that it's better to have some other service (Ceilometer?) collect some or all of those notifications and handle putting them into Zaqar (though the reliability would be a concern). Certainly EC2 seems to funnel all this stuff to CloudWatch, although other services like S3, CloudFormation & Auto Scaling deliver notifications to SNS directly. There is some integration work either way though, to produce the notification.<br>
<br>
Obviously there's less integration to do for a project like Nova that only produces notifications than there would be for those that could actually consume notifications. Heat would certainly like to use these notifications to reduce the amount of polling we do of the APIs (and ditch it altogether if reliability is guaranteed). But if we can get both ends integrated then the *user* can start doing really interesting things like:<br></blockquote><div><br></div><div>This is one of the bigger questions for me, as a nova developer. What would integration look like from Nova's POV.  I am a little weary of adding yet another API when we have so much trouble with our existing ones.  Especially the notification based API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 - Hey Zaqar, give me a new queue/topic/whatever<br>
 - Hey Mistral, run this workflow when you see a message on this topic<br>
 - Hey Nova, send a message to this topic whenever my VM reboots<br>
<br>
Bam, user-defined workflow triggered on VM reboot. (Super easy to set up in a Heat template BTW ;)<br>
<br>
It gets even cooler when there are multiple producers and consumers: imagine that Ceilometer alarms and all other kinds of notifications in OpenStack are produced this way, and that SNS-style notifications, Heat autoscaling events and Mistral workflows can all be triggered by them. And of course if the logic available in the workflow isn't sufficient, the user can always insert their own conditioning logic running in a VM (future: container), since the flow is through a user-facing messaging system.<br>
<br>
I wrote a blog post earlier today about why all this is needed:<br>
<br>
<a href="http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack" target="_blank">http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack</a><br>
<br>
tl;dr: many applications being written now and even more in the future will expect to be able to interact with their own infrastructure and will go to proprietary clouds if we don't provide an open source alternative.<br>
<br>
cheers,<br>
Zane.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
    Icehouse's - we've been collecting feedback from the community. We've<br>
    worked on addressing the many use-cases, we've worked on addressing<br>
    the concerns raised by the community and we've also kept moving<br>
    towards reaching the project's goals.<br>
<br>
    As you all know, the project has gone through many ups and downs.<br>
    We've had some "failures" in the past and we've also had successes, as<br>
    a project and as a team. Nevertheless, we've got to the point where it<br>
    doesn't make much sense to keep pushing new features to the project<br>
    until it gains adoption. Therefore, I'd like to take advantage of the<br>
    workshop slots and invite people from other projects to help us/guide<br>
    us through a hacking session on their projects so we can help with the<br>
    adoption. The current adoption of Zaqar consist in:<br>
<br>
    - 1 company reachingunning it in production<br>
    - 1 planning to do it soon<br>
    - RDO support<br>
<br>
    Unfortunately, the above is certainly not enough for a project to<br>
    succeed and it makes the time and effort spent on the project not<br>
    worth it. It's been more than 2 years since we kicked the project off<br>
    and it's time for it to show some results. The current problem seems<br>
    to be that many people want the project but no one wants to be the<br>
    first in adopting Zaqar (which kind of invalidates the premises of the<br>
    "Big tent").<br>
<br>
    In summary, this is a call for adoption before we call it a nice<br>
    adventure and ask for the project to be excluded from the OpenStack<br>
    organization based on the lack of adoption and contributions.<br>
<br>
    If you think it's worth it, speak up. Either way, thanks for the<br>
    support and for reading thus far.<br>
<br>
    On behalf of the Zaqar team,<br>
    Flavio<br>
<br>
    --<br>
    @flaper87<br>
    Flavio Percoco<br>
<br>
    __________________________________________________________________________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div></div>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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><span class=""><br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</div></div></blockquote></div><br></div></div>