i was expeict that oslo.service would not be released as part of the eventlet removal
and instead would have been ported to not depend on eventlet.
i.e. have oslo.service perodici tasks just delegate to futurist
providing the same api with a diffent backend.
so i was kidn of surprised to see this topic come up.
I'll focus my answer only on that point ^.
We were not thinking of managing the oslo.service topic at the same time as the Eventlet removal, but unfortunately, both topics can be separated...
As oslo.service is heavily based on Eventlet, we can't touch one without touching the other.
We were thinking of giving orientation for replacement through deprecation messages and through guidance [1].
But, indeed, a binding to futurist and cotyledon through oslo.service could be an option. Indeed it would really simplify the migration, but on the other hand it will produce technical debt, which at term, risks to remain an undefined amount of time. If people feel comfortable using this binding, they won't have reasons to drop oslo.service in favor of futurist and cotyledon. They will continue using the binding...
But this side effect doesn't seem so terrible, it could be a credible scenario in the long term, so I don't think we should ignore that point.
But if we consider the benefits brought by such binding, this side effect could be surely ignored.
Indeed, on the other hand, such a kind of binding would be a good option to:
1. not have to internalize cotyledon into OpenStack. I'm personally more in favor of keeping Cotyledon as an independent deliverable as we did with Eventlet;
2. to host a wsgi binding (maybe based on flask) as an alternative to the Eventlet WSGI binding offered by oslo.service.
Maintaining the binding would allow us to monitor if Cotyledon needs help at some point.
Maintaining a binding would simplify the migration.
Maintaining a binding could merge the best of both worlds in many aspects.