09:00:06 <oanson> #startmeeting Dragonflow
09:00:07 <openstack> Meeting started Mon Feb 13 09:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:09 <oanson> itamaro, hi
09:00:11 <openstack> The meeting name has been set to 'dragonflow'
09:00:15 <dimak> Hello all
09:00:26 <xiaohhui> hi
09:00:32 <oanson> dimak, xiaohhui, hi
09:00:32 <irenab> hi
09:00:36 <oanson> irenab, hi
09:00:59 <oanson> We'll wait another minute, and then start
09:01:02 <nick_ma> hi all
09:01:36 <dimak> I see we branched Ocata, 🎉
09:01:45 <oanson> nick_ma, hi
09:01:50 <oanson> dimak, don't ruin the surprise! :)
09:02:05 <oanson> #info itamaro dimak xiaohhui irenab nick_ma are in meeting
09:02:20 <oanson> #topic Announcements
09:02:39 <oanson> First off, a big welcome to xiaohhui, who should now be a core
09:02:52 <oanson> I say should, because I am not sure I updated the correct list :)
09:03:03 <nick_ma> conglats!!~~
09:03:06 <oanson> So xiaohhui, if your core powers are activated, let me know
09:03:09 <dimak> Congratulations!
09:03:28 <ishafran> Hi
09:03:30 <xiaohhui> Thanks guys!
09:03:38 <oanson> With great power comes great responsibility, so please try not to delete the project :)
09:03:51 <xiaohhui> It seems not work now.
09:03:59 <itamaro> congrats
09:04:00 <xiaohhui> I will try...
09:04:06 <xiaohhui> try not..
09:04:23 <irenab> xiaohhui, congrats!
09:04:24 <oanson> I updated the list about 10 minutes ago. If withing 24 hours it isn't working, I'll contact the infra guys for help
09:04:31 <oanson> within*
09:04:44 <xiaohhui> Thanks irenab
09:05:01 <nick_ma> xiaohhui: i checked the dragonflow-core list, you are there.
09:05:38 <oanson> Second item is, like dimak said, the new tag (3.0.0) and branch (stable/ocata) for Dragonflow is out
09:05:53 <xiaohhui> OK, thanks nick_ma
09:06:24 <xiaohhui> Does that mean we need to cherry-pick patches to ocata branch?
09:06:26 <oanson> There are some things that I think should be backported: lihi's ipv6 work, itamaro's l2 refactor (I was contacted and asked to have it backported)
09:06:46 <oanson> Yes. Patches that were merged and we want in ocata should be cherry picked
09:07:16 <nick_ma> ok.
09:07:17 <oanson> The branch mainly exists for 2 reasons: The Openstack-Ansible deployment patch was merged, and I wanted to make sure the matching Dragonflow version was tagged
09:07:46 <oanson> The second reason is that I want to start merging dimak's NB refactor, including migration, and I wanted to have a stable version without it
09:08:39 <dimak> I see one of the patches is already in
09:08:42 <dimak> Hooray
09:09:02 <oanson> The tag took place about 24 hours ago, with commit tag: Add rate limiter to icmp handler(DNAT)
09:09:13 <nick_ma> that's reasonable. currently there are too many big patches there.
09:09:20 <irenab> oanson, what feature are included?
09:09:35 <oanson> irenab, anything that was merged till yesterday :)
09:10:51 <dimak> Are we going to have release notes?
09:11:06 <oanson> dimak, only if someone writes them.
09:11:14 <oanson> We should start keeping track from this point on
09:11:50 <oanson> That is, any patch that changes API, adds a feature, or changes deployment, should have a release not
09:12:08 <oanson> nick_ma added the reno framework, so it should be easy to do that from now on
09:12:10 <irenab> note?
09:12:23 <nick_ma> yes
09:12:27 <oanson> irenab, sorry?
09:12:49 <xiaohhui> That could be applied to the review process, right?
09:12:53 <irenab> nver mind, was not sure if you mean not ore note
09:13:09 <oanson> xiaohhui, yes
09:13:14 <oanson> irenab, yes, 'note'
09:14:11 <oanson> Anything else here?
09:14:59 <oanson> #topic Roadmap
09:15:44 <oanson> IPv6 - lihi uploaded a WIP here: https://review.openstack.org/#/c/431566/ . She's out this week, and next week is the PTG, so I don't think she'll be able to update it again soon
09:15:57 <oanson> Except that she updated it this morning :)
09:16:07 <oanson> So I guess she is updating it
09:16:35 <oanson> The patch adds IPv6 support to the security groups, which (I think) is the last big obstacle for IPv6 support
09:16:36 <irenab> oanson, is it for review already?
09:16:56 <oanson> It fails py35, so only if you have time
09:17:05 <irenab> ok
09:17:40 <oanson> NB refactor - dimak, you want to take this one?
09:18:03 <dimak> I see that you took the first framework patch
09:18:29 <dimak> I'm working mainly on SFC while using the framework as basis to weed out more issues
09:18:45 <dimak> but I didn't come across anything I hadn't fixed yet
09:18:55 <oanson> That's good
09:19:06 <dimak> So for now I'm waiting for more feedback
09:19:14 <dimak> And keep focusing on SFC
09:19:14 <oanson> You also want to take this chance to talk about SFC?
09:19:30 <dimak> I got it to work last week on a single node
09:19:45 <dimak> Without treating most of the edge cases
09:19:58 <irenab> I have one comment about NB refactor
09:20:15 <oanson> irenab, shoot
09:20:16 <dimak> And I'm writing some tests now before I proceed with tackling the apps
09:20:41 <irenab> one more patch is needed to add dev doc guide for adding new models
09:21:00 <dimak> I'll draft one up :)
09:21:07 <irenab> thanks
09:21:10 <oanson> thanks
09:21:26 <oanson> dimak, re sfc, what service functions are you testing?
09:22:10 <dimak> I am working with a fullstack testing framework so I built something simple by using policy
09:22:15 <dimak> its enough for now
09:22:37 <oanson> Cool
09:22:45 <dimak> Simple packet modification and return to the next hop
09:22:48 <dimak> or SF
09:23:08 <dimak> I'll upload the tests sometime today, everyone can take a look
09:23:38 <oanson> Very cool!
09:23:49 <oanson> Anything else for NB refactor and SFC?
09:23:59 <dimak> Nothing for now
09:24:05 <oanson> All right.
09:24:23 <oanson> As far as I know, there is no update regarding TaaS and chassis/service health
09:24:42 <oanson> Anonymous/distributed snat - ishafran, you want to take this?
09:24:50 <ishafran> ok
09:25:07 <ishafran> I have 2 ongoing code reviews
09:25:25 <ishafran> one is in more mature state
09:25:30 <ishafran> https://review.openstack.org/#/c/431422/
09:25:58 <ishafran> I need to make small functional changes hopefully today for both patches
09:26:25 <ishafran> And I will be ready for next review cicle
09:26:46 <ishafran> questions ? :)
09:27:08 <dimak> I'll take another look at the patches today
09:27:25 <oanson> Sounds good
09:27:39 <irenab> regarding the https://review.openstack.org/#/c/431423/
09:27:40 <oanson> ishafran, if you're respinning, could you also add a release note?
09:28:10 <ishafran> note in commit itself ?
09:28:32 <irenab> We discussed the approach at the previous patch, but my concern is still present. I do not think that the sNAT change should be reflected durectly in the ml2 mech_driver
09:29:14 <oanson> ishafran, using 'reno', you can create a release note file. I want it to mention the new feature, as well as that it requires OVS 2.6
09:29:24 <ishafran> irenab: yes I remember this. We need a time to talk about it
09:29:31 <oanson> but this can be done in another patch, so as not to delay this one
09:29:45 <irenab> another concern is about modifing the port object with port profile stuff that is not present in neutron, but sent to DF
09:30:14 <irenab> ishafran, great. Lets chat after the meeting
09:30:31 <irenab> just wanted to see if there are more opinions on this
09:30:41 <ishafran> irenab: for the profile change. its DF specific feature so I don't see a problem there
09:31:41 <irenab> ishafran, consider the case where we need to align DF DB with neutron one
09:32:20 <ishafran> this is a very long shot :)
09:32:45 <irenab> it may happen due to some cases where DF DB is out of sync, and we could use sync DB utility to align both, but adding neutron side applicative logic, will make it difficult
09:33:26 <oanson> ishafran, I don't think it's such a long shot
09:33:41 <oanson> And being able to do so adds stability to our system
09:34:27 <ishafran> updating neutron DB cause kind of recursive update ... lets talk about it
09:34:40 <oanson> Sure. We can take it offline
09:34:51 <irenab> ishafran, I would prefer not changing port object at all
09:35:09 <irenab> sure, let discuss offile
09:35:26 <oanson> That gets us to the API feature
09:35:31 <nick_ma> imo, if we don't check the port object, it should be no problem.
09:35:51 <nick_ma> s/check/change
09:37:03 <oanson> Yes. That info has to be placed somewhere, but I agree the port object shouldn't be modified
09:37:18 <oanson> irenab, you want to talk about the API?
09:37:32 <irenab> oanson, yes
09:38:00 <irenab> nothing to update actually. The spec is up to review. I added few clarifications based on the recent reviews
09:38:15 <oanson> Note, the spec is here: https://review.openstack.org/#/c/418842/
09:38:47 <irenab> Please check if there are some missing requirements that to be added
09:39:35 <oanson> irenab, will the api be pending migration to the new NB? i.e. change the models like in the 'chassis' case?
09:39:53 <irenab> oanson, yes
09:40:32 <yuli_s> hello
09:40:43 <irenab> it does not make sense to base on the previous modesl. json models can be helpful for the automation of the API processing
09:40:44 <oanson> yuli_s, hi
09:40:57 <oanson> irenab, all right
09:41:22 <oanson> We should get an etherpad up with the modules that have to be migrated.
09:41:44 <oanson> Once someone takes a model, put your name next to it. Once it is merged, we'll strike-through the model name
09:41:45 <dimak> Thats a good idea
09:41:45 <nick_ma> good idea.
09:41:54 <irenab> +1\
09:41:54 <oanson> dimak, you want to create the etherpad?
09:42:04 <dimak> Sure, I'll do that today
09:42:27 <oanson> Great. Post a link in the channel once you have a link, so it'll be recorded somewhere
09:42:50 <oanson> yuli_s, you arrived just in time. Want to talk about TaaS?
09:42:51 <dimak> Ok
09:43:13 <yuli_s> I created a very simple plugin
09:43:25 <yuli_s> that receives taas events
09:43:58 <yuli_s> I started to port it to use the new API that Dima is working
09:44:07 <yuli_s> on
09:44:25 <oanson> That's a good idea.
09:44:43 <yuli_s> besides I was working a new performance test project
09:45:22 <irenab> yuli_s, new plugin on the neutron or DF side?
09:46:22 <yuli_s> it should work in both cases
09:46:25 <irenab> on neutron I believe it should be new driver for the TaaS plugin
09:46:48 <yuli_s> the one that receives messages should push them to db using new API
09:47:06 <yuli_s> and the implementation part that applies the rules
09:47:08 <irenab> yuli_s, link to the patch?
09:47:20 <yuli_s> running as part of df process
09:47:25 <yuli_s> it is will not ready
09:47:45 <yuli_s> as I had to switch to performance test project
09:48:05 <irenab> ok, got it
09:48:25 <yuli_s> i found and fixed a number of small issues in multi-node deployment
09:48:44 <oanson> That reminds me, we need to see if we can set up a multinode gate
09:49:03 <dimak> oanson, maybe we can use ODAD
09:49:09 <dimak> OSAD
09:49:22 <yuli_s> 2 patches had been merged already
09:49:24 <oanson> dimak, you're gonna have to give me more than an acronym :)
09:49:33 <dimak> ansible
09:50:04 <oanson> dimak, yes. That's one option that will definitely be added. I want to make sure we don't break the ansible deployment on our end as well
09:50:20 <irenab> OSAD?
09:50:42 <oanson> That we don't cause a degradation, that is. Shouldd't be too difficult, as openstack-ansible already have a gate job running for us on openstack-ansible-os_neutron
09:51:10 <oanson> Open-Stack Ansible Deployment?
09:51:16 <dimak> yes
09:51:50 <oanson> In any case, I am also thinking of taking up TripleO this cycle. This should allow us to test provider nets as well.
09:53:25 <irenab> oanson, can you elaborate on TripleO?
09:53:41 <oanson> My understanding is that it's for running openstack on openstack
09:54:24 <irenab> yes, it is. So what is your plan with regards to DF?
09:54:59 <oanson> We'll use the lower openstack deployment (it has a name, but I forgot it now) to set up the network for the upper openstack deployment (also has a name). The upper openstack deployment will be Dragonflow. The lower deployment will provide the network needed to have provider net (flat and vlan), VxLAN, and maybe dNAT and  sNAT.
09:55:10 <oanson> Yes, this took longer to write than I expected :)
09:55:31 <nick_ma> it can help you deploy neutron with dragonflow and check whether it is working for undercloud networking.
09:55:50 <oanson> That's also an interesting use case. I haven't thought of that
09:56:09 <oanson> undercloud and overcloud. Those are the names :)
09:56:19 <nick_ma> :-)
09:57:12 <oanson> One more item, before we break off to dinner - next week there will be no meeting due to the PTG
09:57:12 <irenab> the undercloud can be DF network too
09:57:27 <oanson> irenab, yes, that's what nick suggested.
09:57:35 <oanson> That would be a 2-in-1 testing environment :)
09:57:37 <irenab> oanson, any update on VLAN aware VMs?
09:57:57 <oanson> irenab, none as of yet. I'll try contacting rajivk offline. I didn't see him around lately
09:57:58 <noops> Hey tomorrow ...do we have meeting?
09:58:43 <oanson> That means our next meeting is on the 27th of Feb., two weeks from now
09:59:00 <oanson> I'll also send a reminder in the mailing list towards the end of the week
09:59:20 <oanson> All right, that's our time.
09:59:25 <oanson> Anything last-minute?
09:59:49 <nick_ma> ok.
10:00:05 <oanson> Great! Thanks, everyone!
10:00:09 <oanson> #endmeeting