Hello,
I have been working for a while on integration with kubernetes with a CNI
plugin for OVN.
The work in [1] is forked by Guru's repository by the same name [2].
Most consumers of the CNI interface have an expectation that when returning
from the plugin the container interface is fully config
om/salv-orlando/ovn-kubernetes/blob/master/ovn_k8s/conn_processor.py#L59
On 19 May 2016 at 12:38, Salvatore Orlando wrote:
> Hello,
>
> I have been working for a while on integration with kubernetes with a CNI
> plugin for OVN.
> The work in [1] is forked by Guru's repo
Thanks Guru!
Some comments inline.
Salvatore
On 19 May 2016 at 16:11, Guru Shetty wrote:
>
>
> On 19 May 2016 at 03:57, Salvatore Orlando wrote:
>
>> [Accidentally sent message before completing, resuming here]
>>
>> Hello,
>>
>> I have been working
As I am doing some integration between OVN and Kubernetes, there is a
similar problem there where the introduction of this concept can be very
beneficial.
To provide some context a Kubernetes network policy [1] might have several
"from" clauses which might translate into a great number of IP addre
I'm afraid I have to start bike shedding on this thread too.
Apparently that's what I do best.
More inline,
Salvatore
On 23 June 2015 at 23:23, Russell Bryant wrote:
> On 06/23/2015 05:10 PM, Ben Pfaff wrote:
> > On Tue, Jun 23, 2015 at 04:54:20PM -0400, Russell Bryant wrote:
> >> On 06/23/2015
[resending to the ovs-dev as I sent my original reply to Russell only]
Comments inline
Salvatore
On 24 June 2015 at 16:15, Russell Bryant wrote:
> On 06/23/2015 06:56 PM, Ben Pfaff wrote:
> > On Tue, Jun 23, 2015 at 11:58:25PM +0200, Salvatore Orlando wrote:
> >> I'm
Reading your post and the associated patch it seems that you're treating
the physical network as a logical port from a pipeline perspective but
exposing it as a logical switch attribute from a NB DB perspective. Is that
correct?
If my previous statement is correct, I wonder why not treat it always
This makes sense to me as well.
It's surely better to have structured data rather then encode them in
resource names.
In the options attribute for a "local" logical port, I guess the "name"
attribute will be the name of some ovs bridge instance where the port is
plugged.
From a neutron integratio
I reckon that this approach makes sense, as it alters very little OVN's
northbound schema; moreover at first glance I do not see in the patch
series any change to the OVN pipeline.
Also mapping neutron provider networks extension onto OVN should not be too
difficult. Perhaps neutron will have to d
Polling for port status is the easiest solution.
In some cases excessive polling does not scale very well.
For instance in large cloud with 1000s of compute nodes, this will put a
bit of a strain on the neutron server.
This why Aaron a while ago implemented [1] for interfacing neutron with
nova.
B
Thanks a lot Russell, this information are very useful.
I'm not sure what you think of it, but I feel like a link to your blog post
[1] might be very useful as well.
This is what I've been following so far to get started on the OVN side of
things.
It seems the information there complement and do n
Hi Russel,
thanks for sharing these thoughts. I was indeed thinking as well we need to
support this in OVN as the provider networks are a fairly basic neutron
feature - despite being an "extensions".
I have some comments inline. I apologise in advance for their dumbness as
I'm still getting up to
12 matches
Mail list logo
