Open Stack

On 24/04/15 19:02, Joe Gordon wrote:
>
>
> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco <flavio at redhat.com
> <mailto:flavio at redhat.com>> wrote:
>
>     Greetings,
>
>     I'd like my first action as Zaqar's PTL to be based on reflections and
>     transparency with regards to what our past has been, to what our
>     present is and to what our future could be as a project and community.
>     Therefore, I'm sending this call for adoption and support before
>     taking other actions (also mentioned below).
>
>     The summit is very close and the Zaqar team is looking forward to it.
>
>     The upcoming summit represents an important opportunity for Zaqar to
>     integrate with other projects. In the previous summits - since
>
>
> I get integration with Horizon etc. But to use the SQS/SNS analogy how
> would say Nova integrate with Zaqar?

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.

So examples might be:
  - Hey, your resize is done
  - Hey, your [re]build is done
  - Hey, your VM rebooted
  - Hey, your VM disappeared

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.

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:

  - Hey Zaqar, give me a new queue/topic/whatever
  - Hey Mistral, run this workflow when you see a message on this topic
  - Hey Nova, send a message to this topic whenever my VM reboots

Bam, user-defined workflow triggered on VM reboot. (Super easy to set up 
in a Heat template BTW ;)

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.

I wrote a blog post earlier today about why all this is needed:

http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack

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.

cheers,
Zane.

>     Icehouse's - we've been collecting feedback from the community. We've
>     worked on addressing the many use-cases, we've worked on addressing
>     the concerns raised by the community and we've also kept moving
>     towards reaching the project's goals.
>
>     As you all know, the project has gone through many ups and downs.
>     We've had some "failures" in the past and we've also had successes, as
>     a project and as a team. Nevertheless, we've got to the point where it
>     doesn't make much sense to keep pushing new features to the project
>     until it gains adoption. Therefore, I'd like to take advantage of the
>     workshop slots and invite people from other projects to help us/guide
>     us through a hacking session on their projects so we can help with the
>     adoption. The current adoption of Zaqar consist in:
>
>     - 1 company reachingunning it in production
>     - 1 planning to do it soon
>     - RDO support
>
>     Unfortunately, the above is certainly not enough for a project to
>     succeed and it makes the time and effort spent on the project not
>     worth it. It's been more than 2 years since we kicked the project off
>     and it's time for it to show some results. The current problem seems
>     to be that many people want the project but no one wants to be the
>     first in adopting Zaqar (which kind of invalidates the premises of the
>     "Big tent").
>
>     In summary, this is a call for adoption before we call it a nice
>     adventure and ask for the project to be excluded from the OpenStack
>     organization based on the lack of adoption and contributions.
>
>     If you think it's worth it, speak up. Either way, thanks for the
>     support and for reading thus far.
>
>     On behalf of the Zaqar team,
>     Flavio
>
>     --
>     @flaper87
>     Flavio Percoco
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>