> 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