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

[Soichi Shigeta]

+1

Soichi


On 2018/05/31 14:36, 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

[openstack-dev] [neutron][taas] IRC Meeting Canceled (week of 9/11/2017)

[Soichi Shigeta]

 Hi,

Next week's TaaS IRC meeting is being canceled because of
  the week of OpenStack PTG.

  Regards,
  Soichi



__
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-dev] [neutron][taas] IRC Meeting Canceled (weeks of 5/1/2017 and 5/8/2017)

[Soichi Shigeta]

 Hi,

  Next two weeks, TaaS IRC meetings are being canceled.

  1) week of 5/1/2017: national holidays in Japan
  2) week of 5/8/2017: week of OpenStack Summit Boston

  Regards,
  Soichi


__
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-dev] [neutron][taas] IRC Meeting Canceled (week of 2/20/2017)

[Soichi Shigeta]

 Hi,

Next week's TaaS IRC meeting is being canceled because of
  the week of OpenStack PTG.

  Regards,
  Soichi


__
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] ocata

[Soichi Shigeta]

 Hi Yamamoto,

   We discussed this on today's IRC and agreed to make an ocata release.

   Best regards,
   Soichi




tap-as-a-service folks,

unless anyone objects, i'll make a ocata release and thus stable
branch this week.
(otherwise the CI of consuming subprojects will break)

__
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

[openstack-dev] [neutron][taas] TaaS IRC schedule

[Soichi Shigeta]

 Hi,

TaaS IRC meetings on 12/21, 12/28 and 1/4 being
  canceled because of Christmas and New Year holidays.

  We will resume TaaS IRC on 1/11/2017.

  Have a nice holiday!

  Sincerely,
  Soichi


__
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] [tap-as-a-service] stable/newton 'broken'

[Soichi Shigeta]

 Hi,

> taas folks,
> given increasing demands (networking-midonet also will depend on it)
> i guess it makes sense to create newton branch.
> if we don't think it's mature enough, we can call it experimental or
> tech-preview or whatever.
> how do you think?

  It sounds nice idea.
  +1 (maybe "tech-preview")

  Regards,
  Soichi


hi,

On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton  wrote:

Please see - 
http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
Here we are pulling trunk as there is no stable version to use


thank you.
tap-as-a-service doesn't have any stable branches or releases yet.

taas folks,
given increasing demands (networking-midonet also will depend on it)
i guess it makes sense to create newton branch.
if we don't think it's mature enough, we can call it experimental or
tech-preview or whatever.
how do you think?



On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:

can you give me an example of breakage?

On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
> Hi,
>
> The change https://review.openstack.org/#/c/386845/ that landed yesterday
> has caused a breakage in stable/newton. This is due to the fact that the
> following projects do not have stable/newton tags:
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>
> Can the relevant release teams of the projects above please create the
> relevant tags.
>
> Thanks
>
> Gary
>
>
> __
> 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


__
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




__
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-dev] [neutron][taas] IRC meeting canceled (week of 11/21/2016)

[Soichi Shigeta]

 Hi,

  TaaS IRC meeting on this week being canceled
  because of national holiday in Japan.

  Regards,
  Soichi



__
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-dev] [neutron][taas] start time of weekly TaaS IRC meeting

[Soichi Shigeta]

 Hi Anil, Vinay, and folks,

I'd like to confirm the start time of weekly TaaS IRC meeting
  will be changed from 06:30 UTC to 05:30 UTC (adjustment for
  summer/daylight time) from next IRC on 13th Apr.

  Is this right?

  Regards,
  Soichi


__
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 of Dashboard for TaaS

[Soichi Shigeta]

 Hi,

Thank you for your comment.
  Yes, I know the Network Topology view was changed dramatically
  since Liberty.

  My design proposal is based on Kilo, currently.

  I personally prefer the view in Kilo because I can intuitively
  recognize tiered topology.

  Regards,
  Soichi


On 2016/03/16 17:56, Andreas Scheuring wrote:

Just to make sure you're aware of that - there is this new Curvature
Network Topology view since Liberty [1]. Maybe you want to integrate
with it as well...

[1] https://www.openstack.org/software/liberty/




__
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

[Soichi Shigeta]

 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

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

[Soichi Shigeta]

   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.

---
 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

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

[Soichi Shigeta]

 Hi,

  We find a problem that neutron ovs-agent deletes taas flows.

  o) Problem description:

 Background:
  At Liberty, a bug fix to drop only old flows was merged
  to Neutron.
  When ovs-agent is restarted, the cleanup logic drops flow
  entries unless they are stamped by agent_uuid (recorded as
  a cookie).

  bug: #1383674
   "Restarting neutron openvswitch agent causes network
hiccup by throwing away all flows"
   https://bugs.launchpad.net/neutron/+bug/1383674

  commit: 73673beacd75a2d9f51f15b284f1b458d32e992e (patch)

https://git.openstack.org/cgit/openstack/neutron/commit/?id=73673beacd75a2d9f51f15b284f1b458d32e992e


 Problem:
  Cleanup will be done only once, but it seems not to work
  until port configuration is changed.

  Therefore, taas flows will be deleted as follows:
   1. Start a new compute node or restart an existing compute node.
   2. Start taas agent on the compute node.
  --> taas agent creates flows
  (these flows are not stamped by using ovs-agent's uuid)
   3. Deploy a vm on the compute node.
  --> 1. neutron changes port configuration
  2. subsequently, the cleanup logic is invoked
  3. ovs-agent drops taas flows

 Specifically, following taas flows in br_tun are dropped:
 -
  table=35, priority=2,reg0=0x0 actions=resubmit(,36)
  table=35, priority=1,reg0=0x1 actions=resubmit(,36)
  table=35, priority=1,reg0=0x2 actions=resubmit(,37)
 -

 log in q-agt.log
 -

neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
cookie=0x0, duration=434.59s, table=35, n_packets=0, n_bytes=0,
idle_age=434, priority=2,reg0=0x0 actions=resubmit(,36)

neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
cookie=0x0, duration=434.587s, table=35, n_packets=0, n_bytes=0,
idle_age=434, priority=1,reg0=0x1 actions=resubmit(,36)

neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
cookie=0x0, duration=434.583s, table=35, n_packets=0, n_bytes=0,
idle_age=434, priority=1,reg0=0x2 actions=resubmit(,37)
 -


  o) Impact for TaaS:

 Because flows in br_tun are dropped by the cleanup logic, mirrored
 packets will not send to a monitoring vm running on another host.

 Note: Mirrored packets are sent in case of both source vm and
   monitoring vm are running on the same host. (not affected by
   flows in br_tun)


  o) How to reproduce:

 1. Start a new compute node or restart an existing compute node.
(Actually, restarting ovs-agent is enough.)
 2. Start (or restart) taas agent on the compute node.
 3. Deploy a vm on the compute node.
--> The cleanup logic drops taas flows.


  o) Workaround:

 After a vm is deployed on a (re)started compute node, restart taas
 agent before creating a tap-service or tap-flow.
 That is, create taas flows after cleanup has been done.

 Note that cleanup will be done only once during an ovs-agent is
 running.


  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.


 ---
 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

[openstack-dev] [neutron][taas] discussion about port security setting

[Soichi Shigeta]

 Hi,

   I have a discussion about port security setting.

 The recommended sequence of operations:
  1. Create a neutron port (with port security disabled).
  2. Launch the monitoring VM and attach it to this port.
  3. Create a tap-service instance whose destination port
 is the monitoring VM's port.

 But, a monitoring VM can receive mirrored packets without
 disabling port security in our site.

 What I found:
  1) In case of port security is enabled, entries to enforce
 anti IP spoofing are set into iptables of a linux bridge
 when a VM is launched.

 It looks like this:
  INPUT:
   Chain neutron-openvswi-s12345678-9 (1 references)
   RETURN  all  -- 192.168.1.10 anywhere  MAC aa:bb:cc:dd:ee:ff /* 
Allow traffic from defined IP/MAC pairs. */
   DROPall  -- anywhere  anywhere  /* Drop traffic without 
an IP/MAC allow rule. */


 Note that these entries are effective for only egress
 direction from the VM.

  2) On the other hand, mac learning mechanism will drop
 ingress packets if destination mac address doesn't match
 the monitoring VM.

 During tap-service creation process, mac address learning
 is disabled (at line 251 in 
neutron_taas/services/taas/drivers/linux/ovs_taas.py).

 Therefore, a monitoring VM can receive mirrored packets
 from source VMs.

 As a result, I think the 1st operation (disabling port security)
 is not required for a monitoring VM to receive mirrored packets.

 Is my understand right?

 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

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

[Soichi Shigeta]

 Thank you for your interest.

 The (dedicated) tunnel is used only to carry mirrored packets.
 Time stamp and order of a mirrored packet is the same as
 original packet.

 We may need to consider the issue you pointed out, but I
 think it's independent from whether dedicated tunnel is
 used or not.



Regarding tunnel for that. How do you ensure packet timestamps and
ordering?

Endre Karlson
19. nov. 2015 4.55 a.m. skrev "Li Ma" <skywalker.n...@gmail.com>:


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
<shigeta.soi...@jp.fujitsu.com> 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





__
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-dev] [neutron][taas] proposal: dedicated tunnel for carrying mirrored traffic

[Soichi Shigeta]

 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