On 24/04/15 19:02, Joe Gordon wrote:
On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco <fla...@redhat.com
<mailto:fla...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
