20:00:20 #startmeeting Octavia 20:00:21 Meeting started Wed Nov 28 20:00:20 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:24 The meeting name has been set to 'octavia' 20:00:33 Hi folks 20:00:41 ahoy! 20:01:15 Seems quiet this week. 20:01:16 #topic Announcements 20:01:33 Just a friendly reminder, we have a priority review list: 20:01:37 #link https://etherpad.openstack.org/p/octavia-priority-reviews 20:01:55 Lots of goodies looking for a review.... 20:02:14 FYI, I am trying to update it at least once a week 20:02:37 Otherwise I don't think I have any announcements today. Anyone else? 20:02:44 we released octavia-tempest-plugin 0.2.0 20:02:59 o/ 20:03:17 Ah yes, good stuff there. 20:03:22 johnsom, on that note, I've built 0.2.0 RPMs today so there will get ship in the near future 20:03:46 There are a few patches up for review on the stable/queens branch too. I hope we can get those in and cut a queens release soon 20:03:48 o/ 20:04:02 nmagnezi Nice! 20:04:19 #topic Brief progress reports / bugs needing review 20:04:47 Other than taking Thanksgiving week off, I have been working on reviews and catching up on email, etc. 20:05:02 I have started looking at the next step for the flavors work as well. 20:05:46 Any other updates? 20:05:49 * cgoncalves has been fixing the usual suspect, again 20:06:23 * johnsom grumbles "triple-opps" 20:06:33 lol 20:06:44 I reviewed the tags patch. good stuff there. still need to vote though 20:07:18 Ok cool, I pitched in my +2 this morning on that. It does look great and he fixed the code duplication issue I posted. 20:07:36 yeah, the mixin. I wanted to leave that comment too 20:08:10 tags was something a vendor also was interested in. hopefully we will be able to pass it down to the provider 20:08:17 Nope! 20:08:23 ok... 20:08:40 you mean in this patch or never? 20:08:51 That allows bad behaviors like using tags to configure drivers and such. They get overloaded and it becomes a mess. 20:09:10 There really isn't a good reason a driver would need access to the tags. 20:09:23 They should pass in driver config settings via flavors 20:10:13 never IMO 20:10:37 What vendor thought they wanted tags? 20:10:41 ok, I don't know the use case they have in mind. via flavors sounds reasonable and likely doable for their needs 20:12:01 Yep. 20:12:05 Yeah, the right away to do driver configs is flavors, so it is at least validated, etc. 20:12:12 It's part of the driver spec 20:12:32 Indeed. No random stuff passed in 20:12:34 And coming to a patch review near you soon! grin 20:13:25 tenant: tag: "vCPUs": 255 20:13:38 "I need it fast!" 20:13:41 grin 20:14:12 Ok, other updates or on to some topics for this week? 20:14:41 #topic Brief progress reports / bugs needing review 20:14:48 Dang, wrong topic 20:14:58 #topic Amp failover when failover already occurred (Queens) 20:15:01 You are repeating yourself 20:15:05 #link https://review.openstack.org/#/c/548989/ 20:15:20 * johnsom thinks he should not be eating lunch at the same time 20:15:56 Back in Rocky we had this handy patch that fixes an issue with LBs that failover twice. 20:15:57 johnsom, bon appétit 20:16:01 Multi tasking 20:16:49 Basically if the first attempt failed, say nova issue, then it tries again. The problem is in between housekeeping can get a bit aggressive and purge some useful records. 20:17:35 I looked at backporting this to Queens (recently a vendor hit is as they were missing another patch), but as it is, this patch depends on some schema changes that were not part of Queens 20:17:53 20:18:48 However, I think I can improve the situation for Queens at least some with a partial backport of this. It wouldn't be a true cherry-pick because of the other schema dependencies. 20:19:06 Before I dig into that I wanted to run it by you all for comment 20:20:32 first, is there a way to easily assert when a patch is not backportable because of schema changes, in this case? what should we do better? 20:21:24 Ok. So, I don't think it would be right/best to use the cherry pick string, etc. when the bulk of the fix won't be going back. Are we ok with a "new" patch against stable/queens that attempts to fix this? That patch would not go forward to Rocky/Stein as there is a more complete fix already there. 20:21:46 I am ok with that 20:22:03 Yeah, I manually cherry-picked and fixed the conflicts, the unit and functional tests blew up due to the missing schema 20:22:30 ok, good 20:22:39 So, yes, it was obvious there was a required schema change patch that was not on queens 20:22:42 fine with a new patch 20:23:15 tests=good 20:23:20 Same here 20:23:36 Ok cool. I will propose something later today that should improve that scenario. 20:23:56 I will reference the Rocky patch and explain the situation in the commit message. 20:24:26 I think it's the best answer as folks are using queens as an LTS and this should be fixed. 20:24:45 #topic VIP ACLs/SGs - continued 20:25:00 We ran out of time on this last week, so I added it to this weeks agenda. 20:25:11 Is there more discussion needed on this topic? 20:26:10 Going once.... 20:26:35 Going twice... (we can always discuss more at a future meeting) 20:26:55 #topic Open Discussion 20:27:27 Other topics for today? 20:29:31 Ok, then I will get busy on the queens patch and back to doing interesting jsonschema things for flavors. 20:29:37 Have a good week! 20:29:56 #endmeeting