Open Stack

Just as a followup from the summit,

One of the sessions (the new lib one) had a few proposals:

https://etherpad.openstack.org/p/ocata-oslo-bring-ideas

And I wanted to try to get clear owners for each part (there was some 
followup work for each); so just wanted to start this email to get the 
thoughts going on what to do for next steps.

*A hash ring library*

So this one it feels like we need at least a tiny oslo-spec for and for 
someone to write down the various implementations, what they share, what 
they do not share (talking to swift, nova, ironic and others? to figure 
this out). I think alexis was thinking he might want to work through 
some of that but I'll leave it for him to chime in on that (or others 
feel free to also).

This one doesn't seem very controversial and the majority of the work is 
probably on doing some analysis of what exists and then picking a 
library name and coding that up, testing it, and then integrating 
(pretty standard).

*Failure capturing/formation/(de)serialization library*

This one I've just decided to push through, though more comments on the 
spec are always welcome @ https://review.openstack.org/#/c/229194/ the 
repo where I started just doing this work (while in the airports 
traveling back) is @ https://github.com/harlowja/failure

Ideally once that is in a slightly better state we should be able to 
start to converge the various (at least 3 similar kinds of 
implementations) to that one and ideally get less duplicated (or 
slightly same code) out of the various libraries and projects that have 
copied/recreated it.

Anyone desiring to help in that is more than welcome to jump in :)

*Next-gen oslo.service replacement*

This one may require a little more of a plan on how to make it work, but 
the gist is that medhi (and others) has created 
https://github.com/sileht/cotyledon which is a nice replacement for 
oslo.service that ceilometer is using (and others?) and the idea was to 
start to figure out how to move away from (or replace with?) 
olso.service with that library.

I'd like to see a spec with some of the details/thoughts on how that 
could be possible, what changes would still be needed. I think from that 
session that the following questions were raised:

- Can multiprocessing (or subprocess?) be used (instead of os.fork)
- What to do about windows?
- Is it possible to create a oslo.service compat layer that preserves 
the oslo.service API but uses cotyledon under the covers to smooth the 
transition/adoption of other projects to cotyledon
    - Perhaps in general we should write how an adoption could happen 
for a consuming project (maybe just writing down how ceilometer made the 
switch would be a good start, what issues were encountered, how they 
were resolved...)
- Something else that people forgot to write down in the etherpad here :-P

I think that was the majority of thoughts coming out of that session 
(there were a few others, but those were not especially loud and may 
have just been me rambling, ha). Anything I forgot feel free to add in :)

Whose in to make the above happen?!?!

-Josh