Re: [openstack-dev] [tap-as-a-service] core reviewer update

2018-06-13 Thread SUZUKI, Kazuhiro
Hi,

Thank you.
I'm glad to be able to support the TaaS community.

Regards,
Kaz

From: Takashi Yamamoto 
Subject: Re: [openstack-dev] [tap-as-a-service] core reviewer update
Date: Wed, 13 Jun 2018 16:34:09 +0900

> i just made the change as i haven't got any concerns.
> welcome, kaz!
> 
> On Thu, May 31, 2018 at 2:36 PM, Takashi Yamamoto  
> wrote:
>> hi,
>>
>> i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
>> he is one of active members of the project.
>> he is also the original author of tap-as-a-service-dashboard.
>> i'll make the change after a week unless i hear any objections/concerns.
>>
>> [1] https://review.openstack.org/#/admin/groups/957,members
>> http://stackalytics.com/report/contribution/tap-as-a-service/120
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas dashboard split out

2017-06-29 Thread SUZUKI, Kazuhiro
Hi,

I would like to announce a new repository for tap-as-a-service was
created.
Could you please take a look.

http://git.openstack.org/cgit/openstack/tap-as-a-service-dashboard/

Regards,
Kaz


From: Akihiro Motoki 
Subject: [openstack-dev] [neutron][horizon][fwaas][vpnaas] fwaas/vpnaas 
dashboard split out
Date: Wed, 21 Jun 2017 13:46:37 +0900

> Hi neutron and horizon teams (especially fwaas and vpnaas folks),
> 
> As we discussed so far, I prepared separate git repositories for FWaaS
> and VPNaaS dashboards.
> http://git.openstack.org/cgit/openstack/neutron-fwaas-dashboard/
> http://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/
> 
> All new features will be implemented in the new repositories, for
> example, FWaaS v2 support.
> The initial core members consist of neutron-fwaas/vpnaas-core
> (respectively) + horizon-core.
> 
> There are several things to do to complete the split out.
> I gathered a list of work items at the etherpad and we will track the
> progress here.
> https://etherpad.openstack.org/p/horizon-fwaas-vpnaas-splitout
> If you are interested in helping the efforts, sign up on the etherpad
> or contact me.
> 
> I would like to release the initial release which is compatible with
> the current horizon
> FWaaS/VPNaaS dashboard (with no new features).
> I hope we can release it around R-8 week (Jul 3) or R-7 (Jul 10).
> 
> It also will be good examples for neutron stadium/related projects
> which are interested in
> adding dashboard support. AFAIK, networking-sfc, tap-as-a-service are
> interested in it.
> 
> Thanks,
> Akihiro
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-12 Thread SUZUKI, Kazuhiro
Hi,

> I think (a) is also good from TaaS dashboard.

This opinion is agreed as a TaaS project.

Regards,
Kaz


From: "SUZUKI, Kazuhiro" <k...@jp.fujitsu.com>
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?
Date: Wed, 12 Apr 2017 09:19:42 +0900 (JST)

> Hi,
> 
> I think (a) is also good from TaaS dashboard.
> 
> Regards,
> Kaz
> 
> 
> From: Akihiro Motoki <amot...@gmail.com>
> Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
> like to have horizon dashboard for neutron stadium projects?
> Date: Tue, 11 Apr 2017 00:09:10 +0900
> 
>> Hi neutrinos (and horizoners),
>> 
>> As the title says, where would we like to have horizon dashboard for
>> neutron stadium projects?
>> There are several projects under neutron stadium and they are trying
>> to add dashboard support.
>> 
>> I would like to raise this topic again. No dashboard support lands since 
>> then.
>> Also Horizon team would like to move in-tree neutron stadium dashboard
>> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>> 
>> Possible approaches
>> 
>> 
>> Several possible options in my mind:
>> (a) dashboard repository per project
>> (b) dashboard code in individual project
>> (c) a single dashboard repository for all neutron stadium projects
>> 
>> Which one sounds better?
>> 
>> Pros and Cons
>> 
>> 
>> (a) dashboard repository per project
>>   example, networking-sfc-dashboard repository for networking-sfc
>>   Pros
>>- Can use existing horizon related project convention and knowledge
>>  (directory structure, testing, translation support)
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons
>>- An additional repository is needed.
>> 
>> (b) dashboard code in individual project
>>   example, dashboard module for networking-sfc
>>   Pros:
>>- No additional repository
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons:
>>- Requires extra efforts to support neutron and horizon codes in a
>> single repository
>>  for testing and translation supports. Each project needs to
>> explore the way.
>> 
>> (c) a single dashboard repository for all neutron stadium projects
>>(something like neutron-advanced-dashboard)
>>   Pros:
>> - No additional repository per project
>>   Each project do not need a basic setup for dashboard and
>> possible makes things simple.
>>   Cons:
>> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>>   (Similar discussion happens as for neutronclient OSC plugin)
>>   Project before neutron stadium inclusion may need another 
>> implementation.
>> 
>> 
>> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a 
>> repo).
>> 
>> Note that as dashboard supports for feature in the main neutron repository
>> are implemented in the horizon repository as we discussed several months ago.
>> As an example, trunk support is being development in the horizon repo.
>> 
>> Thanks,
>> Akihiro
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

2017-04-11 Thread SUZUKI, Kazuhiro
Hi,

I think (a) is also good from TaaS dashboard.

Regards,
Kaz


From: Akihiro Motoki 
Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
like to have horizon dashboard for neutron stadium projects?
Date: Tue, 11 Apr 2017 00:09:10 +0900

> Hi neutrinos (and horizoners),
> 
> As the title says, where would we like to have horizon dashboard for
> neutron stadium projects?
> There are several projects under neutron stadium and they are trying
> to add dashboard support.
> 
> I would like to raise this topic again. No dashboard support lands since then.
> Also Horizon team would like to move in-tree neutron stadium dashboard
> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
> 
> Possible approaches
> 
> 
> Several possible options in my mind:
> (a) dashboard repository per project
> (b) dashboard code in individual project
> (c) a single dashboard repository for all neutron stadium projects
> 
> Which one sounds better?
> 
> Pros and Cons
> 
> 
> (a) dashboard repository per project
>   example, networking-sfc-dashboard repository for networking-sfc
>   Pros
>- Can use existing horizon related project convention and knowledge
>  (directory structure, testing, translation support)
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons
>- An additional repository is needed.
> 
> (b) dashboard code in individual project
>   example, dashboard module for networking-sfc
>   Pros:
>- No additional repository
>- Not related to the neutron stadium inclusion. Each project can
> provide its dashboard
>  support regardless of neutron stadium inclusion.
>  Cons:
>- Requires extra efforts to support neutron and horizon codes in a
> single repository
>  for testing and translation supports. Each project needs to
> explore the way.
> 
> (c) a single dashboard repository for all neutron stadium projects
>(something like neutron-advanced-dashboard)
>   Pros:
> - No additional repository per project
>   Each project do not need a basic setup for dashboard and
> possible makes things simple.
>   Cons:
> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>   (Similar discussion happens as for neutronclient OSC plugin)
>   Project before neutron stadium inclusion may need another 
> implementation.
> 
> 
> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).
> 
> Note that as dashboard supports for feature in the main neutron repository
> are implemented in the horizon repository as we discussed several months ago.
> As an example, trunk support is being development in the horizon repo.
> 
> Thanks,
> Akihiro
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Cloud-init VM instance not coming up in a multi-node DevStack envionment

2017-03-02 Thread SUZUKI, Kazuhiro
Hi Anil,

I met the same issue in my local devstack environment.
Do you use proxy when you execute stack.sh script in your environment?
If so, please try to set no_proxy parameter.

See also:
https://answers.launchpad.net/devstack/+question/245480

Regards,
Kaz


From: Anil Rao 
Subject: [openstack-dev] [all] Cloud-init VM instance not coming up in a 
multi-node DevStack envionment
Date: Thu, 2 Mar 2017 03:27:33 +

> Hi,
> 
> I recently created a multi-node DevStack environment (based on stable/ocata) 
> made up of the following nodes:
> 
> 
> -1 Controller Node
> 
> -1 Network Node
> 
> -2 Compute Nodes
> 
> All VM instances are only deployed on the 2 compute nodes. Neutron network 
> services are provided by the network node.
> 
> I am able to create VMs and have them communicate with each other and also 
> with external (outside the DevStack environment) endpoints.
> 
> However, I find that I am unable to successfully deploy a VM instance that is 
> based on cloud-init. As the following console log snippet shows, cloud-init 
> running inside a VM instance is unable to get the necessary meta-data and 
> hangs during VM instance startup.
> 
> 
> 91.811361] cloud-init[977]: ci-info: 
> ++Net device 
> info+++
> [   91.818689] cloud-init[977]: ci-info: 
> ++--+--+---+---+---+
> [   91.825274] cloud-init[977]: ci-info: | Device |  Up  |   Address  
>   |  Mask | Scope | Hw-Address|
> [   91.832763] cloud-init[977]: ci-info: 
> ++--+--+---+---+---+
> [   91.839288] cloud-init[977]: ci-info: |   lo   | True |  127.0.0.1 
>   |   255.0.0.0   |   .   | . |
> [   91.857827] cloud-init[977]: ci-info: |   lo   | True |   ::1/128  
>   |   .   |  host | . |
> [   91.864806] cloud-init[977]: ci-info: |  eth0  | True | 
> 192.168.1.10 | 255.255.255.0 |   .   | fa:16:3e:cf:a8:d8 |
> [   91.871433] cloud-init[977]: ci-info: |  eth0  | True | 
> fe80::f816:3eff:fecf:a8d8/64 |   .   |  link | fa:16:3e:cf:a8:d8 |
> [   91.878237] cloud-init[977]: ci-info: 
> ++--+--+---+---+---+
> [   91.896344] cloud-init[977]: ci-info: 
> Route IPv4 
> info
> [   91.903652] cloud-init[977]: ci-info: 
> +---+-+-+-+---+---+
> [   91.912523] cloud-init[977]: ci-info: | Route |   Destination   |   
> Gateway   | Genmask | Interface | Flags |
> [   91.930131] cloud-init[977]: ci-info: 
> +---+-+-+-+---+---+
> [   91.936482] cloud-init[977]: ci-info: |   0   | 0.0.0.0 | 
> 192.168.1.1 | 0.0.0.0 |eth0   |   UG  |
> [   91.942651] cloud-init[977]: ci-info: |   1   | 169.254.169.254 | 
> 192.168.1.1 | 255.255.255.255 |eth0   |  UGH  |
> [   91.948624] cloud-init[977]: ci-info: |   2   |   192.168.1.0   |   
> 0.0.0.0   |  255.255.255.0  |eth0   |   U   |
> [   91.954798] cloud-init[977]: ci-info: 
> +---+-+-+-+---+---+
> [   91.961102] cloud-init[977]: 2017-03-01 17:46:38,723 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: 
> bad status code [404]
> [   92.997374] cloud-init[977]: 2017-03-01 17:46:39,917 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: 
> bad status code [404]
> [   94.320985] cloud-init[977]: 2017-03-01 17:46:41,240 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]: 
> bad status code [404]
> [   95.480615] cloud-init[977]: 2017-03-01 17:46:42,400 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: 
> bad status code [404]
> [
> ...
> 
> [  118.589843] cloud-init[977]: 2017-03-01 17:47:05,509 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [27/120s]: 
> bad status code [404]
> [  121.796946] cloud-init[977]: 2017-03-01 17:47:08,716 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [30/120s]: 
> bad status code [404]
> [  124.918111] cloud-init[977]: 2017-03-01 17:47:11,837 - 
> url_helper.py[WARNING]: Calling 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [33/120s]: 
> bad status code [404]
> [  129.195778] cloud-init[977]: 2017-03-01 17:47:16,115 - 
> url_helper.py[WARNING]: Calling 
> 

Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?

2016-07-05 Thread SUZUKI, Kazuhiro

Hi Jimmy,

I guess that it has not been resoved yet.
You should try to ask it on IRC meeting, I think.

http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting

Regards,
Kaz


From: 张广明 <gmzhan...@gmail.com>
Subject: Re: [openstack-dev] [neutron][taas] Taas can not capture the 
packet, if the two VM on the same host. Is it a Bug?

Date: Tue, 5 Jul 2016 19:31:14 +0800


Hi Kaz
Thanks for your answer. But int the log, i can not find how to  
resolve

this issue. In fact ,this issue is not related with br-ex.
In OVS, the normal action add or remove vlan id when output the pac 
ket. So

we should add another rule that use in_port that
belongs to the same vlan with mirror port as rule condition  in br- 
int.




 Jimmy

2016-07-05 17:01 GMT+08:00 SUZUKI, Kazuhiro <k...@jp.fujitsu.com>:


Hi,

I also have seen the same situation.
The same issue is discussed at the IRC meeting of TaaS.
Please take a look at the log.


http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-04-13- 
06.30.log.html


Regards,
Kaz


From: 张广明 <gmzhan...@gmail.com>
Subject: [openstack-dev] [neutron][taas] Taas can not capture the  
packet,

if the two VM on the same host. Is it a Bug?
Date: Fri, 1 Jul 2016 16:03:53 +0800

> Hi ,
> I found a limitation when use taas.  My test case is descrip 
ped as

> follow:
> VM1 and VM2 is running on the same host and  they are belong 
 the

vlan.
> The monitor VM is on the same host or the  other host . I want t 
o monitor

> the only INPUT flow to the VM1.
> So I configure the tap-flow like this "neutron tap-flow-crea 
te

--port
> 2a5a4382-a600-4fb1-8955-00d0fc9f648f  --tap-service
> c510e5db-4ba8-48e3-bfc8-1f0b61f8f41b --direction IN ".
> When ping from VM2 to VM1.  I can not get the flow in the mo 
nitor VM.
>The reason is the the flow from VM2 to VM1 in br-int has not  
vlan
> information. The vlan tag was added in flow when output the pack 
et  in

OVS.
> So the code in file ovs_taas.py did not work in this case .
>
>  if direction == 'IN' or direction == 'BOTH':
> port_mac = tap_flow['port_mac']
>  self.int_br.add_flow(table=0,
>  priority=20,
> dl_vlan=port_vlan_id,
> dl_dst=port_mac,
>
actions="normal,mod_vlan_vid:%s,output:%s" %
>  (str(taas_id), str(patch_int_ta 
p_id)))

>
>
>
>
>  Is this is a Bug or a Design ??
>
>
>
> Thanks.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][taas] Taas can not capture the packet, if the two VM on the same host. Is it a Bug?

2016-07-05 Thread SUZUKI, Kazuhiro
Hi,

I also have seen the same situation.
The same issue is discussed at the IRC meeting of TaaS.
Please take a look at the log.

http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-04-13-06.30.log.html

Regards,
Kaz


From: 张广明 
Subject: [openstack-dev] [neutron][taas] Taas can not capture the packet, if 
the two VM on the same host. Is it a Bug?
Date: Fri, 1 Jul 2016 16:03:53 +0800

> Hi ,
> I found a limitation when use taas.  My test case is descripped as
> follow:
> VM1 and VM2 is running on the same host and  they are belong the vlan.
> The monitor VM is on the same host or the  other host . I want to monitor
> the only INPUT flow to the VM1.
> So I configure the tap-flow like this "neutron tap-flow-create  --port
> 2a5a4382-a600-4fb1-8955-00d0fc9f648f  --tap-service
> c510e5db-4ba8-48e3-bfc8-1f0b61f8f41b --direction IN ".
> When ping from VM2 to VM1.  I can not get the flow in the monitor VM.
>The reason is the the flow from VM2 to VM1 in br-int has not vlan
> information. The vlan tag was added in flow when output the packet  in OVS.
> So the code in file ovs_taas.py did not work in this case .
> 
>  if direction == 'IN' or direction == 'BOTH':
> port_mac = tap_flow['port_mac']
>  self.int_br.add_flow(table=0,
>  priority=20,
> dl_vlan=port_vlan_id,
> dl_dst=port_mac,
>actions="normal,mod_vlan_vid:%s,output:%s" %
>  (str(taas_id), str(patch_int_tap_id)))
> 
> 
> 
> 
>  Is this is a Bug or a Design ??
> 
> 
> 
> Thanks.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][taas] Voting for new core reviewers

2016-03-01 Thread SUZUKI, Kazuhiro
+1 for both Soichi and Yamamoto.

Thanks,
KAZ

From: Fawad Khaliq 
Subject: Re: [openstack-dev] [neutron][taas] Voting for new core reviewers
Date: Tue, 1 Mar 2016 20:09:07 -0800

> +1 to both. Great to see the core team growing.
> 
> Fawad Khaliq
> 
> 
> On Tue, Mar 1, 2016 at 5:35 PM, Anil Rao  wrote:
> 
>> Both Takashi and Soichi have been involved with the project for a while
>> now and have made significant contributions in terms of code and reviews.
>>
>>
>>
>> +1 for both.
>>
>>
>>
>> Thanks,
>>
>> Anil
>>
>>
>>
>> *From:* reedip banerjee [mailto:reedi...@gmail.com]
>> *Sent:* Tuesday, March 01, 2016 4:21 PM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* [openstack-dev] [neutron][taas] Voting for new core reviewers
>>
>>
>>
>>
>>
>> +1 to both Soichi and Yamamoto
>>
>> --
>>
>> Date: Tue, 1 Mar 2016 21:26:59 +0100
>> From: Vinay Yadhav 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: [openstack-dev]  [neutron][taas]
>> Message-ID:
>> <
>> ca+bcmm3avextk-vb4y0e8dphyb0pjxsutkxfv6_bsshqkf-...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi All,
>>
>> Its time to induct new members to the TaaS core reviewers, to kick start
>> the process i nominate the following developers and active contributors to
>> the TaaS project
>>
>> 1. Yamamoto Takashi
>> 2. Soichi Shigeta
>>
>>
>> Cheers,
>> Vinay Yadhav
>>
>>
>>
>> --
>>
>> Thanks and Regards,
>> Reedip Banerjee
>>
>> IRC: reedip
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas flows

2015-12-21 Thread SUZUKI, Kazuhiro
Hi,

I submited a modified patch set as follows.
In addition, I added test codes for this patch.

>   1. Set an integer cookie value to taas flows.
>  Maybe all "1" for short term tentative value.
>   2. Modify the cleanup logic in ovs-agent not to delete flows
>  which have a reserved integer cookie value.

https://review.openstack.org/#/c/257285/
https://review.openstack.org/#/c/257286/

Thanks,
KAZ


From: Soichi Shigeta 
Subject: Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas 
flows
Date: Thu, 17 Dec 2015 09:28:10 +0900

> 
>  Thank you for your helpful comments.
> 
>  I'd like to update my proposal as follows:
> 
>   1. Set an integer cookie value to taas flows.
>  Maybe all "1" for short term tentative value.
>   2. Modify the cleanup logic in ovs-agent not to delete flows
>  which have a reserved integer cookie value.
> 
> 
>> Sorry, that I don't see this earlier. Yes, cookies have integer
>> values, so
>> we won't be able to set string there. May be we can have a reserved
>> integer
>> cookie value for a project like all "1".
>>
>> I won't support idea of modifying cleanup logic not to drop 0x0
>> cookies.
>> During implementation of graceful restart it was not dropped at first,
>> but
>> I get rid of it as having a lot of flows not related to anything was
>> not
>> desirable, so we should try to avoid it here, too.
>>
>> On Wed, Dec 16, 2015 at 7:46 AM, Soichi Shigeta <
>> shigeta.soi...@jp.fujitsu.com> wrote:
>>
>>>
>>> o) An idea to fix:

1. Set "taas" stamp(*) to taas flows.
2. Modify the cleanup logic in ovs-agent not to delete entries
   stamped as "taas".

* Maybe a static string.
  If we need to use a string which generated dynamically
  (e.g. uuid), API to interact with ovs-agent is required.


>>>Last week I proposed to set a static string (e.g. "taas") as cookie
>>>of flows created by taas agent.
>>>
>>>But I found that the value of a cookie should not be a string,
>>>but an integer.
>>>
>>>At line 187 in
>>> "neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py":
>>>self.agent_uuid_stamp = uuid.uuid4().int & UINT64_BITMASK
>>>
>>>In case of we set an integer value to cookie, coordination
>>>(reservation of range) is required to avoid conflict of cookies with
>>>other neutron sub-projects.
>>>
>>>As an alternative (*** short term ***) solution, my idea is:
>>>Modify the clean up logic in ovs agent not to delete flows whose
>>>"cookie = 0x0".
>>>Because old flows created by ovs agent have an old stamp, "cookie =
>>>0x0" means it was created by other than ovs agent.
>>>
>>># But, this idea has a disadvantage:
>>>  If there are flows which have been created by older version of ovs
>>>  agent, they can not be cleaned.
>>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

2015-11-20 Thread SUZUKI, Kazuhiro
Hi,

Thank you for your interest and suggestion.

A blueprint [1] has already proposed to add port mirroring
capabilities to Neutron.

[1] https://blueprints.launchpad.net/neutron/+spec/port-mirroring

Because our proposal is for the current design of TaaS
(tap-as-a-service), I guess a RFE is not required at this time.

Thank you.

--
Kazuhiro Suzuki


From: Li Ma 
Subject: Re: [openstack-dev] [neutron][taas] proposal: dedicated tunnel for 
carrying mirrored traffic
Date: Thu, 19 Nov 2015 11:51:15 +0800

> It is suggested that you can issue a RFE request for it. [1] We can
> discuss with it and track the progress in the launchpad.
> 
> By the way, I'm very interested in it. I discussed a another problem
> with Huawei neutron engineers about abstract VTEP to neutron port. It
> allows managing VTEP and can leverage the flexibility in many aspects
> as more and more neutron features need VTEP management, just like your
> proposal.
> 
> [1] http://docs.openstack.org/developer/neutron/policies/blueprints.html
> 
> On Thu, Nov 19, 2015 at 11:36 AM, Soichi Shigeta
>  wrote:
>>
>>  Hi,
>>
>> As we decided in the last weekly meeting,
>>   I'd like to use this mailing list to discuss
>>   a proposal about creating dedicated tunnel for
>>   carrying mirrored traffic between hosts.
>>
>>   link:
>> https://wiki.openstack.org/w/images/7/78/TrafficIsolation_20151116-01.pdf
>>
>>   Best Regards,
>>   Soichi Shigeta
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> 
> Li Ma (Nick)
> Email: skywalker.n...@gmail.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev