Open Stack

On 25/08/14 05:21, Thierry Carrez wrote:
> Zane Bitter wrote:
>> [...]
>> Here are a few of the conclusions:
>>
>> * Everyone wishes the Design Summit worked like this.
>> The meetup seemed a lot more productive than the design summit ever is.
>> It's really nice to be in a room small enough that you can talk normally
>> and hear everyone, instead of in a room designed for 150 people. It's
>> really nice to be able to discuss stuff that isn't related to a
>> particular feature - we had a long discussion about how to get through
>> the review backlog, for example. It's really nice to not have fixed time
>> slots for discussions - because everyone was in the room the whole time,
>> we could dip in and out of different topics at will. Often we came back
>> to one that we'd previously discussed because we had discovered new
>> information. Finally, it's critical to be in a room covered in
>> full-sized whiteboards that everyone can see. A single tiny flip chart
>> doesn't cut it.
>
> That's good feedback, thanks. The current discussion on design summit
> format changes is a bit lost under a Nova thread, so I should revive it
> as a separate thread very soon. The idea being to implement whatever
> changes we can to the summit to make it more productive (in the limited
> remaining time and options we have for that).

Yeah, I have been following that thread too. It's a hard problem, 
because obviously the ability to talk to developers from other projects 
and users at the design summit is _also_ valuable... we need to find a 
way to somehow make both happen, preferably without making everyone 
travel 4 times a year or for more than a week at a time.

>> [...]
>> * Marc^W Zaqar is critical to pretty much every major non-Convergence
>> feature on the roadmap.
>> We knew that we wanted to use it for notifications, but we also want to
>> make those a replacement for events, and a conduit for warnings and
>> debugging information to the user. This is becoming so important that
>> we're going to push ahead with an implementation now without waiting to
>> see when Zaqar will graduate. Zaqar would also be a good candidate for
>> pushing metadata changes to servers, to resolve the performance issues
>> currently caused by polling.
>
> Could you expand on that ? Do you need some kind of user-facing queue
> service, or is there something in the marc^WZaqar approach that makes it
> especially appealing ?

Basically we just need a user-facing queue service. The key drivers are 
the need for:
1) an asynchronous way of talking back to the user
2) a central service optimised for polling by the user, so that other 
services (like Heat) can move to a push model
3) a way of passing notifications between OpenStack services that the 
user can intercept and process if they choose (e.g. we already use 
user-defined webhooks to communicate from Ceilometer to autoscaling in 
Heat so that users can interpose their own alarm conditioning, but this 
has authentication issues and the potential to turn Ceilometer into a 
DOS engine)

Zaqar is a more-than-adequate-seeming implementation of those 
requirements that is already incubated.

Ideally it will also support SNS-style push notifications to the user, 
but that's more the user's problem than Heat's ;) We just want people to 
stop polling us, because it's killing our performance.

cheers,
Zane.