Open Stack

On Fri, Apr 24, 2015 at 5:05 PM, Zane Bitter <zbitter at redhat.com> wrote:

> 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:
>

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-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
>>
>>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/68298afc/attachment.html>