Open Stack

Excerpts from Flavio Percoco's message of 2015-05-26 01:28:06 -0700:
> Greetings,
> 
> TL;DR: Thanks everyone for your feedback. Based on the discussed plans
> at the summit - I'll be writing more about these later - Zaqar will
> stick around and play its role in the community.
> 
> Summit Summary
> ==============
> 
> I'm happy to say that several use cases were discussed at the summit
> and the difference from previous summits is that we left the room with
> some action items to make them happen.
> 
> Cross-project user-facing notifications
> =======================================
> 
> https://etherpad.openstack.org/p/liberty-cross-project-user-notifications
> 
> Besides brainstorming a bit on what things should/should not be
> notified and what format should be used, we also talked a bit about
> the available technologies that could be used for this tasks. Zaqar
> was among those and, AFAICT, at the end of the session we agreed on
> giving this a try. It'll likely not happen as fast as we want but the
> action item out of this session was to write a cross-project spec
> describing the things discussed and the technology that will be
> adopted.
> 

My takeaway from that session was that there's need for something
like yagi to filter the backend notifications into user-consumable
tenant-scoped messages, and that Zaqar would be an interesting target for
those messages along with Atom feeds or perhaps other pub/sub oriented
things that deployers would be comfortable hosting for their users.

> Heat + Zaqar
> ============
> 
> The 2 main areas where Zaqar will be used in Heat are Software Config
> and Hooks. The minimum requirements (server side) for this are in
> place already. There's some work to do on the client side that the
> team will get to asap.
> 

The bigger one to me is just user-notificiation which I think is covered
in the cross project session, but it's worth noting that Heat is one
of the projects that already does some user notification and suffers
problems because of it (the events API is what I mean here).

> Next Steps
> ==========
> 
> In light of the above, and as mentioned in the TL;DR, Zaqar will stick
> around and the team, as promised, will focus on making those
> integrations happen. The team is small, which means we'll carefully
> pick the tasks we'll be spending time on.
> 
> As a first step, we should restore our meetings and get to work right
> away. To favor our contributors in NZ, next week's meeting will be at
> 21:00 UTC and we'll keep it at that time for 2 weeks.
> 
> For the Zaqar team (and folks interested), I'll be sending out further
> emails to sync on the work to do.
> 
> Special thanks for all the folks that showed interest, participated in
> sessions and that are committed on making this happen.
> 

Thanks for setting things up for success before the summit. I think we
all went into the discussions with an open mind because we knew where
the team stood.


== Crazy idea section ==

One thing I never had a chance to discuss with any of the Zaqar devs that
I would find interesting is an email-only backend for Zaqar. Basically
make Zaqar an HTTP-to-email gateway. There are quite a few hyper-scale
options for SMTP and IMAP, and they're inherently multi-tenant, so I'd
find it interesting to see if the full Zaqar API could be mapped onto
that. This would probably be more comfortable to scale for some deployers
than Redis or MongoDB, and might have the nice side-effect that a deployer
could expose IMAP IDLE for efficient end-user subscription, and it could
also allow Zaqar to serve as email-as-a-service for senders too (to
prevent getting all your vms' IPs added to spam lists overnight. ;)