On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote:
Hi,
Following the conversation [1]:
My understanding was that the way to use out of the tree vif_driver is to
set vif_driver option in nova.conf
until there is a better way to support such cases but the commit [2] removed
this
On 27/08/2014 17:06, Daniel P. Berrange wrote:
On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote:
Hi,
Following the conversation [1]:
My understanding was that the way to use out of the tree vif_driver is to
set vif_driver option in nova.conf
until there is a better way to support
: [openstack-dev] [nova] Configuring libivrt VIF driver
On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote:
Hi,
Following the conversation [1]:
My understanding was that the way to use out of the tree vif_driver
is
to set vif_driver option in nova.conf until there is a better way
Hi,
Following the conversation [1]:
My understanding was that the way to use out of the tree vif_driver is
to set vif_driver option in nova.conf
until there is a better way to support such cases but the commit [2]
removed this option.
Can someone clarify the current status (i.e. what is the
Hi,
I see that the option to specify vif_driver in nova.conf for libvirt is
deprecated for Juno release.
What is the way to use an external VIF driver (i.e. that is out of the
tree)?
Itzik
___
OpenStack-dev mailing list
On Wed, Jul 23, 2014 at 07:38:05PM +0300, Itzik Brown wrote:
Hi,
I see that the option to specify vif_driver in nova.conf for libvirt is
deprecated for Juno release.
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate the various
legacy VIF driver implementations in Nova, not remove the ability
to use 3rd party ones.
I'm pretty sure it was deprecated specifically for that reason.
On Wed, Jul 23, 2014 at 09:53:55AM -0700, Dan Smith wrote:
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate the various
legacy VIF driver implementations in Nova, not remove the ability
to use 3rd party ones.
I don't see an issue with allowing people to configure 3rd party impl
for the VIF driver, provided we don't claim that the VIF driver API
contract is stable, same way we don't claim virt driver API is stable.
It lets users have a solution to enable custom NIC functionality while
waiting for
On Wed, Jul 23, 2014 at 10:09:37AM -0700, Dan Smith wrote:
I don't see an issue with allowing people to configure 3rd party impl
for the VIF driver, provided we don't claim that the VIF driver API
contract is stable, same way we don't claim virt driver API is stable.
It lets users have a
If we're going to do that, then we should be consistent. eg there is
a volume_drivers parameter that serves the same purpose as
vif_driver
There are lots of them. We've had a bit of a background task running to
remove them when possible/convenient and try to avoid adding new ones.
I'm not
On Wed, Jul 23, 2014 at 10:52:54AM -0700, Dan Smith wrote:
If we're going to do that, then we should be consistent. eg there is
a volume_drivers parameter that serves the same purpose as
vif_driver
There are lots of them. We've had a bit of a background task running to
remove them when
On 23 July 2014 10:52, Dan Smith d...@danplanet.com wrote:
What is our story for people who are developing new network or
storage drivers for Neutron / Cinder and wish to test Nova ? Removing
vif_driver and volume_drivers config parameters would mean that they
would have to directly
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we arbitrarily change
it during development
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to
things that are not stable APIs and if they didn't already exist,
I'd not approve adding them. I'd actually go further and say not
even the virt driver API should be a plugin point, since we
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we
17 matches
Mail list logo
