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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
