+1 Hemanth.
On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi <[email protected]> wrote: > Hi, > > I believe that the API has been reviewed well both for its usecases and > correctness. And the blueprint has been approved after sufficient exposure > of the API in the community. The best way to enable users to adopt GBP is > to introduce this in Juno rather than as a project in StackForge. Just as > in other APIs any evolutionary changes can be incorporated, going forward. > > OS development processes are being followed in the implementation to make > sure that there is no negative impact on Neutron stability with the > inclusion of GBP. > > Thanks, > -hemanth > > > On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain <[email protected]> > wrote: > >> All- >> >> tl;dr >> >> * Group Based Policy API is the kind of experimentation we be should >> attempting. >> * Experiments should be able to fail fast. >> * The master branch does not fail fast. >> * StackForge is the proper home to conduct this experiment. >> >> >> Why this email? >> --------------- >> Our community has been discussing and working on Group Based Policy (GBP) >> for many months. I think the discussion has reached a point where we need >> to openly discuss a few issues before moving forward. I recognize that >> this discussion could create frustration for those who have invested >> significant time and energy, but the reality is we need ensure we are >> making decisions that benefit all members of our community (users, >> operators, developers and vendors). >> >> Experimentation >> ---------------- >> I like that as a community we are exploring alternate APIs. The process >> of exploring via real user experimentation can produce valuable results. A >> good experiment should be designed to fail fast to enable further trials >> via rapid iteration. >> >> Merging large changes into the master branch is the exact opposite of >> failing fast. >> >> The master branch deliberately favors small iterative changes over time. >> Releasing a new version of the proposed API every six months limits our >> ability to learn and make adjustments. >> >> In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental >> APIs. The results have been very mixed as operators either shy away from >> testing/offering the API or embrace the API with the expectation that the >> community will provide full API support and migration. In both cases, the >> experiment fails because we either could not get the data we need or are >> unable to make significant changes without accepting a non-trivial amount >> of technical debt via migrations or draft API support. >> >> Next Steps >> ---------- >> Previously, the GPB subteam used a Github account to host the >> development, but the workflows and tooling do not align with OpenStack's >> development model. I’d like to see us create a group based policy project >> in StackForge. StackForge will host the code and enable us to follow the >> same open review and QA processes we use in the main project while we are >> developing and testing the API. The infrastructure there will benefit us as >> we will have a separate review velocity and can frequently publish >> libraries to PyPI. From a technical perspective, the 13 new entities in >> GPB [1] do not require any changes to internal Neutron data structures. >> The docs[2] also suggest that an external plugin or service would work to >> make it easier to speed development. >> >> End State >> --------- >> APIs require time to fully bake and right now it is too early to know the >> final outcome. Using StackForge will allow the team to retain all of its >> options including: merging the code into Neutron, adopting the repository >> as sub-project of the Network Program, leaving the project in StackForge >> project or learning that users want something completely different. I >> would expect that we'll revisit the status of the repo during the L or M >> cycles since the Kilo development cycle does not leave enough time to >> experiment and iterate. >> >> >> mark >> >> [1] >> http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370 >> [2] >> https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078 >> [3] >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
