09:00:52 <oanson> #startmeeting Dragonflow
09:00:53 <openstack> Meeting started Mon Jan 16 09:00:52 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:56 <openstack> The meeting name has been set to 'dragonflow'
09:01:03 <dimak> Good morning
09:01:07 <lihi> Hi
09:01:13 <hshan> hi~
09:01:17 <rajivk> Hi
09:01:39 <oanson> Al right. Let's begin
09:01:44 <irenab> hi
09:01:49 <oanson> Actually, before we begin.
09:01:56 <itamaro> hi
09:01:57 <oanson> Please note that our gate is broken again :)
09:02:23 <oanson> Looks like Neutron removed the tenant_id from their objects.
09:03:11 <oanson> I think it's from patch https://review.openstack.org/#/c/382659
09:03:22 <oanson> I am looking at it, but if anyone has any info, please share :)
09:03:30 <oanson> Now we can begin.
09:03:37 <dimak> I'll look into it :)
09:03:48 <oanson> #info dimak lihi hshan rajivk irenab itamaro in meeting
09:04:02 <ishafran> me too
09:04:04 <oanson> dimak, note I uploaded a test here: https://review.openstack.org/420587 but it's just a test
09:04:09 <oanson> #info ishafran is also in meeting
09:04:12 <oanson> #topic roadmap
09:04:29 <oanson> IPv6. lihi, the floor is yours
09:04:49 <lihi> I've stopped working on the Router Discovery for now. I'm having issues detecting the socilitations when there are multiple routers, and advertising the same response as the periodic router advertisemts messages.
09:04:58 <lihi> So I've started to work on the DHCPv6
09:05:09 <yuli_s> oanson, i think they use project_id instead of tenant_id
09:05:18 <irenab> lihi: can you please elaborate on the issues you see
09:05:25 <oanson> yuli_s, yes. I gathered that too. That's what I put in the test
09:05:32 <yuli_s> ok
09:06:23 <nick-ma> hi
09:06:30 <oanson> nick-ma, hi
09:06:35 <oanson> #info nick-ma also in meeting
09:07:21 <lihi> The requests are sent to the broadcast link local address, and I can't build the response in the flows the same way I did in the flows.
09:07:42 <lihi> I still need to think how to do it properly
09:08:13 <irenab> how does it work with ref. impementation?
09:08:51 <oanson> irenab, I don't think ref implementation uses responders
09:09:07 <oanson> lihi, I am not sure I understand the issues you're running into
09:09:53 <lihi> All the requests are send to the broadcast linklocal address. The address is the same for all routers
09:10:11 <lihi> Usually, each router that receives the messages response.
09:10:25 <oanson> You can detect your network using the 'metadata' field in OVS
09:10:36 <oanson> This way you know which router interfaces need to respond
09:11:03 <lihi> OK, I will look into it
09:12:02 <lihi> I wasn't sure what to do, so I've started working on the DHCPv6 in the meanwhile. But I think this might help
09:12:23 <oanson> Both directions are important
09:12:54 <lihi> yeah I know :)
09:13:00 <oanson> All right
09:13:14 <oanson> If you have any issues, feel free to ask in the channel
09:13:19 <oanson> NB refactor
09:13:26 <oanson> dimak, you want to update?
09:13:38 <dimak> Yeah
09:14:07 <dimak> I think we are starting to have a better picture of how everything should look and be used
09:14:40 <oanson> All right.
09:14:43 <dimak> I've talked to Irena and Omer and we decided to try dropping CRUD layer\
09:15:12 <dimak> And add custom functionality to NB api operations with hooks
09:15:33 <dimak> we still have to update the spec (if we see that it works well for us)
09:15:59 <dimak> Other than that, jsonmodels requirements is in!
09:16:23 <lihi> What was the issue with CRUD?
09:16:24 <dimak> I've asked library maintainer to roll out a version with my changes into PyPI
09:16:48 <dimak> We tried to add CRUD logic to each model
09:17:04 <oanson> All right. I'll update the spec probably tomorrow. I'd ask that you'd all vote so we can get it in
09:17:09 <dimak> And we wanted to add shared model functionality with mixins
09:17:26 <dimak> (e.g. Mixin that adds unique key or version fields)
09:17:48 <dimak> And some fields might require special treatment in CRUD layer
09:18:39 <oanson> Anything else for NB refactor?
09:18:40 <dimak> But if we add a CRUD layer to each mixin that requires it, and then use several mixins, deciding on ordering that CRUDs are called are not that simple or readable
09:18:45 <dimak> Be patient :P
09:18:56 <oanson> Sorry. Didn't know you had such a big buffer
09:19:05 <oanson> You should limit your mtu :)
09:19:32 <dimak> We though of exploring hooks because they sit on the models/mixins themselves and obey to super() rules
09:20:12 <dimak> lihi, I can draw up some more elaborate example with code why we wanted to avoid CRUD layer when using mixins
09:20:47 <itamaro> I will be glad to sit in too
09:20:50 <itamaro> :)
09:21:00 <nick-ma> it may be better to update the spec along with these pictures.
09:21:03 <dimak> Other than that, I want to see if the chassis refactor works (fullstack-wise)
09:21:17 <lihi> yeah, that would be nice
09:21:18 <irenab> lihi: in short it required to count on the model inheritance order, which is really bad practice
09:21:45 <lihi> ok, makes sense
09:22:30 <oanson> dimak, could you prepare these diagrams, I'll add them to the spec?
09:22:37 <dimak> Sure
09:22:56 <dimak> I'll post them in #dragonflow too to facilitate some discussion :)
09:23:08 <dimak> Oh
09:23:30 <dimak> jsonmodels maintaner just pushed a new version :)
09:23:50 <oanson> Great!
09:23:53 <lihi> :)
09:23:55 <irenab> looks like you are their super user :-)
09:24:02 <nick-ma> good news.
09:24:03 <nick-ma> ~
09:24:19 <oanson> All right. dimak, is there any more?
09:24:32 <dimak> I think thats all
09:24:41 <oanson> Chassis
09:24:53 <oanson> Chassis health
09:25:07 <oanson> rajivk, anything to update?
09:25:18 <rajivk> I have put patch for it.
09:25:31 <oanson> This one: https://review.openstack.org/#/c/415997/ ?
09:25:46 <rajivk> yes
09:26:05 <rajivk> Once i get enough comment and it get freeze.
09:26:25 <rajivk> I will add UT and commands of df-db to service enable and disable.
09:26:58 <rajivk> Do you think, current patch is ok or does it require major changes?
09:27:11 <oanson> From what I saw, there are a few minor things
09:27:15 <dimak> rajivk, I think df-db is getting a bit too overloaded
09:27:35 <oanson> dimak, on the other hand, your work should fix that :)
09:27:44 <rajivk> I think, there is a specs for dragonflow-api.
09:27:54 <oanson> And that is the only CLI utility we have for the moment
09:28:01 <rajivk> may be i should add API directly in that specs.
09:28:22 <oanson> Yes. This should be a model-API
09:28:31 <dimak> oanson, we can just rename it to df-client or something 😉
09:28:43 <irenab> so ‘service’ will be a model object?
09:28:56 <rajivk> yes
09:28:57 <oanson> IIRC, that's how it is in the spec
09:29:18 <rajivk> dimak, +1
09:29:29 <rajivk> I think, df-db will become too complex soon.
09:29:39 <rajivk> If we keep on adding functionality.
09:30:08 <irenab> dimak: df-client will be confising, we will need it once add proper API
09:30:13 <nick-ma> i suggest to add a subproject named python-dfclient for the api spec.
09:30:27 <oanson> The CLI requirement is in the API spec. I think df-db will become a troiubleshooting tool. And we will have a cli client for the northbound stuff
09:30:39 <oanson> Not a bad idea
09:30:57 <irenab> nick-ma: please check the spec and post comments for what you think is missing
09:31:04 <nick-ma> but it is just cli implementation.
09:31:14 <nick-ma> the api is belonging to df project as the rest layer.
09:31:23 <nick-ma> irenab: sure.
09:31:23 <oanson> In general, maybe we should start splitting things off into smaller subprojects. e.g. specific database drivers, external applications (once the NB refactor is complete)
09:31:44 <rajivk> we will have to integrate with keystone as well.
09:31:52 <nick-ma> project splitting is another big topic to discuss.
09:31:56 <rajivk> If we provide support for APIs.
09:31:59 <nick-ma> maybe in another spec.
09:32:01 <oanson> nick-ma, that's something I wanted cleared up - is the API REST, or a python library with REST on top?
09:32:05 <irenab> oanson: by subpojects you mean diferent repos?
09:32:05 <oanson> irenab, ^^^^
09:32:05 <irenab> 
09:32:32 <oanson> Like Neutron have a stadium, we'll have a... errr.. theatre...
09:32:35 <nick-ma> oanson: in my opinion, it should be the standard api framework as nova, cinder, etc.
09:32:56 <nick-ma> rest api with python library.
09:32:59 <oanson> You mean REST, and the CLI client will send REST requests to the API?
09:33:00 <irenab> oanson: we need to have both, REST API and pythion clinet
09:33:08 <oanson> nick-ma, beat me to it :)
09:33:18 <nick-ma> irenab: yes
09:33:30 <oanson> irenab, no argument. I wanted to verify where everything connects
09:34:19 <irenab> oanson: will upload the updated spec version soon, hope it will get more clear
09:34:27 <nick-ma> ok.
09:34:35 <oanson> irenab, great, thanks!
09:34:59 <oanson> rajivk, one more questions: How do you plan to do the UT?
09:35:13 <oanson> And do you plan to add fullstack tests?
09:36:03 <rajivk> No, idea. Give me ideas :)
09:36:17 <rajivk> Which is the best for the project?
09:36:59 <oanson> I guess you could set up something inheriting Service, and see if the NB database is updated (fullstack test)
09:37:19 <rajivk> ok, i will start looking at it.
09:37:42 <oanson> Thanks. This can be done as a separate patch if you'd like, since the main patch already seems to be very advanced
09:37:58 <rajivk> ok, i will do it in other patch.
09:38:04 <oanson> Great. Thanks!
09:38:07 <oanson> Anything else on this topic?
09:38:19 <rajivk> no, that's all.
09:38:29 <oanson> TAPaaS - yuli_s, any updates?
09:38:42 <yuli_s> Yes
09:38:52 <yuli_s> today I submitted first patch
09:38:59 <yuli_s> to make ids more sparse
09:39:35 <oanson> Looks promising.
09:39:42 <yuli_s> after that I will start to other parts
09:39:48 <yuli_s> ;)
09:40:06 <oanson> Great. Only downside is that I now need to re-memorise all the table numbers :)
09:40:39 <yuli_s> we use constants in code, so, I guess it will not be that hard
09:41:03 <rajivk> I saw one constants, can we make enums?
09:41:08 <oanson> Yes. If we behaved well, this patch should go very smoothly.
09:41:17 <yuli_s> I am also working on submitting the rally project I mare
09:41:37 <yuli_s> I am also working on submitting the rally project I was working on too
09:42:15 <oanson> rajivk, sure. What are the benefits?
09:42:23 <oanson> yuli_s, great!
09:42:28 <itamaro> Would you like to discuss how we can do connectivity tests using naitive DF api only (openstack less)?
09:42:53 <yuli_s> rajivk, send you comments in the patch, I think we will continue from their
09:43:12 <rajivk> ok
09:43:13 <yuli_s> rajivk, https://review.openstack.org/#/c/420602/
09:43:16 <irenab> itamaro: native API is only speced now
09:43:40 <oanson> itamaro, yes, but let's wait for the open discussion
09:43:40 <irenab> # link https://review.openstack.org/#/c/418842/
09:43:42 <itamaro> tests are not even there
09:44:12 <itamaro> ok
09:44:22 <oanson> sNAT application
09:44:34 <oanson> ishafran, any updates?
09:44:42 <oanson> Please note that the patch is here: https://review.openstack.org/#/c/417799/
09:44:50 <ishafran> I posted first implementation + UT on review
09:45:04 <ishafran> Since then no update
09:45:56 <oanson> All right. I left some comments there. Please review.
09:46:03 <ishafran> ok
09:46:17 <oanson> Did you get a chance to try what I suggested regarding passing the zone as an immediate value (and not via the regs)?
09:46:26 <oanson> I'm curious to know if that worked and could be done
09:46:48 <oanson> Please also rebase the spec, so that we can vote on it
09:47:00 <ishafran> my environment is broken now due to rebase to DF master, so still not tried it
09:47:25 <oanson> All right. Please keep me posted - as I said, I am very curious :)
09:47:34 <ishafran> ok
09:47:43 <oanson> Anything else on sNAT?
09:47:49 <oanson> Anything else for roadmap?
09:48:12 <irenab> oanson: any update on LBaaS or vlan amware VMs?
09:48:25 <oanson> No update on LBaaS. It's looking for a carrier
09:48:29 <rajivk> I am going through specs
09:48:44 <oanson> rajivk, that's for VLAN aware VMs, right?
09:48:58 <rajivk> yes. I am checking how it can be done in dragonflow.
09:49:25 <rajivk> Currently, how vlans etc work and then map implementation from neutron to dragonflow
09:49:44 <rajivk> I will discuss on IRC, if i need information.
09:49:59 <irenab> rajivk: thanks for update
09:50:06 <oanson> Anything else?
09:50:21 <rajivk> not from my side.
09:50:37 <oanson> #topic Bugs
09:51:00 <oanson> Just a quick update here: nick-ma posted some workarounds for the critical bug 1651643
09:51:00 <openstack> bug 1651643 in DragonFlow "metadata service cannot start due to zmq binding conflict" [High,In progress] https://launchpad.net/bugs/1651643 - Assigned to Li Ma (nick-ma-z)
09:51:11 <oanson> It is now reduced to High.
09:51:15 <oanson> nick-ma, thanks!
09:51:47 <oanson> Also thanks to xiaohhui for quickly fixing the broken gate last time. The gate was stable for a whole day before Neutron broke it again :D
09:51:51 <nick-ma> you are welcome. the bug has not been closed yet.
09:52:32 <irenab> oanson: its good to have gate watching
09:52:34 <oanson> Yes, but it is no longer Critical. That's not to be ignored.
09:53:01 <nick-ma> yes.
09:53:28 <oanson> irenab, not sure what to do on this front. Maybe I'll ask Neutron to add a Dragonflow check, but I don't know if they'll approve
09:54:17 <irenab> not sure if this change was communcated well enough, we should have not got by suprise
09:55:02 <oanson> I think I'll free up some time and start watching the Neutron changes.
09:55:33 <oanson> At least we'll know what could have broken the gate when it happens, rather than go looking for it in retrospect
09:55:45 <irenab> oanson: bot is less expensive :-)
09:55:56 <oanson> Not sure a bot can do that.
09:56:00 <oanson> No matter. Let's move on.
09:56:03 <nick-ma> yes.
09:56:08 <oanson> #topic Open Discussion
09:56:27 <oanson> Floor is for the taking.
09:56:29 <nick-ma> do you guys go to project gathering?
09:56:37 <oanson> I plan on attending, yes.
09:56:48 <oanson> (I think I have to :D )
09:57:04 <nick-ma> cool, I don't have opportunity to attend, :-(
09:57:26 <oanson> That's a shame. We'll miss you
09:57:53 <nick-ma> :-)
09:58:23 <oanson> Anyone else coming to the PTG?
09:58:52 <oanson> Not all at once :(
09:58:54 <rajivk> no
09:59:39 <oanson> I have to admit, this isn't very surprising when it's split from the summit
10:00:02 <oanson> All right. That's our time.
10:00:09 <oanson> Thanks everyone for coming. Thanks for the great work!
10:00:20 <oanson> #endmeeting