On Thu, Aug 28, 2014 at 06:45:58AM +0300, Itzik Brown wrote:
>
> 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 i
pment Mailing List (not for usage questions)
> Subject: Re: [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
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 su
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
> t
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 cur
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 arbi
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 arbi
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, sin
> 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 developm
On 23 July 2014 10:52, Dan Smith 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 modify the exist
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 the
> 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 op
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 h
> 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 f
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
> 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 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 deprecat
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
OpenStack-dev@lists.opensta
18 matches
Mail list logo
