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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
