Though Code reviews for vendor code takes more time, I feel it must go through 
Core reviews.

Since, Vendors might submit the code that is working fine within their third 
party CI environment but the Code review make it more efficient with respect to 
the coding standards followed in the community.

Also, for all the vendor plugins/drivers the code reviews (+1s and +2s) give a 
feedback on the quality they must be in to be with Neutron.

But one suggestion I want to put forward, when an -1 or -2 is given to the 
code, Reviewers might give a brief comment on why this was given, what might be 
preferred solution and Is there any reference implementation that can be 
considered for the code in review to move away from these errors. This can help 
the developers.




--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048

From: Amit Das [mailto:amit....@cloudbyte.com]
Sent: Thursday, September 18, 2014 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: tanny...@huawei.com
Subject: Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third 
vendors' plugin and driver

+1
I don't think it will be seen as punitive. Vendors can write their plugins or 
drivers when a deal occurs and they do not need to submit code to community and 
wait for approving.

Being a third party vendor, i do not think this is punitive. OpenStack has 
already established through processes like cert tests via tempest, external CI, 
etc. However, waiting for months for reviews and some more days for next round 
of reviews is really disturbing.
Vendor plugins can always always provide repository links, cert tests, external 
CI logs, pep8 logs, flake8 logs, code coverage stats etc. to confirm if they 
are abiding by the OpenStack processes.


Regards,
Amit
CloudByte Inc.<http://www.cloudbyte.com/>

On Thu, Sep 18, 2014 at 9:56 AM, Germy Lure 
<germy.l...@gmail.com<mailto:germy.l...@gmail.com>> wrote:
Hi Salvatore,
Thanks for your hyperlink. It's really a monster thread that contains 
everyone's opinion. But it's useful to me.
So, Before we focus on the Neutron core itself, we should firstly release a 
suite standardized APIs and a framework for vendors' codes.
About this job, I think most of it is already OK. We have 20+ monolithic 
plugins following NB API and plugin framework.
We need publish an API doc for internal interface(I prefer to call it SB API, 
stand on the Neutron core's point to consider, vendors' codes
do not belong to core.) and other things unsuitable now.

In my opinion, the Neutron core's main responsibility is data model and DB, 
schedule and dispatch, API and validation, framework and workflow.

Some more comments inline.


This is a very important discussion - very closely related to the one going on 
in this other thread 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045768.html.
Unfortunately it is also a discussion that tends to easily fragment and move in 
a thousand different directions.
A few months ago I was too of the opinion that vendor plugins and drivers were 
the main reason of unnecessary load for the core team. I still think that 
they're an unnecessary heavy load, but I reckon the problem does not really 
lies with open source versus vendor code. It lies in matching people's 
competencies with subsystems and proper interface across them - as already 
pointed out in this thread.
Yes, it's really important.

I have some more comments inline, but unless growing another monster thread I'd 
rather start a different, cross-project discussion (which will hopefully not 
become just a cross-project monster thread!)

Salvatore

On 15 September 2014 08:29, Germy Lure 
<germy.l...@gmail.com<mailto:germy.l...@gmail.com>> wrote:
Obviously, to a vendor's plugin/driver, the most important thing is API.Yes?
NB API for a monolithic plugin or a service plugin and SB API for a service 
driver or agent, even MD. That's the basic.
Now we have released a set of NB APIs with relative stability. The SB APIs' 
standardization are needed.

The internal interface between the API and the plugins is standardized at the 
moment through use of classes like [1]. A similar interface exists for ML2 
drivers [2].
To the monolithic plugins, [1] is useful. Vendors can implement those APIs and 
keep their codes locally.

At the moment the dispatch of an API call to the plugin or from a plugin to a 
ML2 driver is purely a local call so these interfaces are working fairly well 
at the moment. I don't know yet however whether they will be sufficient in case 
plugins are split into different repos. ML2 Driver maintainers have however 
been warned in the past that the driver interface is to be considered internal 
and can be changed at any time. This does not apply to the plugin interface 
which has been conceived in this way to facilitate the development of out of 
tree plugins.
Indeed, it's difficult to split MDs from ML2 plugin framework. I think it need 
some adaption.

On the other hand, if by SB interfaces you are referring to the RPC interfaces 
for communicating between the servers and the various plugin, I would say that 
they should be considered internal at the moment.

[1] 
https://github.com/openstack/neutron/blob/master/neutron/neutron_plugin_base_v2.py#L28
[2] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py

Some comments inline.



On Fri, Sep 12, 2014 at 5:18 PM, Kevin Benton 
<blak...@gmail.com<mailto:blak...@gmail.com>> wrote:
> So my suggestion is remove all vendors' plugins and drivers except opensource 
> as built-in.

Yes, I think this is currently the view held by the PTL (Kyle) and some of the 
other cores so what you're suggesting will definitely come up at the summit.
Good!

The discussion however will not be that different from the one we're seeing on 
that huge thread on splitting out drivers, which has become in my opinion a 
frankenthread.
Nevertheless, that thread points out that this is far from being merely a 
neutron topic (despite neutron being the project with the highest number of 
drivers and plugins).



> Why do we need a different repo to store vendors' codes? That's not the 
> community business.
> I think only a proper architecture and normal NB&SB API can bring "a clear 
> separation between plugins(or drivers) and core code", not a different repo.

The problem is that that architecture won't stay stable if there is no shared 
community plugin depending on its stability. Let me ask you the inverse 
question. Why do you think the reference driver should stay in the core repo?

A separate repo won't have an impact on what is packaged and released so it 
should have no impact on "user experience", "complete versions", "providing 
code examples",  or "developing new features". In fact, it will likely help 
with the last two because it will provide a clear delineation between what a 
plugin is responsible for vs. what the core API is responsible for. And, 
because new cores can be added faster to the open source plugins repo due to a 
smaller code base to learn, it will help with developing new features by 
reducing reviewer load.
OK, the key point is that vendors' code should be kept by themselves NOT by the 
community. But in the same time, the community should provide
some open source reference as standard examples for those new cores and vendors.
U are right, "A separate repo won't have an impact on what is packaged and 
released". The open source can stays in the core repo or a different one.
In any case, we need them there for referencing and version releasing.
Any vendor would not maintain the open source codes, the community only.

I think that we are probably focusing too much on the "separate repo" issue, 
which is probably being seen as punitive for drivers and plugins.
The separate repo would be just a possible tool for achieving the goal of 
reducing the review load imposed by drivers on the core team while keeping them 
part of the integrated release.
I don't think it will be seen as punitive. Vendors can write their plugins or 
drivers when a deal occurs and they do not need to submit code to community
and wait for approving. The community dose not need to waste energy to review 
those codes.
If we must give a cause to keep vendors codes in the same or different repos, I 
think just installation-automatic. Similar to Linux kernel, user installs 
system on different hardware platform, and the system discovers the type of 
CPU, NIC, etc. and loads the right driver for that device. But OpenStack is not 
Linux, they are different.

Regarding the  "open source reference" solution... first there's no such thing 
like this. The fact that the upstream gate tests ML2 + OVS mech driver 
implicitly seem to make this the "reference", but this has not been sanctioned 
anywhere; second, the Neutron source tree does not just have a "reference 
plugin". It also has the DHCP agent, the OVS agent, the L3 agent, which 
implement also the management plane of a network virtualization system which 
uses OVS, iptables and other tools as its datapath. This is just for saying 
that when we talk about "splitting stuff from the main repo" there is more than 
just vendor plugin and drivers. It's more about giving control of subsystems to 
the people which are truly experts of that subsystem. I don't know whether 
splitting repositories would be the way to go.
Splitting into different repos is helpful to standardizing APIs. We can also 
split those agents into separate repo as sub modules. This is, I think, the 
next stage after vendors' codes splitting.

BR,
Germy

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to