Open Stack

Hi,

When I think about Group-Based Policy I cannot help myself but think about
the degree of variety of sentiments (for lack of better words) that this
subject has raised over the past few months on the mailing list and/or
other venues.

I speak for myself when I say that when I look at the end-to-end
Group-Based Policy functionality I am not entirely sold on the following
points:

- The abstraction being proposed, its relationship with the Neutron API and
ODL;
- The way the reference implementation has been introduced into the
OpenStack world, and Neutron in particular;
- What an evolution of Group-Based Policy means going forward if we use the
proposed approach as a foundation for a more application-friendly and
intent-driven API abstraction going forward.
- The way we used development tools for bringing Neutron developers
(reviewers and committers), application developers, operators, and users
together around these new concepts.

Can I speak for everybody when I say that we do not have a consensus across
the board on all/some/other points being touched in this thread or other
threads? I think I can: I have witnessed that there is *NOT* such a
consensus. If I am asked where I stand, my position is that I wouldn't mind
to see how Group-Based Policy as we know it kick the tires; would I love to
see it do that in a way that's not disruptive to the Neutron project? YES,
I would love to.

So, where do we go from here? Do we need a consensus on such a delicate
area? I think we do.

I think Mark's intent, or anyone's who has at his/her heart the interest of
the Neutron community as a whole, is to make sure that we find a compromise
which everyone is comfortable with.

Do we vote about what we do next? Do we leave just cores to vote? I am not
sure. But one thing is certain, we cannot keep procrastinating as the Juno
window is about to expire.

I am sure that there are people hitching to get their hands on Group-Based
Policy, however the vehicle whereby this gets released should be irrelevant
to them; at the same time I appreciate that some people perceive Stackforge
projects as not as established and mature as other OpenStack projects; that
said wouldn't be fair to say that Group-Based Policy is exactly that? If
this means that other immature abstractions would need to follow suit, I
would be all in for this more decentralized approach. Can we do that now,
or do we postpone this discussion for the Kilo Summit? I don't know.

I realize that I have asked more questions than the answers I tried to
give, but I hope we can all engage in a constructive discussion.

Cheers,
Armando

PS: Salvatore I expressly stayed away from the GBP acronym you love so
much, so please read the thread and comment on it :)

On 4 August 2014 15:54, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:

> +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
>>
>>
>
> _______________________________________________
> 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/20140804/a824b771/attachment.html>