Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
Sent from my iPad On 2014-12-16, at 下午2:54, "Armando M." wrote: > > > Good questions. I'm also looking for the linux bridge MD, SRIOV MD... > Who will be responsible for these drivers? > > Excellent question. In my opinion, 'technology' specific but not vendor > specific MD (like SRIOV) should not be maintained by specific vendor. It > should be accessible for all interested parties for contribution. > > I don't think that anyone is making the suggestion of making these drivers > develop in silos, but instead one of the objective is to allow them to evolve > more rapidly, and in the open, where anyone can participate. > > > The OVS driver is maintained by Neutron community, vendor specific hardware > driver by vendor, SDN controllers driver by their own community or vendor. > But there are also other drivers like SRIOV, which are general for a lot of > vendor agonitsc backends, and can't be maintained by a certain > vendor/community. > > Certain technologies, like the ones mentioned above may require specific > hardware; even though they may not be particularly associated with a specific > vendor, some sort of vendor support is indeed required, like 3rd party CI. > So, grouping them together under an hw-accelerated umbrella, or whichever > other name that sticks, may make sense long term should the number of drivers > really ramp up as hinted below. There are also MD not related with hardware, like via-tap, vif-vhostuser. Even for sriov, a stub agent for testing is enough, no need for real hardware. All these MD should be very thin, only handle port binding. > > > So, it would be better to keep some "general backend" MD in tree besides > SRIOV. There are also vif-type-tap, vif-type-vhostuser, > hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base > MD that only handle "vif bind" which is backend agonitsc, then backend > provider is free to implement their own service logic, either by an backend > agent, or by a driver derived from the base MD for agentless scenery. > > Keeping general backend MDs in tree sounds reasonable. > Regards > > > Many thanks, > > Neil > > > > ___ > > OpenStack-dev mailing list > > 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 > > ___ > OpenStack-dev mailing list > 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
Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
> > > > Good questions. I'm also looking for the linux bridge MD, SRIOV MD... > Who will be responsible for these drivers? > > Excellent question. In my opinion, 'technology' specific but not vendor > specific MD (like SRIOV) should not be maintained by specific vendor. It > should be accessible for all interested parties for contribution. > I don't think that anyone is making the suggestion of making these drivers develop in silos, but instead one of the objective is to allow them to evolve more rapidly, and in the open, where anyone can participate. > > The OVS driver is maintained by Neutron community, vendor specific > hardware driver by vendor, SDN controllers driver by their own community or > vendor. But there are also other drivers like SRIOV, which are general for > a lot of vendor agonitsc backends, and can't be maintained by a certain > vendor/community. > Certain technologies, like the ones mentioned above may require specific hardware; even though they may not be particularly associated with a specific vendor, some sort of vendor support is indeed required, like 3rd party CI. So, grouping them together under an hw-accelerated umbrella, or whichever other name that sticks, may make sense long term should the number of drivers really ramp up as hinted below. > > So, it would be better to keep some "general backend" MD in tree besides > SRIOV. There are also vif-type-tap, vif-type-vhostuser, > hierarchy-binding-external-VTEP ... We can implement a very thin in-tree > base MD that only handle "vif bind" which is backend agonitsc, then backend > provider is free to implement their own service logic, either by an backend > agent, or by a driver derived from the base MD for agentless scenery. > > Keeping general backend MDs in tree sounds reasonable. > Regards > > > Many thanks, > > Neil > > > > ___ > > OpenStack-dev mailing list > > 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 > > ___ > OpenStack-dev mailing list > 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
Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
On 15 December 2014 at 09:53, Neil Jerram
wrote:
>
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver _entirely_
> out of tree, so long as the vendor repository that provides the ML2
> mechanism driver does something like this to register their driver as a
> neutron.ml2.mechanism_drivers entry point:
>
> setuptools.setup(
> ...,
> entry_points = {
> ...,
> 'neutron.ml2.mechanism_drivers': [
> 'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
> ],
> },
> )
>
> (Please see
>
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f03789001c2139b16de85c
> for the complete change and detail, for the example that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and the
> vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
> - other than for the reference OVS driver, are there any reasons in
> principle for keeping _any_ ML2 mechanism driver code in tree?
>
The approach you outlined is reasonable, and new plugins/drivers, like
yours, may find it easier to approach Neutron integration this way.
However, to ensure a smoother migration path for existing plugins and
drivers, it was deemed more sensible to go down the path being proposed in
the spec referenced above.
>
> Many thanks,
> Neil
>
> ___
> OpenStack-dev mailing list
> 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
Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
But then, is this decomposition is for the ML2 MDs or for all vendor specific
plugins/drivers in all the sub divisions around neutron?
Any comments on the same.
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: Irena Berezovsky [mailto:ire...@mellanox.com]
Sent: Tuesday, December 16, 2014 12:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: henry4...@gmail.com
Subject: Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron
decomposition change
-Original Message-
From: henry hly [mailto:]
Sent: Tuesday, December 16, 2014 3:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron
decomposition change
On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram wrote:
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver
> _entirely_ out of tree, so long as the vendor repository that provides
> the ML2 mechanism driver does something like this to register their
> driver as a neutron.ml2.mechanism_drivers entry point:
>
> setuptools.setup(
> ...,
> entry_points = {
> ...,
> 'neutron.ml2.mechanism_drivers': [
> 'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
> ],
> },
> )
>
> (Please see
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f0378900
> 1c2139b16de85c for the complete change and detail, for the example
> that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and
> the vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
>
> - other than for the reference OVS driver, are there any reasons in
> principle for keeping _any_ ML2 mechanism driver code in tree?
>
Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
Who will be responsible for these drivers?
Excellent question. In my opinion, 'technology' specific but not vendor
specific MD (like SRIOV) should not be maintained by specific vendor. It should
be accessible for all interested parties for contribution.
The OVS driver is maintained by Neutron community, vendor specific hardware
driver by vendor, SDN controllers driver by their own community or vendor. But
there are also other drivers like SRIOV, which are general for a lot of vendor
agonitsc backends, and can't be maintained by a certain vendor/community.
So, it would be better to keep some "general backend" MD in tree besides SRIOV.
There are also vif-type-tap, vif-type-vhostuser,
hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base
MD that only handle "vif bind" which is backend agonitsc, then backend provider
is free to implement their own service logic, either by an backend agent, or by
a driver derived from the base MD for agentless scenery.
Keeping general backend MDs in tree sounds reasonable.
Regards
> Many thanks,
> Neil
>
> ___
> OpenStack-dev mailing list
> 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
___
OpenStack-dev mailing list
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
Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
-Original Message-
From: henry hly [mailto:]
Sent: Tuesday, December 16, 2014 3:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron
decomposition change
On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram wrote:
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver
> _entirely_ out of tree, so long as the vendor repository that provides
> the ML2 mechanism driver does something like this to register their
> driver as a neutron.ml2.mechanism_drivers entry point:
>
> setuptools.setup(
> ...,
> entry_points = {
> ...,
> 'neutron.ml2.mechanism_drivers': [
> 'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
> ],
> },
> )
>
> (Please see
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f0378900
> 1c2139b16de85c for the complete change and detail, for the example
> that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and
> the vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
>
> - other than for the reference OVS driver, are there any reasons in
> principle for keeping _any_ ML2 mechanism driver code in tree?
>
Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
Who will be responsible for these drivers?
Excellent question. In my opinion, 'technology' specific but not vendor
specific MD (like SRIOV) should not be maintained by specific vendor. It should
be accessible for all interested parties for contribution.
The OVS driver is maintained by Neutron community, vendor specific hardware
driver by vendor, SDN controllers driver by their own community or vendor. But
there are also other drivers like SRIOV, which are general for a lot of vendor
agonitsc backends, and can't be maintained by a certain vendor/community.
So, it would be better to keep some "general backend" MD in tree besides SRIOV.
There are also vif-type-tap, vif-type-vhostuser,
hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base
MD that only handle "vif bind" which is backend agonitsc, then backend provider
is free to implement their own service logic, either by an backend agent, or by
a driver derived from the base MD for agentless scenery.
Keeping general backend MDs in tree sounds reasonable.
Regards
> Many thanks,
> Neil
>
> ___
> OpenStack-dev mailing list
> 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change
On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram wrote:
> Hi all,
>
> Following the approval for Neutron vendor code decomposition
> (https://review.openstack.org/#/c/134680/), I just wanted to comment
> that it appears to work fine to have an ML2 mechanism driver _entirely_
> out of tree, so long as the vendor repository that provides the ML2
> mechanism driver does something like this to register their driver as a
> neutron.ml2.mechanism_drivers entry point:
>
> setuptools.setup(
> ...,
> entry_points = {
> ...,
> 'neutron.ml2.mechanism_drivers': [
> 'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
> ],
> },
> )
>
> (Please see
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f03789001c2139b16de85c
> for the complete change and detail, for the example that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and the
> vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
>
> - other than for the reference OVS driver, are there any reasons in
> principle for keeping _any_ ML2 mechanism driver code in tree?
>
Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
Who will be responsible for these drivers?
The OVS driver is maintained by Neutron community, vendor specific
hardware driver by vendor, SDN controllers driver by their own
community or vendor. But there are also other drivers like SRIOV,
which are general for a lot of vendor agonitsc backends, and can't be
maintained by a certain vendor/community.
So, it would be better to keep some "general backend" MD in tree
besides SRIOV. There are also vif-type-tap, vif-type-vhostuser,
hierarchy-binding-external-VTEP ... We can implement a very thin
in-tree base MD that only handle "vif bind" which is backend agonitsc,
then backend provider is free to implement their own service logic,
either by an backend agent, or by a driver derived from the base MD
for agentless scenery.
Regards
> Many thanks,
> Neil
>
> ___
> OpenStack-dev mailing list
> 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
