[Openstack] Company Role Identification

2017-05-22 Thread TanXin 
Hello,

I am doing a research about company role in OpenStack developing activities. I 
wonder to know if I use the domain of commit author email is feasible and 
meaningful.
I need your feedback or suggestions.

Thank your for your kind help.

TanXin


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to utilize Neutron independently with veths

2017-05-22 Thread Kevin Benton 
Yes, the only thing that needs to use the correct MAC is whatever is
actually sending traffic.

On May 21, 2017 22:06, "duhongwei"  wrote:

>
> Thanks for your patient, Kevin.
>
> So *qvo *could be any veth whose mac address doesn't matter, but *veth/tap
> *must have exact the same mac address as *port*, otherwise it will be
> anti-spoofed.
>
> *qvo*'s attributes (external-ids) tell neutron which logical *port* *qvo*
> is connecting, so neutron knows how to add flows to ovs *br-int *and
> *br-tun*.
>
> Am I correct?
>
> Regards,
> Dastan
>
> -- Original --
> *From: * "Kevin Benton";
> *Date: * Sat, May 20, 2017 03:26 AM
> *To: * "duhongwei";
> *Cc: * "openstack"; "Vallachorum
> Tyranorum";
> *Subject: * Re: [Openstack] How to utilize Neutron independently with
> veths
>
> >After all these, we create *veth/tap* (as vm/containers vNIC) and plugin
> it into *qbr* then we're able to talk with other vms/containers on the
> same network through *veth/tap*, am I understanding it right?
>
> Yes, this last step of creating a veth/tap is missing from my script
> because I didn't need actual dataplane communication for the tests I was
> doing.
>
> >1) isn't it necessary that *veth/tap*'s mac address same as neutron
> *port*'s mac address?
>
> Yeah, if you attach something to qbr to behave like the VM interface, you
> will need it to be using the mac address of the neutron port, or else the
> neutron anti-spoofing rules will prevent it from communicating.
>
>
> >2) after we plug *qvo* into ovs *br-int*, neutron just automatically add
> flows into ovs bridge?
>
> Yes, the agent will receive to the new port event from ovs, retrieve port
> details from the server and then setup the flows.
>
> On Fri, May 19, 2017 at 12:09 AM, duhongwei  wrote:
>
>>
>> This script seems easy and cool!
>>
>> So first we have to create a logical neutron *port*, then create *qbr*,
>> *qvo* and *qvb*, and plug *qvb* into *qbr*, finally plug *qvo* into ovs
>> *br-int*. After all these, we create *veth/tap* (as vm/containers vNIC)
>> and plugin it into *qbr* then we're able to talk with other
>> vms/containers on the same network through *veth/tap*, am I
>> understanding it right?
>>
>> Questions,
>>
>> 1) isn't it necessary that *veth/tap*'s mac address same as neutron
>> *port*'s mac address?
>> 2) after we plug *qvo* into ovs *br-int*, neutron just automatically add
>> flows into ovs bridge?
>>
>> Regards,
>> Dastan
>>
>> -- Original --
>> *From: * "Kevin Benton";
>> *Date: * Sat, May 13, 2017 07:46 AM
>> *To: * "duhongwei";
>> *Cc: * "openstack"; "Vallachorum
>> Tyranorum";
>> *Subject: * Re: [Openstack] How to utilize Neutron independently with
>> veths
>>
>> Nova is only responsible for creating the interface and plugging it into
>> the OVS bridge. It's the neutron agent (or alternative neutron backend like
>> OVN) responsible for setting up all of the flows.
>>
>> Here is a hacky script that I had used to create and delete a bunch of
>> ports like Nova would that you can probably start with:
>> http://paste.openstack.org/show/609478/
>>
>> On Fri, May 12, 2017 at 4:25 AM, duhongwei  wrote:
>>
>>>
>>> Thanks Kevin!
>>>
>>> I'll dig into neutron.agent.linux.interface to see how it works. Before
>>> that, would you give me any previews about what steps should be taken to
>>> add a veth to a existed Neutron network?
>>>
>>> Furthermore, is it Neutron who add a veth to ovs bridge or is it the
>>> Neutron caller? (such as Nova)
>>>
>>> Who's adding flows to ovs bridge? Neutron or caller?
>>>
>>> Regards,
>>> Dastan
>>>
>>> -- Original --
>>> *From: * "Kevin Benton";
>>> *Date: * Fri, May 12, 2017 10:45 AM
>>> *To: * "duhongwei";
>>> *Cc: * "openstack"; "Vallachorum
>>> Tyranorum";
>>> *Subject: * Re: [Openstack] How to utilize Neutron independently with
>>> veths
>>>
>>> You want to look in neutron.agent.linux.interface to see how things are
>>> plugged into OVS. That's the module used by the L3 agent to plug into
>>> OVS/linux bridge/etc.
>>>
>>> There is a well defined interface name format corresponding to the port
>>> ID and the port ID, Mac address, and a couple of other things I can't
>>> recall are set in ovsdb to help the agent identify the port as something it
>>> should care about.
>>>
>>> On May 9, 2017 04:49, "duhongwei"  wrote:
>>>

 Thanks Dan!

 I have to write a customized CNI plugin for our product, so it's better
 if I know more operation details about how to interact with Neutron
 manually (consider myself as Nova). Therefore Kuryr is not my best option
 right now, but it's cool!

 Regards,
 Dastan

 -- Original --
 *From: * "Vallachorum Tyranorum";
 *Date: * Tue, May 9, 2017 04:08 PM
 *To: * "duhongwei"; "openstack">>> enstack.org>;
 *Subject: * Re: [Openstack] How to utilize Neutron independently with
 veths

 Hi,

>>>

Re: [Openstack] Openstack Routed Provider Networks Question

2017-05-22 Thread Chris Marino 
I'm digging into how Routed Provider Networks work and have some questions
as well. I will presenting at the OpenStack Meetup
on Wed on this and want
to make sure I have my facts straight..

>From the doc page

it
shows a multi-segment network with segment 1 on 203.0.113.0/24 and segment
2 on 198.51.100.0/24. It also suggests using the same VLAN ID for these
segments.

I find both of these things really confusing. But ignoring that for a
minute, I'm more interested in the expected use case for this feature. I
see from the original spec/blueprint

that the
goal was to allow for a single Provider Network to be made up from multiple
network segments, where external routing provided connectivity among the
segments. And Routed Provider Networks provide this.  Great.

But the use cases I'm curious about are where the operator wants to take
their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
Network. Same CIDR as the L2 provider network, but in a fully routed
deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
L2 to the host. Or L3 to the host.

Both of these configurations are gaining popularity and wondering how they
would need to be configured. For the L3 to ToR, the network segments would
have to be split across the ToRs as described in the doc, but what about L3
to host? Guessing a segment per host, but wondering how practical that's
going to be without better coordination of IP/segments with Nova?

CM
ᐧ

On Sun, May 21, 2017 at 6:12 AM, Alex Evonosky 
wrote:

> Thank you Yura.
>
> A
>
> On Thu, May 18, 2017 at 3:24 AM, Yura Poltoratskiy 
> wrote:
>
>> Hi
>>
>> On 17.05.2017 21:56, Alex Evonosky wrote:
>>
>>> Hello fellow Openstackers-
>>>
>>> I have a quick question regarding routed provider networks.  I am
>>> looking at this
>>> page: https://docs.openstack.org/ocata/networking-guide/config-rou
>>> ted-networks.html
>>>
>>> I configured the controller as stated in the docs, however this line is
>>> somewhat vaugue:
>>>
>>> "
>>>
>>>
>>>   Network or compute nodes¶
>>>   >> uted-networks.html#network-or-compute-nodes>
>>>
>>>   * Configure the layer-2 agent on each node to map one or more segments
>>> to the appropriate physical network bridge or interface and restart
>>> the agent."
>>>
>>>
>>> Which file am I editing on the compute nodes to answer the above
>>> question?
>>>
>> If you are using OpenVSwitch agent, then on compute/network node you
>> should modify:
>> /etc/neutron/plugins/ml2/openvswitch_agent.ini
>> /etc/neutron/plugins/ml2/ml2_conf.ini
>>
>>
>>>
>>> Thank you,
>>> A
>>>
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Openstack Routed Provider Networks Question

2017-05-22 Thread Kevin Benton 
On May 22, 2017 9:34 AM, "Chris Marino"  wrote:

I'm digging into how Routed Provider Networks work and have some questions
as well. I will presenting at the OpenStack Meetup
on Wed on this and want
to make sure I have my facts straight..

>From the doc page

it
shows a multi-segment network with segment 1 on 203.0.113.0/24 and segment
2 on 198.51.100.0/24. It also suggests using the same VLAN ID for these
segments.

I find both of these things really confusing.


What do you find confusing about this? It's a pretty standard L3 to ToR and
L2 in rack setup. L2 is limited to the rack so you can use or not use
whatever VLANs in that scope. We can fix the docs to clear up whatever
confusion you have.

But ignoring that for a minute, I'm more interested in the expected use
case for this feature. I see from the original spec/blueprint

that the
goal was to allow for a single Provider Network to be made up from multiple
network segments, where external routing provided connectivity among the
segments. And Routed Provider Networks provide this.  Great.

But the use cases I'm curious about are where the operator wants to take
their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
Network. Same CIDR as the L2 provider network, but in a fully routed
deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
L2 to the host. Or L3 to the host.

Both of these configurations are gaining popularity and wondering how they
would need to be configured. For the L3 to ToR, the network segments would
have to be split across the ToRs as described in the doc, but what about L3
to host? Guessing a segment per host, but wondering how practical that's
going to be without better coordination of IP/segments with Nova?


L3 to the host and one segment per host is possible, but it's going to have
a severe limitation of not being able to migrate VMs without an IP change.
To get migration at that point you will need some form of dynamic routing.

L3 to ToR and L2 in rack is definitely the target use case as of now.

On May 22, 2017 9:34 AM, "Chris Marino"  wrote:

> I'm digging into how Routed Provider Networks work and have some questions
> as well. I will presenting at the OpenStack Meetup
> on Wed on this and
> want to make sure I have my facts straight..
>
> From the doc page
> 
>  it
> shows a multi-segment network with segment 1 on 203.0.113.0/24 and
> segment 2 on 198.51.100.0/24. It also suggests using the same VLAN ID for
> these segments.
>
> I find both of these things really confusing. But ignoring that for a
> minute, I'm more interested in the expected use case for this feature. I
> see from the original spec/blueprint
> 
>  that the
> goal was to allow for a single Provider Network to be made up from multiple
> network segments, where external routing provided connectivity among the
> segments. And Routed Provider Networks provide this.  Great.
>
> But the use cases I'm curious about are where the operator wants to take
> their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
> Network. Same CIDR as the L2 provider network, but in a fully routed
> deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
> L2 to the host. Or L3 to the host.
>
> Both of these configurations are gaining popularity and wondering how they
> would need to be configured. For the L3 to ToR, the network segments would
> have to be split across the ToRs as described in the doc, but what about L3
> to host? Guessing a segment per host, but wondering how practical that's
> going to be without better coordination of IP/segments with Nova?
>
> CM
> ᐧ
>
> On Sun, May 21, 2017 at 6:12 AM, Alex Evonosky 
> wrote:
>
>> Thank you Yura.
>>
>> A
>>
>> On Thu, May 18, 2017 at 3:24 AM, Yura Poltoratskiy > > wrote:
>>
>>> Hi
>>>
>>> On 17.05.2017 21:56, Alex Evonosky wrote:
>>>
 Hello fellow Openstackers-

 I have a quick question regarding routed provider networks.  I am
 looking at this
 page: https://docs.openstack.org/ocata/networking-guide/config-rou
 ted-networks.html

 I configured the controller as stated in the docs, however this line is
 somewhat vaugue:

 "


   Network or compute nodes¶
   

   * Configure the layer-2 agent on each node to map one or more segments
 to the appropriate physical network bridge or interface and restart
 the agent."