08:01:14 <oanson> #startmeeting Dragonflow
08:01:15 <openstack> Meeting started Mon Aug  7 08:01:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:18 <openstack> The meeting name has been set to 'dragonflow'
08:01:20 <dimak> Hey
08:01:33 <lihi> Hi
08:01:50 <oanson> We'll wait a minute for leyal and anyone else who would like to join.
08:02:31 <oanson> All right. I guess that's us.
08:02:36 <oanson> #info dimak and lihi in meeting
08:02:43 <oanson> #topic Roadmap
08:02:53 <leyal> Hi
08:03:00 <oanson> Let's run through this one quickly, since there are interesting stuff in the bugs and open discussion
08:03:12 <oanson> LBaaS and RPM packaging - no progress. I'm still on PTO
08:03:20 <oanson> I bet you couldn't tell :)
08:03:50 <oanson> I'm removing skydive from future meetings. It has no carrier. Until that changes, there's no reason to have it on the agenda
08:04:06 <oanson> etcd driver and publisher - lihi?
08:04:43 <lihi> I'm still working on the new client integration.
08:04:57 <lihi> I'm testing if the multi-host configuration can be removed, since the new etcd client doesn't support it. Since etcd manage its own clusters, I don't think it should be a problem, but I'm still working on building a multinode enviroment :)
08:05:03 <oanson> I saw the gate passes on the latest version
08:05:38 <oanson> lihi, I think dimak had some experience with that during the SFC work. If you run into any trouble, maybe he can help.
08:06:08 <dimak> would be glad to
08:06:31 <lihi> Yes we already worked on it yesterday
08:06:36 <oanson> #link etcd3 driver patch https://review.openstack.org/#/c/489246/
08:06:39 <lihi> Thanks
08:06:44 <oanson> Cool. Thanks!
08:06:52 <oanson> Anything else for etcd3?
08:07:03 <lihi> No
08:07:26 <oanson> dimak, l3 flavour? How is that going?
08:08:04 <dimak> The service provider patch it a bit slow
08:08:31 <oanson> In what way?
08:08:43 <dimak> There's a discussion of how to implement it, yamamoto brought up some issues with the current implementation (neutron-side)
08:08:59 <dimak> It's on the ML
08:09:17 <oanson> Do you have a link, or at least the thread's subject?
08:09:23 <dimak> A second
08:09:58 <dimak> [openstack-dev] [neutron] out-of-tree l3 service providers
08:10:24 <dimak> and this https://review.openstack.org/#/c/483173/
08:11:39 <oanson> I think we discussed this last week as well.
08:11:52 <oanson> 2 questions: Is this issue blocking you?
08:11:53 <dimak> This exactly?
08:11:57 <oanson> yes
08:12:13 <oanson> and is l3 flavour blocking irenab's work on kuryr-integration?
08:12:21 <oanson> (As per our discussion last week)
08:12:23 <dimak> No
08:12:38 <dimak> (to blocking irena's work)
08:12:53 <dimak> We can deploy DF if L3 agent
08:13:03 <dimak> and I think it will work with lbaas
08:13:16 <oanson> Last week we discussed the Neutron is entering feature freeze. mlavalle said he'll check if we can get an exception, but it looks like the patch itself isn't ready (WF-1).
08:13:19 <dimak> I have a patch up that drops dnat and l3 apps and it passes the gates
08:13:45 <oanson> What's the patch link?
08:14:01 <dimak> https://review.openstack.org/#/c/490783/
08:14:51 <oanson> In this patch, q-l3 is by default on or off?
08:14:54 <dimak> So I think we can try running kuryr integration in this manner for now
08:15:01 <dimak> on
08:15:19 <dimak> I mean, I think we enable it in override defaults
08:15:24 <dimak> I can check
08:15:55 <oanson> We enable it if df-l3-agent is enabled
08:16:17 <oanson> Which it is in devstackgaterc
08:16:39 <oanson> I don't want to turn off dnat and l3 in the gate. I'd rather turn off the l3-agent.
08:16:54 <oanson> We can test the l3-agent when the kuryr-integration gate is set up.
08:17:23 <dimak> Lets discuss it later on with the CI stuff
08:17:27 <oanson> And for now kuryr integration can work around this by manually modifying the apps list
08:17:33 <oanson> Sure
08:17:53 <oanson> That leaves just leyal with ironic. Did you get feedback from irenab and mlavalle?
08:18:17 <dimak> oanson, ignore what I said about the patch, for some reason l3 app is still there...
08:18:23 <dimak> I'll check it later
08:18:27 <oanson> Sure
08:18:48 <leyal> Irena looked in the doc ..
08:19:26 <oanson> Could you post the link again, please?
08:19:39 <leyal> shew have some comment that i changed. and some that u still want to discuss
08:20:04 <leyal> https://docs.google.com/document/d/1kAFRRBSQQbKjrfxvD8UYZMZeyBG4avxnY3TjqRP8SpE/edit?usp=sharing
08:21:12 <oanson> Sure. dimak and lihi, please take a look as well
08:21:17 <dimak> Will do
08:21:18 <lihi> sure
08:21:21 <oanson> We want to post this to our blog.
08:21:27 <oanson> Anything else for roadmap?
08:22:09 <oanson> Do we want to unify bugs and open discussion today? There'll be many cross-cutting issues.
08:22:41 <dimak> We can try
08:23:05 <oanson> #topic Bugs and Open Discussion
08:23:16 <oanson> Who wants to start?
08:23:31 <dimak> I'll start with the CI stuff
08:23:36 <oanson> Sure.
08:23:43 <dimak> I think we should set up more jobs
08:23:51 <oanson> By the way, to keep things organised, you can add open discussion topics to the wiki
08:23:58 <dimak> And gate more configurations
08:24:36 <dimak> There's this etherpad:
08:24:37 <dimak> https://etherpad.openstack.org/p/df-ci-matrix
08:24:37 <oanson> This is a good idea, but has drawbacks: More jobs means more load on OpenStack servers, and slower review cycle
08:24:40 <lihi> +1 dimak. There are scenarios that are not tested
08:24:52 <dimak> With the dimensions of tests we have
08:25:00 <dimak> (Well, at least some of)
08:25:36 <oanson> There are some tests we *must* have: fullstack, tempest, OSA, kuryr, multinode, kolla
08:26:11 <oanson> We also *must* test l3 with and without the agent (as we have seen last week)
08:26:12 <dimak> I think we should tempest on each of the db backends we support
08:26:55 <oanson> But too many jobs is problematic.
08:27:09 <oanson> Maybe we can have most jobs post-merge, or scheduled.
08:27:10 <oanson> ?
08:27:19 <dimak> What's the benefit?
08:27:39 <oanson> We'll know if something broke, and have a fairly good idea of when and where
08:27:56 <dimak> Why not know it before we merge?
08:28:09 <dimak> Much more visible
08:28:15 <oanson> 1. Additional load on test servers. 2. Longer review cycle
08:28:18 <lihi> But why merge a code that breaks our deployments?
08:28:45 <oanson> I'm not saying 0 testing. Just that the less critical tests will be done less
08:29:18 <dimak> I don't think we can honestly claim we support something if we don't gate it
08:29:41 <oanson> True.
08:30:03 <oanson> But we can gate it in a way that isn't getting in the way of productivity.
08:30:26 <oanson> We are a small project. Running 10 gate jobs for every patchset is a bit much (I think)
08:30:52 <oanson> And I am not saying not to gate stuff, just to gate the less.
08:30:56 <dimak> But we're trying to do a lot
08:31:31 <dimak> We can also start breaking stuff out of the project
08:31:47 <dimak> Like specific apps, and test them separately
08:31:58 <dimak> It should be very close to possible now
08:32:07 <oanson> That's not a bad idea.
08:32:16 <oanson> Let's do this differently. Let's construct a list of all the gates we want. We'll split it into gate we *must* have. And then see what we can get it?
08:32:32 <dimak> Sure
08:32:32 <lihi> And create a sub-project "Dragonflow-apps"?
08:32:34 <oanson> in*, not it
08:32:45 <dimak> or dragonflow-lbaas
08:32:49 <dimak> dragonflow-sfc
08:32:52 <oanson> or dragonflow-zookeeper,
08:32:52 <dimak> dragonflow-l3
08:32:53 <dimak> etc
08:33:58 <lihi> ok
08:34:05 <oanson> Let's start by reviewing the gates we want. Half of them are not written yet. The other half are unstable.
08:34:15 <oanson> In fact, the only stable one is the fullstack.
08:34:24 <dimak> and pep8 ;)
08:34:29 <lihi> :D
08:34:45 <kkxue> :)
08:34:51 <oanson> :)
08:35:07 <dimak> I think we don't need a fullstack both for redis and etcd
08:35:15 <oanson> Probably not.
08:35:17 <dimak> we're testing mostly apps there
08:35:32 <dimak> I think tempest is a better overall approach to test backends
08:35:33 <lihi> That should be tested somewhere
08:35:36 <lihi> OK
08:35:37 <dimak> (or rally)
08:35:40 <oanson> etcd testing will be covered in OSA deployment. But we do need a second fullstack for ZMQ (i.e. non-broker pub/sub mechanism)
08:35:57 <dimak> Why fullstack and not tempest?
08:36:03 <oanson> In general, I prefer to move away from fullstack, and to tempest.
08:36:19 <oanson> dimak, I'm going to go with 'Historical Reasons', and leave it at that.
08:36:20 <dimak> If pubsub is broken, tempest will get red
08:36:32 <dimak> sure
08:36:39 <oanson> Yes. Then we need to tempests.
08:37:12 <dimak> I'm working on that
08:37:14 <oanson> We can also make fullstack more minimal - remove nova, cinder, etc., anything except dragonflow's dependencies. And then test not using VMs but fake VMs.
08:37:32 <oanson> That's *two tempests* above...
08:38:50 <dimak> I'm still investigating the problems in our tempest
08:38:50 <oanson> So we can have tempest with: redis, zookeeper. We can have fullstack with cassandra, we'll have OSA with etcd. That should cover databases
08:39:30 <dimak> I'd do tempest with all 4, then you have a rough estimate how well each of those works
08:39:30 <oanson> dimak, I see you have also a few related patches lying around. Is your tempest [DNM] patch rebased?
08:39:36 <dimak> for the rest, use the same backend
08:40:02 <oanson> For the rest then we can use etcd, since it's a base service and less chance of failing during installation
08:40:28 <dimak> a good idea
08:40:28 <oanson> After all we're not here to test the databases, just Dragonflow on top of them.
08:40:52 <dimak> The tempest test is not rebased, but master didn't have a lot going last week
08:41:14 <oanson> But I want to do a stable migration - first fix tempest, *then* move away from fullstack.
08:41:30 <dimak> Maybe we can do some more basic tests for databases and that's it?
08:41:33 <oanson> And moving away from fullstack is not a priority. kuryr, OSA, and multinode are more important
08:41:43 <oanson> dimak, yes. That's a good idea.
08:41:43 <dimak> deployment + sanity of db API
08:42:04 <dimak> Same for pubsub
08:42:23 <oanson> I think fullstack's base_operations test does that. It could be expanded and reused.
08:42:50 <dimak> Ok, how do we move on?
08:43:06 <dimak> I'll try to get tempest green
08:43:28 <oanson> dimak, you get tempest green
08:43:43 <oanson> irenab will work on kuryr-integration when she gets back
08:43:53 <oanson> lihi works on getting OSA gate green
08:44:08 <oanson> either via OSA project, or adding the gate to our own (up to you)
08:44:11 <dimak> do we want tempest with l3 agent?
08:44:19 <oanson> No
08:44:27 <oanson> l3 agent is tested via kuryr integration
08:44:27 <dimak> noted
08:44:46 <oanson> lihi, do you think you have enough time to write the basic db tests?
08:45:18 <oanson> dimak, leyal, I would be happy if you two could continue bug-shooting to get the other things stable as well.
08:45:33 <lihi> Yes. I'll add the tests that I am missing right now :)
08:45:33 <oanson> It would be best to reach the end of August with 0 critical bugs
08:46:18 <dimak> We're planning to release in-schedule with the rest?
08:46:30 <oanson> It looks like I'll be able to rejoin next week. So I can take some of the brunt of the work then too.
08:46:31 <oanson> dimak, yes
08:46:45 <leyal> sure..
08:46:48 <oanson> We'll back port bugs if/when we need
08:47:06 <oanson> Are there any legacy models left?
08:47:15 <dimak> Nope
08:47:31 <oanson> Then this version starts our database version 1. Any future database changes will need migration.
08:47:52 <oanson> This is in preparation for the grenade (upgrade) gate job.
08:48:18 <dimak> +1
08:48:47 <oanson> Which means we will probably want to set it up first thing on September after the release, to make sure we don't accidentally change the database
08:49:27 <oanson> We may want to add a hacking rule to tox/pep8 until we get that done, but that is in September as well
08:49:51 <oanson> All right. Everyone knows what they're doing? Everyone has enough bandwidth?
08:50:20 <dimak> Yeah
08:50:36 <lihi> yes
08:50:47 <leyal> yep
08:51:25 <oanson> All right. Then good luck to us all.
08:51:29 <oanson> Thank you for coming.
08:51:32 <oanson> #endmeeting