06:30:13 <anil_rao> #startmeeting taas
06:30:14 <openstack> Meeting started Wed Dec  9 06:30:13 2015 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:30:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:30:17 <openstack> The meeting name has been set to 'taas'
06:30:23 <anil_rao> Hi
06:30:27 <kaz> Hi
06:30:42 <reedip> o/
06:31:51 <reedip> Shall we start?
06:31:56 <soichi> hi
06:31:59 <anil_rao> Sure
06:32:13 <anil_rao> We can start with the Agenda item for today's meeting
06:32:58 <soichi> we found ovs agent deletes taas flows when it is restarted.
06:33:11 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081709.html
06:34:07 <soichi> it is caused by the cleanup logic which was introduced at Liberty.
06:34:26 <soichi> $B!H(Bgraceful ovs-agent restart$B!I(Blink: https://git.openstack.org/cgit/openstack/neutron/commit/?id=73673beacd75a2d9f51f15b284f1b458d32e992e
06:34:35 <anil_rao> The problem is that ovs agent does not know about our (TaaS) existance
06:34:57 <yamamoto> hi
06:35:10 <soichi> i think so too
06:35:55 <anil_rao> We had discussed during the Tokyo summit to find a way to make OVS agent and perhaps other agents know about our resource requirements (OVS tables, vlan idsm, tunnel ids)
06:36:50 <anil_rao> I am not sure what is the best way to go about doing this. Any idea?
06:38:02 <yamamoto> be a part of ovs-agent (as an extension driver) so that we can use the same cookie?
06:39:08 <soichi> it can be one of the idea, i think
06:39:14 <yamamoto> soichi's idea to have a reserved cookie sounds reasonable for a short term.
06:39:51 <soichi> my idea is:
06:39:59 <soichi> 1. taas agent side: set $B!H(Btaas$B!I(B stamp (static string) in taas flows
06:40:07 <soichi> 2. ovs agent side: modify the cleanup logic not to drop flows stamped as $B!H(Btaas$B!I(B
06:40:42 <anil_rao> This sounds reasonable.
06:41:26 <anil_rao> We also need to ensure that the tunnel ids and vlan ids used by taas are not used by anyone else
06:42:28 <yamamoto> soichi: you are using some escape sequences.  maybe iso2022-jp?
06:43:13 <soichi> excuse me
06:45:21 <reedip> yeah, something is not right
06:45:36 <reedip> soichi : this is what we are getting
06:45:37 <yamamoto> soichi: are you going to submit ovs-agent patch?
06:45:44 <reedip> soichi :  2. ovs agent side: modify the cleanup logic not to drop flows stamped as $B!H(Btaas$B!I(B
06:46:09 <soichi> 1. taas agent side: set "taas" stamp (static string) in taas flows
06:46:20 <soichi> 2. ovs agent side: modify the cleanup logic not to drop flows stamped as "taas"
06:47:17 <yamamoto> i guess it doesn't need to be taas specific but the idea is fine.
06:47:22 <kaz> I'm planning to submit a patch.
06:47:41 <anil_rao> The tables used by TaaS in br-tun are currently documented in a TaaS consts file. Do you think we need to advertise this in a more global fashion?
06:48:15 <yamamoto> soichi: kaz: add me to the list of reviewers when submitting it
06:48:26 <soichi> sure
06:49:03 <yamamoto> anil_rao: it needs some coordination among wider audience, yes.  maybe start from having a comment in ovs constants module?
06:49:09 <soichi> anil_rao: i agree to advertise
06:50:24 <anil_rao> We also need to ensure that the priority of the TaaS flows in br-int is co-ordinated with other projects, so that proper ordering among flows is maintained.
06:53:00 <anil_rao> yamamoto: soichi: kaz: Do you guys have a good sense of how other projects are co-ordinating their flows in br-int for example?
06:54:30 <yamamoto> ~no idea off hand.
06:54:43 <soichi> currently, i don't know how other projects are coordinating
06:55:19 <kaz> i have no idea.
06:56:03 <anil_rao> For example, the flows related to anti-arp spoofing broke TaaS back in April. Our temporary workaround was to essentially raise our priority such that anti-arp spoofing is effectively disabled.
06:58:44 <anil_rao> Let's move to the next topic in the agenda
06:58:53 <yamamoto> my guess is other project is in similar positon.  fix when broke.
06:58:55 <soichi> excuse me,
06:59:11 <soichi> i$B!G(Bm not sure, but this issue should be registered as a bug?
06:59:19 <anil_rao> I think Service Chaining will most likely disrupt us
06:59:24 <soichi> i' m not sure, but this issue should be registered as a bug?
06:59:49 <yamamoto> which issue?
07:00:03 <soichi> ovs agent deletes taas flows
07:00:35 <yamamoto> yes.  at least as a taas bug.
07:00:35 <anil_rao> soichi: The thing is that ovs agent is unaware of TaaS at the moment.
07:01:00 <soichi> anil_rao: i see
07:02:09 <soichi> please move to the next topic.
07:02:33 <anil_rao> #topic gate-tempest-dsvm-tap-as-a-service is now voting
07:02:44 <yamamoto> i added it
07:02:52 <yamamoto> it's just an announcement
07:04:20 <reedip> Oh great, so tempest based tests
07:04:44 <yamamoto> yes, we currently have only a few api tests though.
07:06:04 <yamamoto> you can now start adding test cases.
07:06:50 <reedip> yamamoto: Yes, I will look into it... currently facing problems with the CLI though :(
07:07:20 <yamamoto> reedip: what problems?
07:07:22 <anil_rao> reedip: would you like to discuss them?
07:07:36 <reedip> yamamoto: the problem is related to devstack plugin I guess
07:07:57 <reedip> yamamoto: I was trying to link neutronclient to run the neutron-tap CLIs
07:08:06 <reedip> yamamoto: but they were returning 404
07:08:27 <reedip> yamamoto: then when I tried "taas" CLI, they returned the same thing
07:08:35 <yamamoto> they?
07:08:41 <reedip> taas CLIs
07:09:02 <reedip> First they -> neutron-tap CLIs; Second they -> taas CLI
07:09:19 <yamamoto> i think it worked when i wrote it.  i'll take a look later.
07:09:29 <reedip> seemed to me that the UROI end point was not working
07:09:52 <reedip> yamamoto: , anil_rao: also I had another issue, but this is related to integration with Neutron
07:10:01 <reedip> NeutronClient to be exact
07:10:26 <reedip> For Tap CLI integration with neutronclient, we are using the neutronclientextension
07:11:14 <reedip> Reference : http://docs.openstack.org/developer/python-neutronclient/devref/client_command_extensions.html
07:12:09 <reedip> As per the code, it assumes that the resource ( in our case tap_service) should be at the end point in the URI , which is not as we translate the URI as /v2_0/taas/tap-service
07:12:31 <reedip> * As per the NeutronClient Extension code*
07:13:46 <reedip> Other neutron extensions like firewall ( firewall_rule, firewall_policy), Load Balancer( health_monitor)  etc have their URIs and resource name separated with '_'
07:13:53 <reedip> taas has it with a '-'
07:14:15 <yamamoto> oh
07:14:34 <yamamoto> probably we should avoid '-'.
07:14:38 <anil_rao> reedip: if the convention is underscore that we should adhere to it
07:14:39 <reedip> I do not have much experience with the URI end point so not able to know why we have kept the translation as "tap-services" and not "tap_services"
07:15:28 <reedip> anil_rao, yamamoto: Just wanted to know how the URI is actually translated to tap-services. If you guys have any ideas, please let me know, or any reference where I can gain more understanding for this ?
07:17:10 <yamamoto> reedip: what do you mean by "translated"?
07:17:35 <reedip> yamamoto: How is Tap Service launches on /v2_0/taas/tap-services
07:17:46 <reedip> lauches-> launched
07:18:17 <reedip> I know this is not a query for the meeting, should be taken offline. But this is something which  is blocking the current code
07:18:48 <yamamoto> reedip: i got it.  let me look later.
07:20:13 <anil_rao> reedip: Did you modify the url string and remove 'taas' from it as discussed in last week's meeting
07:22:10 <reedip> anil_rao : The problem is that all the permutations are giving 404
07:22:34 <reedip> so I am not sure if it is due to devstack plugin, or due to the resource-URI conflict
07:23:09 <reedip> but the neutronclient is able to deploy Tap Service CLI ( entry point is working , just need to send the proper Request body to the URI now)
07:24:39 <reedip> anil_rao: BTW Sean Collins suggested we keep the URI as /v2_0/taas
07:24:50 <reedip> for proper demarcation
07:24:55 <reedip> between extensions
07:25:16 <reedip> And Fawas suggested the redeployment of the TaaS Spec
07:26:04 <yamamoto> reedip: it seems qos uses hyphens (eg. rule-types) so hyphens should not be a problem.
07:26:11 <anil_rao> Yes, we will try to get the TaaS spec reactivated soon.
07:26:51 <reedip> yamamoto : I am currently recreating the devstack environment. Will try to work on this , later this week
07:27:04 <anil_rao> Can we use /v2_0/taas annd still be part of the Neutron Client?
07:27:12 <reedip> anil_rao: Yes
07:27:19 <reedip> there is no problem with that
07:27:50 <anil_rao> That means that both the Neutron Client and the TaaS Client should work then.
07:27:54 <reedip> yamamoto: Just a query, is qos using the clientcommandextension which TaaS is using (I guess not )
07:28:33 <reedip> anil_rao: Yes ( and because both are failing, without any modification to the server code , so I am guessing the problem is somewhere in the URI itself)
07:28:43 <yamamoto> reedip: qos is built in
07:29:18 <reedip> yamamoto: I thought so, because then it is using the basic neutronclient architecture, which gives them the flexibility
07:29:26 <anil_rao> reedip: Let me examine this and get back to you.
07:30:02 <anil_rao> We are out of time.
07:30:14 <reedip> yamamoto: to have resources with '_' and URI with '-', thanks to https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py
07:31:22 <anil_rao> Let's continue this via email or next week?
07:31:43 <yamamoto> sure
07:31:45 <reedip> anil_rao : Sure ... glad to have this off my chest though :)
07:31:45 <yamamoto> bye
07:31:49 <soichi> bye
07:31:52 <anil_rao> bye
07:31:53 <kaz> bye
07:31:57 <anil_rao> #endmeeting