Hi all,
On Wed, Mar 04, 2015 at 10:52:10AM -0330, Brent Eagles wrote:
> Hi all,
> > Thanks Maxime. I've made some updates to the etherpad.
> > (https://etherpad.openstack.org/p/nova_vif_plug_script_spec)
> > I'm going to start some proof of concept work these evening. If I get
> > anything wor
Hi all,
On Wed, Feb 18, 2015 at 04:12:11PM -0330, Brent Eagles wrote:
> Hi,
> Thanks Maxime. I've made some updates to the etherpad.
> (https://etherpad.openstack.org/p/nova_vif_plug_script_spec)
> I'm going to start some proof of concept work these evening. If I get
> anything worth reading, I
So are we talking about using script to eliminate unnecessary new vif types?
Then, a little confusion that why this BP[1] is postponed to L, and
this BP[2] is merged in K.
[1] https://review.openstack.org/#/c/146914/
[2] https://review.openstack.org/#/c/148805/
In fact [2] can be replaced by [
Hi,
On 18/02/2015 1:53 PM, Maxime Leroy wrote:
> Hi Brent,
> Thanks for your help on this feature. I have just created a channel
> irc: #vif-plug-script-support to speak about it.
> I think it will help to synchronize effort on vif_plug_script
> development. Anyone is welcome on this channel!
>
Hi Brent,
On Wed, Feb 18, 2015 at 3:26 PM, Brent Eagles wrote:
[..]
> I want to get the ball rolling on this ASAP so, I've started on this as
> well and will be updating the etherpad accordingly. I'm also keen to get
> W.I.P./P.O.C. patches to go along with it. I'll notify on the mailing
> list (
Hi Maxime, Neil,
On 16/01/2015 1:39 PM, Maxime Leroy wrote:
> On Wed, Jan 14, 2015 at 6:16 PM, Neil Jerram
> wrote:
>> Maxime Leroy writes:
>>
>>> Ok, thank you for the details. I will look how to implement this feature.
>>
>> Hi Maxime,
>>
>> Did you have time yet to start looking at this? My
On Wed, Jan 14, 2015 at 6:16 PM, Neil Jerram wrote:
> Maxime Leroy writes:
>
>> Ok, thank you for the details. I will look how to implement this feature.
>
> Hi Maxime,
>
> Did you have time yet to start looking at this? My team now has a use
> case that could be met by using vif_plug_script, so
Maxime Leroy writes:
> Ok, thank you for the details. I will look how to implement this feature.
Hi Maxime,
Did you have time yet to start looking at this? My team now has a use
case that could be met by using vif_plug_script, so I would be
happy to help with writing the spec for that. Would
On Fri, Dec 12, 2014 at 3:16 PM, Daniel P. Berrange wrote:
> On Fri, Dec 12, 2014 at 03:05:28PM +0100, Maxime Leroy wrote:
>> On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange
>> wrote:
>> > On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
>> >> On Thu, Dec 11, 2014 at 7:41 PM, Da
On Mon, Dec 15, 2014 at 10:36:59AM +, Neil Jerram wrote:
> "Daniel P. Berrange" writes:
>
> > Failing that though, I could see a way to accomplish a similar thing
> > without a Neutron launched agent. If one of the VIF type binding
> > parameters were the name of a script, we could run that s
"Daniel P. Berrange" writes:
> Failing that though, I could see a way to accomplish a similar thing
> without a Neutron launched agent. If one of the VIF type binding
> parameters were the name of a script, we could run that script on
> plug & unplug. So we'd have a finite number of VIF types, an
On Fri, Dec 12, 2014 at 03:05:28PM +0100, Maxime Leroy wrote:
> On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange
> wrote:
> > On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
> >> On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange
> >> wrote:
> >>
> [..]
> >> Port binding mechan
On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange
wrote:
> On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
>> On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange
>> wrote:
>>
[..]
>> Port binding mechanism could vary among different networking technologies,
>> which is not nova's
On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
> On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange
> wrote:
>
> >
> > Yes, I really think this is a key point. When we introduced the VIF type
> > mechanism we never intended for there to be soo many different VIF types
> > created.
On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange
wrote:
>
> Yes, I really think this is a key point. When we introduced the VIF type
> mechanism we never intended for there to be soo many different VIF types
> created. There is a very small, finite number of possible ways to configure
> the li
+100!
So, for the vif-type-vhostuser, a general script path name replace the
vif-detail "vhost_user_ovs_plug", because it's not the responsibility
of nova to understand it.
On Thu, Dec 11, 2014 at 11:24 PM, Daniel P. Berrange
wrote:
> On Thu, Dec 11, 2014 at 04:15:00PM +0100, Maxime Leroy wrote:
On Dec 11, 2014, at 2:41 AM, Daniel P. Berrange wrote:
> On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote:
>> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
>>> On 10 December 2014 at 01:31, Daniel P. Berrange
>>> wrote:
So the problem of Nova review bandwidth is a
On Thu, Dec 11, 2014 at 04:15:00PM +0100, Maxime Leroy wrote:
> On Thu, Dec 11, 2014 at 11:41 AM, Daniel P. Berrange
> wrote:
> > On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote:
> >> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
> >> > On 10 December 2014 at 01:31, Daniel P. Berran
On Thu, Dec 11, 2014 at 11:41 AM, Daniel P. Berrange
wrote:
> On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote:
>> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
>> > On 10 December 2014 at 01:31, Daniel P. Berrange
>> > wrote:
>> >>
>> >>
[..]
>> The question is, do we really need s
On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote:
> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
> > On 10 December 2014 at 01:31, Daniel P. Berrange
> > wrote:
> >>
> >>
> >> So the problem of Nova review bandwidth is a constant problem across all
> >> areas of the code. We need to
On Thu, Dec 11, 2014 at 2:37 AM, henry hly wrote:
> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
[..]
>>
>> The problem is that we effectively prevent running an out of tree Neutron
>> driver (which *is* perfectly legitimate) if it uses a VIF plugging mechanism
>> that isn't in Nova, as we c
On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells wrote:
> On 10 December 2014 at 01:31, Daniel P. Berrange
> wrote:
>>
>>
>> So the problem of Nova review bandwidth is a constant problem across all
>> areas of the code. We need to solve this problem for the team as a whole
>> in a much broader fashion
On 10 December 2014 at 01:31, Daniel P. Berrange
wrote:
>
> So the problem of Nova review bandwidth is a constant problem across all
> areas of the code. We need to solve this problem for the team as a whole
> in a much broader fashion than just for people writing VIF drivers. The
> VIF drivers a
On 12/10/2014 04:31 AM, Daniel P. Berrange wrote:
So the problem of Nova review bandwidth is a constant problem across all
areas of the code. We need to solve this problem for the team as a whole
in a much broader fashion than just for people writing VIF drivers. The
VIF drivers are really small
t for usage questions)
> Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech
> driver/L2 and vif_driver
>
> The VIF parameters are mapped into the nova.network.model.VIF class which is
> doing some crude validation. I would anticipate that this validation will
Hi Daniel,
Please see inline
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Tuesday, December 09, 2014 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech
driver
On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange wrote:
> On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
>> I have also proposed a blueprint to have a new plugin mechanism in
>> nova to load external vif driver. (nova-specs:
>> https://review.openstack.org/#/c/136827/ and nova (rfc p
On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
> I have also proposed a blueprint to have a new plugin mechanism in
> nova to load external vif driver. (nova-specs:
> https://review.openstack.org/#/c/136827/ and nova (rfc patch):
> https://review.openstack.org/#/c/136857/)
>
> From
Hi there.
I would like some clarification regarding support of out-of-tree
plugin in nova and in neutron.
First, on neutron side, there are mechanisms to support out-of-tree
plugin for L2 plugin (core_plugin) and ML2 mech driver
(stevedore/entrypoint).
Most of ML2/L2 plugins need to have a speci
29 matches
Mail list logo
