Open Stack

I would certainly be interested in dicussing this, though I'm not currently
signed up for the PTG.  Obviously this is close to my interests, and I see
Kevin's raised Gluon as the bogeyman (which it isn't trying to be).

Setting aside all the above talk about how we might do things for a moment:
to take one specific feature example, it actually took several /years/ to
add VLAN-aware ports to OpenStack.  This is an example of a feature that
doesn't affect or interest the vast majority of the user community, and
which is almost certainly not installed in the cloud you're currently
working on, and you probably have no intention of ever programming, and
which even had cross-vendor support.  It's useful and there are times that
you can't do without it; there were people ready to write the code.  So why
was it so very hard?


I hope we will all agree on these points:

- Neutron's current API of networks, subnets and ports is fine for what it
does.  We like it, we write apps using it, it doesn't need to change
- The backward compatibility and common understanding of Neutron's API is
paramount - applications should work everywhere, and should continue to
work as Neutron evolves
- Some people want to do different things with networks, and that doesn't
make them bad people
- What is important about APIs is that they are *not* tied to an
implementation or reinvented by every backend provider, but commonly agreed

This says we find pragmatic ways to introduce sane, consumable APIs for any
new thing we want to do, and perhaps we need a governance model around
ensuring that they are sane and resuable.  None of this says that every API
should fit neatly into the network/port/subnet model we have - it was
designed for, and is good at describing, L2 broadcast domains.  (Gluon,
specifically, is about solving exclusively the technical question of how to
introduce independent APIs, and not the governance one of how to avoid
proliferation.)

For any new feature, I would suggest that we fold it in to the current API
if it's widely useful and closely compatible with the current model.  There
are clearly cases where changing the current API in complex ways to serve
1% of the audience is not necessary and not helpful, and I think this is
where our problems arise.  And by 'the current API' I mean the existing
network/port/subnet model that is currently the only way to describe how
traffic moves from one port to another.  I do not mean 'we must start
another project' or 'we must have another endpoint'.

However, we should have a way to avoid affecting this API if it makes no
sense to put it there.  We should find a way of offering new forwarding
features without finding increasingly odd ways of making networks, ports
and subnets serve the purpose.  They were created to describe L2 overlays,
which is still mostly what they are used to do - to the point that the most
widely used plugin by far is the modular *L2* plugin.  It's hardly a
surprise that these APIs don't map to every possible networking setup in
the world.  My argument is that it's *sane* to want to invent quite
different APIs, it's not competition or dilution, and should we choose to
do so it's even a reasonable thing to do within Neutron's current framework.

I do not care if we make Neutron extensible in some different way to permit
this, if we start a new project or whatever, I just want it to happen. If
you think that the Gluon approach to this is the wrong way to make it
happen, and I'm seeing general consensus here that this could be done
within Neutron, then I welcome alternative suggestions.  But I do honestly
believe that we make our own pain by insisting on one API that must be
ridigly backward- and cross-compatible and simultaneously insisting that
all novel ideas be folded into it.
-- 
Ian.


On 25 January 2017 at 10:19, Sukhdev Kapur <sukhdevkapur at gmail.com> wrote:

> Folks,
>
> This thread has gotten too long and hard to follow.
> It is clear that we should discuss/address this.
> My suggestion is that we organize a session in Atlanta PTG meeting and
> discuss this.
>
> I am going to add this on the Neutron etherpad - should this be included
> in any other session as well?
>
> -Sukhdev
>
>
>
>
> On Tue, Jan 24, 2017 at 12:33 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
>
>> Hi team,
>>
>> I would like to propose my PTL candidacy for Pike.
>>
>> Some of you already know me. If not, here is my brief OpenStack bio. I
>> joined the community back in Havana, and managed to stick around till
>> now. During the time, I fit several project roles like serving as a
>> Neutron liaison of different kinds (stable, oslo, release), fulfilling
>> my Neutron core reviewer duties, taking part in delivering some
>> longstanding features, leading QoS and upgrades subteams, as well as
>> being part of Neutron Drivers team. I also took part in miscellaneous
>> cross project efforts.
>>
>> I think my experience gives me broad perspective on how the OpenStack
>> community and more specifically Networking works, and what is expected
>> from its PTL.
>>
>> First, let me describe my vision of PTL role.
>>
>> * It's not only about technical intricacies. It's also about people
>> and procedures that make the project run smoothly day by day. The role
>> of PTL is in empowering other team members, keeping track of any
>> roadblocks and inconveniences that the team have, and working on
>> streamlining workflow.
>>
>> * It's about delegation. We should make it a habit to look at the list
>> of potential candidates for core membership and other leadership and
>> administrative positions not just in times we are short on existing
>> members.
>>
>> * PTL should be transparent and replaceable. I will work with outgoing
>> PTL to capture oral wisdom and state of affairs into a publicly
>> accessible project dashboard, and I will continue sharing such
>> information with the team on constant basis. The project dashboard
>> will give you answers to questions like: what's the project direction?
>> what are current priorities, and where does each stand?  what's on PTL
>> and Drivers' mind? which cross-project and governance initiatives are
>> currently worked on? etc.
>>
>> As PTL, I'd like to focus on the following things:
>>
>> * Speed up the RFE/spec process. We should manage RFE/spec review
>> pipeline in such a way so that initiatives that are given a green
>> light on writing up design details get timely feedback and can get
>> past spec process in reasonable time.  At the same time we should be
>> honest to the community not to accept proposals that have high risk to
>> fall through cracks due to lack of manpower. I will encourage usage of
>> reviewday and other tools to keep focus of the team. We will mull over
>> the idea of virtual code sprints for high demand topics.
>>
>> * Continue Stadium program without drastic changes of direction.
>> Thanks to Armando, we filled the Stadium with tangible meaning. I want
>> us to build on top of that foundation to drive consistency and high
>> quality standards between participating projects.
>>
>> * Support Marketplace rework. With huge number of drivers and plugins
>> available for Neutron, it became hard for operators to pick the right
>> one and for vendors to advertise their features. There is strong
>> vendor interest to improve situation there. We should boost Feature
>> Classification work, and integrate it with how third party CI systems
>> report test results so that they become useful for Marketplace.
>>
>> * Introduce Gate Keeper role. We've recently made significant progress
>> in how we deal with gate: we expanded coverage to new types of jobs,
>> we utilize Grafana and other community tools, we review gate-failure
>> tagged bugs during weekly meetings. Sadly, sometimes gate becomes
>> unstable, and it slows down work progress for everyone.  In such
>> cases, it's all about timely addressing the issue. For that matter, I
>> will work with the team on defining a new Gate Keeper role that would
>> help prioritizing current gate issues, as well as proactively work
>> with the team on gate instability vectors. I believe clear ownership
>> is the key.
>>
>> * Make centralized L3 legacy indeed. We have DVR and HA in tree for
>> quite some time. Both technologies are now mature enough, and are no
>> longer mutually exclusive. Sadly, they are still second class citizens
>> in our own gate.  My belief is we should give users a clear signal
>> that old L3 is indeed legacy by switching our jobs to DVR+HA where
>> applicable.  I am sure that will surface some previously unknown
>> issues, but we'll be ready to tackle them.  While it's never black or
>> white, I suggest we prioritize this work over adding new major L3
>> features.
>>
>> * Support existing maintenance initiatives. I'd like us to close
>> neutron-lib saga in Pike, and consider neutron-lib switch for a
>> requirement to all Stadium projects starting from Queens. We should
>> also close OSC transition during Pike.
>>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>>
>> Now, you may ask, it's a nice list of things to do, but we can't
>> manage to handle all of that in one cycle, can we? Well, some of those
>> bullet points are procedural (RFE process tweaks, next Stadium steps,
>> Gate Keeper role) and, with team support, won't take too much time to
>> adopt (yes I am an optimist...), and hopefully will deliver the fruits
>> in the same cycle.
>>
>> As for technical bits, it's mostly ongoing work, and I am sure we will
>> still have time for other work that our bright contributors tend to
>> deliver. Also, it's in everyone's interest to get gate into better
>> shape,
>>
>> Of course, some of the goals are long stretching and may spill over
>> into next cycles. It's ok as long as we agree on the path. Do we?
>>
>> Thanks for attention,
>> Ihar
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20170125/35bcadd7/attachment.html>