Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement independently of SCAB #13

Closed
gberche-orange opened this issue Jan 8, 2020 · 2 comments
Closed

Reimplement independently of SCAB #13

gberche-orange opened this issue Jan 8, 2020 · 2 comments

Comments

@gberche-orange
Copy link
Member

gberche-orange commented Jan 8, 2020

Expected behavior

As an osb-cmdb contributor, in order to develop new feature and maintain osb-cmdb, I expect the osb-cmdb contributions to be productive

Observed behavior

  • Effort required to handle Maintain stack, avoid SCAB fork (& changes lack automated test coverage) #6 is still important because

    • SCAB test strategy makes the test code base rigid and costly to evolve when introducing new features. This would sometimes require important refactoring to get new features in
    • The bar is too high w.r.t. our capacity in osb-cmdb
      • The expected test code coverage (unit test, component test with CF wiremocks, and acceptance test with live tests) is expensive
      • The static code analysis (pmd rules, checkstyle, compiler warnings) is strict
    • The osb-cmdb features don't seem to benefit much to SCAB to justify investment by SCAB maintainers
  • Osb-cmdb contributions within SCAB code base are slowed down by

    • Overhead of maintaining/not breaking SCAB features
      • not used in osb-cmdb:
        • app brokering
        • multiple service brokering
        • future K8S support
        • pluggeable workflows
      • seldomly used: configureable brokering (SpacePerServiceOffering vs SpacePerServicePlan)
      • conflicting requirements:
        • service instance update optimization
    • Full non blocking reactor style which are
      • adding boiler plate code
      • sometimes restrictive
      • hard to learn and master
      • whose benefits does not yet seem to leveraged for osb-cmdb use cases:
        • no (or few) parallel processing
        • no backpressure

Possible alternatives

  • Start from scratch

    • sc-osb
    • cf-java-client
  • Simplify current scab-based osb-cmdb spike ?

    • Remove unused features
    • Remove extra layers / modules
    • Keep focused component / acceptance tests

When to schedule

  • Now
  • Before CF V3 API migration
@gberche-orange
Copy link
Member Author

See design and prototype outline at https://gist.github.com/gberche-orange/69bb27be0bf07f7ada61c6b7342f9683 as an alternative to #6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants