On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter <zbit...@redhat.com> wrote:
> 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: > 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. > > - 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 >
__________________________________________________________________________ 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
