08:01:00 <oanson> #startmeeting Dragonflow
08:01:01 <openstack> Meeting started Mon Sep 18 08:01:00 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:04 <openstack> The meeting name has been set to 'dragonflow'
08:01:07 <dimak> hey
08:01:09 <lihi> Hi
08:01:11 <oanson> Yo
08:01:16 <leyal> Hi
08:01:47 <oanson> Give me a second to update the wiki, and we can start
08:02:16 <oanson> All right
08:02:18 <oanson> Let's start
08:02:22 <oanson> #topic Roadmap
08:02:53 <oanson> LBaaS - I haven't updated the spec. I'm sifting through the comments. Should be done by EOD
08:03:30 <oanson> L3 flavour - I have to go through the PTG recording to see how the wiring should be done. It's possible I'll have to drop by the Neutron channel for more help.
08:03:57 <dimak> oanson, link to the recording?
08:04:25 <oanson> dimak, sure, one sec
08:05:03 <oanson> I think this one's it: https://www.youtube.com/watch?v=zSHIpkR9Jxg
08:05:09 <irenab> hey, sorry for being late
08:05:23 <oanson> irenab, hey, no worries
08:05:34 <dimak> oanson, thanks
08:05:55 <oanson> RPM packaging: I got a little stuck. We use jsonmodels which doesn't have an RPM package. We have to ask that it be added to the repo
08:06:32 <oanson> ETCD publisher: lihi, what's up?
08:06:51 <dimak> oanson, I think we should open a bug on RH's bugzilla requesting to add it to fedora
08:06:58 <lihi> Not a lot of updates since last week. I've been sick most of the time :(
08:07:03 <oanson> :(
08:07:11 <oanson> Hope you feel better now
08:07:18 <dimak> and if no one picks it up, we can start pushing it ourselves
08:07:29 <lihi> I am
08:07:32 <lihi> Thanks
08:07:38 <oanson> dimak, sure. Let's take this offline and do it.
08:07:44 <dimak> oanson, +1
08:08:02 <oanson> lihi, last week you said that the work was done, but we're waiting on etcd3gw tagging
08:08:11 <oanson> Does that mean you can start hacking at the OSA deployment?
08:08:48 <lihi> Yes. But I also wanted to updated the patch with the code without debugs.
08:09:02 <lihi> Yes, already started
08:09:07 <oanson> Sure
08:09:32 <oanson> dimak, upgrade scenario / grenade gate
08:09:40 <oanson> I saw you uploaded a patch
08:09:54 <oanson> I also updated the spec to concentrate on what we're doing now. We'll do rolling upgrades later
08:10:15 <oanson> #link Upgrade spec https://review.openstack.org/#/c/500647/
08:10:34 <oanson> #link Migration mechanism https://review.openstack.org/#/c/401210/
08:11:10 <dimak> hey, sorry I dropped for a minute
08:11:17 <oanson> Good to have you back :)
08:11:45 <dimak> Looks like migration is on topic
08:11:56 <oanson> Yes :)
08:12:03 <dimak> I'll adapt the spec to the proposed migration mechanism today
08:12:23 <oanson> Sure
08:12:36 <dimak> the code itself should hopefully work, i'll unWIP it once spec reaches consensus
08:12:57 <oanson> Do we want to discuss the rollback issue? We seem to disagree on the patch
08:13:24 <dimak> Sure
08:13:55 <dimak> oanson, got to read my reply?
08:14:23 <oanson> I think rollback is important. If someone wants to upgrade their database and fails, we should leave the system functioning
08:14:34 <oanson> dimak, just now. In essence this is what I'm suggesting
08:14:56 <oanson> Each migration code also has an undo functionality (with needed info stored in memory or in a file)
08:15:11 <oanson> We apply, apply, apply ... upon failure we undo in reverse order
08:15:22 <oanson> Sortsa like Command design pattern
08:15:37 <oanson> Once everything is done, we say 'hey presto' and clean up
08:15:43 <dimak> I understand, but do we need it though?
08:16:09 <oanson> Yes. We can't have an upgrade failure leave the system inoperable.
08:16:24 <oanson> We have to at least make an effort to bring things to working order automatically
08:16:40 <oanson> Manual intervention is unavoidable, but we should try to make it not urgent
08:17:02 <dimak> We should map out the reasons for error
08:17:10 <oanson> Definitely
08:17:16 <dimak> if for example the database went dead, cleaning up is no use
08:17:21 <oanson> We should log as much data as possible for a post-mortem
08:17:41 <oanson> We should also prepare for the possibility that the undo fails as well.
08:17:43 <dimak> I'll bring it up in the spec
08:18:00 <dimak> If there's no undo, it can't fail :)
08:18:15 <irenab> oanson, cannot we trust neutron DB t resync?
08:18:41 <oanson> irenab, I don't trust it now :)
08:19:03 <oanson> But no, because some of these changes are NB DB schema changes that cannot be synced, since the Neutron DB doesn't know about them
08:19:43 <irenab> I will review the spec and leave my comments there, I think some failures can be resolved by full data resync from neutron
08:20:15 <oanson> Some, not all. Maybe we should allow fatal and non-fatal errors. fatal errors require rollback. non-fatal errors require resync
08:20:17 <dimak> oanson, any examples for non-neutron state?
08:20:48 <oanson> Like adding a unique ID to a model.
08:21:02 <oanson> The unique ID information is unique to Dragonflow. No Neutron copy.
08:21:10 <dimak> We can re-allocate those, provided we flush the datapath
08:21:22 <irenab> but it will be generated
08:21:24 <oanson> The state has to be aligned between the incremented unique ID field in the unique_id table, and the unique IDs already used.
08:21:31 <oanson> irenab, someone has to generate it :)
08:21:32 <dimak> plus, we can store it in neutron if we really want to
08:21:40 <oanson> dimak, do we?
08:21:53 <oanson> I prefer to have a solution that relies on Neutron as little as possible
08:22:10 <dimak> If that'll allow us to avoid undos, it's totally worth it
08:22:19 <oanson> It was just one example
08:22:52 <dimak> We can put in the effort to eliminate dragonflow only state
08:23:03 <irenab> worth to add to the spec list of potential failures and handling
08:23:10 <oanson> irenab, sure
08:23:11 <dimak> irenab, +1
08:23:18 <lihi> +1
08:23:26 <oanson> dimak, I don't think that's achievable. Unless we have a full copy in Neutron
08:23:47 <oanson> The whole idea is not to modify Neutron DB alone. Everything we need is in DF DB
08:24:04 <oanson> s/alone/by our selves/
08:24:40 <oanson> This also means that if Dragonflow is used without Neutron, upgrade is still an option
08:25:43 <dimak> Ok, lets go into detail in the spec
08:26:16 <irenab> sure
08:26:28 <oanson> Sure
08:27:12 <oanson> That's all I have for roadmap
08:27:25 <oanson> Anything you guys want to raise?
08:27:28 <leyal> about DHCP-port-per-lswitch -i talked offline with irenab , i will emphasize in the spec - the impact about the neutron data-model ,irenab also advised to ask  mlavalle to review it  - to make sure it's not brake something in neutron.
08:28:10 <oanson> leyal, sure
08:29:28 <oanson> leyal, I'll also add the DHCP feature to the agenda, so it won't be forgotten next week
08:29:42 <oanson> Anything else for roadmap?
08:30:52 <oanson> #topic Bugs
08:31:17 <oanson> There
08:31:45 <oanson> There's a nice list of High importance bugs
08:32:02 <oanson> Feel free to pick one at random and solve it :)
08:32:17 <dimak> :)
08:32:19 <leyal> oanson , sure
08:32:58 <oanson> Anything else for bugs?
08:33:03 <oanson> One in particular you want to raise?
08:34:01 <oanson> #topic Open Discussion
08:34:18 <oanson> I have a thing to throw around
08:34:19 <oanson> vPTG
08:35:03 <oanson> We need to set a date
08:35:10 <oanson> Or we can can the whole thing
08:35:24 <dimak> what are our options?
08:35:34 <dimak> the holidays are closing in
08:35:38 <oanson> None
08:35:52 <oanson> Next week mlavalle can't make it due to NHO
08:36:03 <irenab> I cannot either
08:36:15 <oanson> Week after irenab is in openstack days
08:36:33 <irenab> after 25-28 Sep
08:36:55 <dimak> what if we push it a few weeks
08:37:04 <dimak> it'll be quite after the beginning of the cycle
08:37:05 <lihi> I', on holiday 29sep-16oct
08:37:26 <oanson> 17th Oct I'm unavailable
08:37:43 <oanson> 23rd Oct?
08:37:44 <irenab> since there are barely working days till Oct 15, maybe we should ahve it after the holidays
08:38:20 <irenab> oanson, how many days do you suggest?
08:38:33 <oanson> 2-3 days
08:38:41 <oanson> One day for design. One day for open discussion
08:39:13 <irenab> oanson, are you back on Oct 18?
08:39:25 <oanson> That's the plan
08:39:28 <irenab> can have it Oct 18-19
08:39:39 <irenab> or week after
08:40:06 <oanson> 18-19 is better
08:40:11 <irenab> +1
08:40:16 <oanson> Please vote
08:40:26 <dimak> +1
08:40:32 <oanson> +1
08:40:32 <leyal> +1
08:40:52 <dimak> which timezones?
08:40:57 <oanson> lihi, ?
08:41:22 <oanson> dimak, China? :)
08:41:22 <lihi> Maybe we can do in the mailing list, or in some kind of another async communication system. Since we want more people to show up
08:41:26 <lihi> +1
08:41:41 <oanson> Yes. Once we decide on a date, I'll fire a mail to the mailing list
08:41:51 <oanson> with a reminder close to the date
08:42:17 <oanson> Since most of us are in Israel, I think Israel timezone (or UTC) would work well
08:42:22 <lihi> do it = do the vote
08:42:43 <oanson> lihi, I don't want to do the vote over the mailinglist
08:42:53 <oanson> too many voters means we'll never find a date
08:43:08 <oanson> It was hard enough to find something that works for all the core devs
08:43:58 <irenab> maybe we can have sessions during the day and afternoon/evening if people from US timezone want to join
08:44:31 <oanson> Sure
08:44:44 <oanson> And during the morning if people from China/Japan want to join
08:45:15 <irenab> and should consider recording
08:45:28 <oanson> Definitely
08:45:45 <oanson> I think we have a conference on site that supports that. Will check with local IT
08:45:56 <oanson> s/conference/conference room/
08:46:38 <oanson> All right. I'll talk to mlavalle tonight (hopefully), and finalize it tomorrow
08:46:58 <oanson> Also have an etherpad for topics
08:47:04 <oanson> #link Dragonflow Queens etherpad https://etherpad.openstack.org/p/dragonflow-queens
08:47:16 <oanson> Anything else for vPTG?
08:47:46 <oanson> All right. The floor is for the taking.
08:48:32 <oanson> Cool.
08:48:39 <oanson> Thank you all for coming. Thanks everyone for the hard work
08:48:51 <oanson> #endmeeting