09:01:29 <oanson> #startmeeting Dragonflow
09:01:30 <openstack> Meeting started Mon Feb  6 09:01:29 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:35 <openstack> The meeting name has been set to 'dragonflow'
09:01:43 <oanson> All right, who's here for the weekly?
09:01:47 <lihi> Hi
09:01:47 <dimak> Hello
09:01:47 <xiaohhui> hello
09:02:09 <oanson> Surprisingly, if I start the meeting in the correct channel, everyone is here :)
09:02:27 <irenab> hi
09:02:35 <oanson> We'll wait another minute, and then we'l start
09:03:13 <oanson> All right
09:03:20 <oanson> I'm going to veer of the agenda for a second
09:03:41 <oanson> I got the Dragonflow logo from the illustration team
09:03:51 <oanson> lihi should have the link read any second now
09:04:02 <lihi> http://www.tiikoni.com/tis/view/?id=436a5d8
09:04:16 <lihi> :)
09:04:26 <oanson> What do you guys think?
09:04:56 <irenab> looks like question mark up down
09:05:02 <xiaohhui> it looks like a sea horse to me...
09:05:06 <lihi> If you want to give direct feedback on your mascot to the designers, go here: http://tinyurl.com/OSmascot
09:05:27 <oanson> It is a sea horse, yes.
09:05:49 <oanson> I understood that we had to choose an animal that was real, not manmade, and not extinct
09:05:59 <oanson> So gsagie, the former PTL, chose a sea horse
09:06:01 <lihi> Well, a sea horse kinda looks like a question mark up down
09:06:12 <xiaohhui> What is this log for?
09:06:25 <xiaohhui> log->logo
09:06:42 <oanson> I think it is going to replace the network cable dragon logo we have now on all our project docs
09:07:24 <xiaohhui> I see
09:08:29 <oanson> I think maybe ask it to be thinner, and have the spikes on the back more pronounced. Might make it a bit more dragon-ish
09:09:50 <lihi> It might be nice
09:10:50 <oanson> All right. So as lihi said, you can also give your comments directly here: http://tinyurl.com/OSmascot
09:10:53 <oanson> Let's move on
09:11:01 <oanson> #topic Roadmap
09:11:13 <oanson> IPv6 - lihi, any updates?
09:12:05 <lihi> I had some unexpected isues with the unit tests, but I should  be done soon. I'm also refactoring a bit the sg code. It contains a lot of duplicate code
09:12:59 <oanson> lihi, I see. Well, any cleanup to the code is appreciate as well.
09:13:09 <oanson> Do you think it will be done by the PTG?
09:13:24 <lihi> yes
09:13:43 <oanson> Cool.
09:14:07 <oanson> NB refactor - dimak, I saw there are a lot of patches up
09:14:16 <oanson> They also look like they are coming along nicely.
09:14:30 <dimak> yeah, primarily waiting for your +1's (or -1's)
09:14:42 <oanson> Since this is a major overhaul, I'd like everyone to put their stamp of approval before we move forwards with this
09:15:07 <oanson> I know it's a lot of code, but dimak did break it down for us, so it should be ... manageable :)
09:15:25 <oanson> dimak, I also understand you are building the SFC on top of it?
09:15:34 <dimak> Yeah, I also postponed some stuff
09:15:55 <dimak> Yes, I'm working primarily on SFC over the new models now
09:16:04 <dimak> trying to get the fullstack test I have to work
09:16:42 <oanson> We will need to move the models from the legacy structure to the refactored structure. Is that something you can do, or are you fully booked with SFC?
09:17:04 <dimak> I can do that as soon as we converge on the basic framework
09:17:19 <irenab> oanson, me and dimak started to check openAPI spec to prepare automation for the schema generation
09:17:21 <oanson> Great.
09:17:43 <oanson> irenab, sounds good. How's that going?
09:17:59 <dimak> Yeah, once we have all the models in the new format we can relatively easily generate large parts of the api declaration
09:18:36 <irenab> we need to see if to keep model definition as a single piece or split db and api parts
09:18:47 <oanson> That's our REST API out-of-the-box?
09:19:06 <oanson> In general, we'll want to split the models of to be by topic
09:19:08 <irenab> yes
09:19:23 <oanson> e.g. routers and l3 in one file, floating IPs in another, BGP (when it lands) in another, etc.
09:19:34 <irenab> oanson, feature
09:19:43 <irenab> topic is abit overloaded term
09:19:51 <oanson> Yes, feature :)
09:20:24 <oanson> Which reminds me, the spec was merged yesterday evening
09:20:35 <irenab> seems that openAPI spec documentation has nice tagging feature, to filter relevant APIs by tags
09:20:45 <oanson> (Or this morning, according to time difference)
09:20:50 <dimak> oanson, we should also examine the translation between db-stored data and api objects
09:20:54 <irenab> so we can use tag = feature
09:21:02 <oanson> irenab, that's a good idea
09:21:05 <oanson> dimak, what do you mean?
09:21:13 <dimak> because api is expected to be backwards compatible
09:21:29 <dimak> and some things present in api objects we might not want in the database
09:21:38 <oanson> dimak, yes, but only after the first version we have it
09:22:00 <oanson> It won't have to be backwards compatible to a time before API, and by the looks of it, it won't make it into Ocata
09:22:13 <dimak> yeah
09:22:19 <oanson> There's just too little time to stabalise it, especially if we will need backwards compatibility
09:22:33 <dimak> I just meant that db and api might need to diverge at some point
09:23:39 <irenab> dimak, +1
09:24:03 <oanson> I guess we'll have to cross that bridge when we get there. We have to minimise API breaking changes, and see how to support backwards compatibility if we have to.
09:24:23 <oanson> Neutron have a deprecation system, but I don't like it very much...
09:24:40 <oanson> Seeing as we were on the broken end of such a change a few times :)
09:24:52 <irenab> oanson, we just need to keep in mind the backward compatibility, not to break existing clients after first version is released
09:25:04 <oanson> Yes.
09:25:32 <oanson> Anything else for API?
09:25:43 <irenab> openAPI also provides tools to generate clients in different launguages
09:26:03 <oanson> That's a powerful feature!
09:26:35 <irenab> so once we are doen with model definition, seems the rest should not be too time consuming
09:26:54 <oanson> That was the plan when we started :)
09:27:05 <dimak> We'll still have to implement some kind of server to translate api to nb db
09:27:34 <oanson> dimak, doesn't openAPI provide that too?
09:27:43 <irenab> please check the latest spec version and my replies to recent comments
09:28:00 <dimak> oanson, You can generate a server with stubs
09:28:30 <dimak> I don't we'd like rebasing on top of it each time
09:28:47 <oanson> We'll have to see what it provides exactly, then. The way we use it, the implementation of these stubs may be automated.
09:28:50 <dimak> maybe better to write someothing of our own with some magic to translate paths to models automatically
09:29:01 <oanson> dimak, no. These things should change only if the models change
09:29:29 <oanson> dimak, possibly. I was playing around with python bottle, which looks like it can do it :)
09:29:44 <oanson> But one step at a time
09:29:56 <dimak> oanson, we should also note that api spec is dependent on the models loaded
09:30:12 <oanson> dimak, sorry?
09:30:23 <dimak> We talked about dynamic loading of features
09:30:34 <oanson> Ah. Yes. Of course.
09:30:36 <dimak> e.g. apps + service plugins
09:30:48 <oanson> We have to support API for all loaded models, and not support API for models that aren't loaded.
09:31:03 <dimak> this means that the set of models we support is different for each configuration
09:31:16 <dimak> what about 3rd party?
09:31:32 <oanson> Yes. But all have to be implemented, and only those that are loaded, should be supported by the API
09:32:00 <dimak> I meant that if I have an out-of-tree feature I want to support
09:32:01 <oanson> For 3rd party, we will have to provide some way to extend our API. If everything is done automagically, that wouldn't be a problem.
09:32:04 <irenab> we will havCen we delay a bit the dynamic loading, at least till we have basic stuff working?
09:32:36 <irenab> Can we delay a dynamic part?
09:32:50 <oanson> irenab, no worries. Right now we're only planning ahead. It's not like dimak already has it all written. (dimak, right?)
09:33:11 <dimak> heh, not yet
09:33:15 <irenab> oanson, I won't be suprised to see it during the afternoon :-)
09:33:39 <oanson> He said he doesn't have it written yet. So it will take him at least until
09:33:41 <oanson> the evening
09:34:03 <oanson> All right. Let's move on.
09:34:21 <oanson> distributed sNAT
09:34:47 <oanson> the second implementation has been uploaded. But I will talk with ishafran. It looks like he squashed the two commits.
09:34:55 <oanson> I will ask him to un-squash them.
09:35:14 <oanson> TAP-as-a-Service - yuli_s are you in?
09:35:52 <dimak> It looks like the snat patch is on top of the abandoned patch
09:36:22 <oanson> dimak, that sounds strange. But I'll ask ishafran organise it so it's digestible
09:36:40 <irenab> I also talked with ishafran regarding the ml2 driver change, I proposed different approach and we will continue the discussion
09:36:58 <oanson> irenab, you want to elaborate?
09:37:32 <oanson> ishafran, right on time :)
09:37:50 <ishafran> Hi
09:37:59 <irenab> the lates patch includes changes to  ml2 df driver, I suggested a bit different approach that does not require ml2 driver modification.
09:38:19 <itamaro> Hi
09:38:20 <irenab> but I think we still need some time to discuss it offline
09:39:03 <oanson> Sure.
09:39:04 <irenab> in short, get port_created notification outside of the ml2 driver and create compute tenant gw port
09:39:30 <oanson> irenab, as in a second mechanism driver?
09:39:46 <irenab> oanson, more like l3 service
09:40:10 <irenab> but maybe another l2 driver can work as well
09:40:33 <oanson> If Neutron supports that, it would be great. I though ports and l2 were only accessible via the mechanism driver?
09:40:41 <ishafran> I am actually did not find alternative pre/post commit mechansim except mech_driver since our talk yesterday
09:40:59 <irenab> ishafran, will show you what I meant
09:41:11 <oanson> All right. As irenab said, let's take this offline.
09:41:32 <oanson> Should we continue?
09:41:52 <ishafran> lets take tit offline
09:42:44 <oanson> Tap-as-a-Service - I understand that yuli_s is setting up a taas environment, and then he'll start the implementation
09:42:57 <oanson> (He is also working with the Rally croud on something else)
09:43:07 <oanson> crowd*
09:43:19 <oanson> All right. Anything else for roadmap?
09:44:05 <oanson> #topic Open Discussion
09:44:09 <oanson> The floor is for the taking
09:44:31 <xiaohhui> I have one question about storing port unique key in reg
09:44:50 <xiaohhui> in table 0 we store it in reg6, but in all other tables we store it in reg7
09:45:08 <xiaohhui> and the value in reg6 seems only be used by metadata app
09:45:18 <dimak> I though it reg6 is used for source port and reg7 for the dest
09:45:21 <oanson> reg6 is the source port's ID
09:45:28 <oanson> dimak beat me to it :)
09:45:44 <xiaohhui> I see it
09:45:51 <xiaohhui> thanks guys
09:45:51 <oanson> The thing is, only metadata actually needs to know the source (So far)
09:46:31 <oanson> In theory, I guess reg6 can be winged for the in_port (like in port sec)
09:47:22 <oanson> The floor is free again.
09:48:14 <oanson> All right. Thanks everyone.
09:48:29 <oanson> #endmeeting