Open Stack

+1 Hemanth.


On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi <hemanthraviml at gmail.com>
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 <mmcclain at yahoo-inc.com>
> 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/42d58e63/attachment.html>