Open Stack

> On Nov 3, 2016, at 11:27 AM, Joshua Harlow <harlowja at fastmail.com> wrote:
> 
> 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).
> 

Ironic and Nova both share a hash ring implementation currently (ironic-conductor and nova-compute driver for ironic). It would be sensible to reuse this implementation, oslo-ify it, and have that code shared. 

I question the value of re-implementing something like this from scratch though.

Thanks,
Jay Faulkner
OSIC

> *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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev