> On Nov 3, 2016, at 11:27 AM, Joshua Harlow <harlo...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
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

Reply via email to