20:00:37 #startmeeting Octavia 20:00:38 Meeting started Wed Jun 27 20:00:37 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:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:41 The meeting name has been set to 'octavia' 20:00:45 Hi folks! 20:00:47 o/ 20:01:05 I know Nir is on vacation today, so he won't be joining us 20:01:24 #topic Announcements 20:01:41 Just a friendly reminder, we have a priority review list for Rocky 20:01:48 #link https://etherpad.openstack.org/p/octavia-priority-reviews 20:02:12 We have been making progress, thank you! However we still have more work to do 20:02:36 o/ 20:02:44 Also of note this week, we filed governance patches for upgrade tags 20:02:51 #link https://review.openstack.org/577967 20:02:58 #link https://review.openstack.org/577970 20:03:18 It looks like we have good support there, so likely in a week or two we will have the supports upgrades tags. 20:03:56 Special shout out to cgoncalves for his work getting us to this point with upgrades 20:04:28 team effort! 20:04:49 O/ 20:04:53 I think I also need to file for the standard-deprecation tag, which seems to have disappeared during the neutron-lbaas split. We certainly qualify for that one too 20:05:25 Any other announcements today? 20:05:59 #topic Brief progress reports / bugs needing review 20:06:02 Just an FYI that apparently LOCI is supporting Octavia now -- just noticed today after someone mentioned they're using those. 20:06:17 Yeah, that is cool. 20:06:43 We probably should have a partner projects links page to keep track of this stuff. 20:06:54 sorry for my ignorance. what is LOCI? xD 20:07:11 #link https://github.com/openstack/loci 20:07:20 Lightweight OCI compatible images for OpenStack Projects 20:07:31 nice! 20:08:10 So, I finished up the "dual amphora down failover" patch. It is up for review. 20:08:30 I then shifted to reviewing the UDP patches, as that is a feature I would like to get into Rocky. 20:08:41 Still some work to do there, but good progress. 20:09:09 While I waited on a update cycle with the UDP patches I have started work on the migration tool again. 20:09:39 I should have it done today. I just have the L7 tables to do and some cleanup work. 20:10:11 I provide feedback on that migration tool next week when I'm in office again 20:10:18 I'll* 20:10:18 How do people feel about testing for that tool? Is it worth me investing time in creating a periodic gate or would basic testing be good enough? 20:10:55 Technically to do it right it would be checking hundreds of fields, which for a one-time-use tool seems a bit much. 20:11:11 johnsom, would anyone actually check results of a periodic gate? 20:11:32 I am pretty sure I am the only one that occasionally looks at the periodic gates..... 20:12:23 Since you can't bookmark it.... It's not easy to glance at 20:12:25 if you do... all good :) 20:12:50 #link http://zuul.openstack.org/builds.html 20:13:03 Pipeline is "periodic" project is "openstack/octavia" 20:13:59 So, yeah, that was kind of my thought too. I don't think I will invest time in building a gate for it. I will do a bunch of manual testing local though. It also has a nice "trial run" setting. 20:14:15 i mean, something as simple as "create a LB in n-lbaas, run script, use octavia to look at it" should be good enough? 20:14:38 Once it's posted for review, if you have environments with LBs running in neutron-lbaas and an Octavia database, you can do the trial run and let me know if anything fails. 20:14:38 what about adding a voting job to your patch while it's under review? once it's good, you remove the job and have it merged? 20:14:42 just prove at least that the script runs and successfully exits 20:15:35 Yeah, it's just a trade off of my time. If you all think a gate is worth it, ok, I will put something together. 20:15:57 rm_work +1. I was kinda thinking the same. I was trying to think about corner cases but for the legacy haproxy in namespace we don't even have support for L7 rules (last I checked) 20:16:17 i think this is only octavia->octavia 20:16:21 So shouldn't be too hard to create bunch of loadbalancers with different configs and migrate them 20:16:28 not migrating across providers 20:16:56 The work I am finishing is for migrating any provider, but no provider conversion, just straight across 20:17:17 btw 20:17:21 #link https://review.openstack.org/#/c/554420/ 20:18:39 Yep, thanks. Not sure what was up with that requirements thing given I didn't change the main requirements file, but we will see what happens. Could be the main file is wrong and the new requirements management stuff is not so helpful anymore 20:20:16 So what I am hearing is a gate test is valuable to folks, so I will spend a day and set something up. 20:21:13 Anyone have an other progress updates to share? 20:22:09 #topic Talk about API versioning/microversioning 20:22:22 So I have posted an update to my version discovery patch: 20:22:28 #link https://review.openstack.org/559460 20:22:35 The example output is here: 20:22:41 #link http://paste.openstack.org/show/724425/ 20:23:24 Please comment on the patch and if this path works for you, etc. 20:23:35 This is another one I want to get into Rocky. 20:23:57 +1 20:23:58 sorry for being late 20:24:02 We have less than a month left to get features into Rocky 20:24:10 #link https://releases.openstack.org/rocky/schedule.html 20:24:46 johnsom, btw re:periodic gate bookmarks, I think I was able to get this working as a URL: http://zuul.openstack.org/builds.html?pipeline=periodic&project=openstack%2Foctavia 20:25:00 Any more discussion on versions beyond comments for the patch? 20:25:18 FYI, cinder also does microversions 20:25:25 nmagnezi Ha, nice 20:25:30 :) 20:25:49 #link https://docs.openstack.org/cinder/ocata/devref/api_microversion_dev.html 20:25:51 cgoncalves Yes, a few projects do. 20:26:09 cgoncalves, they have something like 3 major version 20:26:20 Painful.. :) 20:26:27 I asked a cinder core for feedback and he said it has been working pretty good for them 20:27:43 johnsom, re: output of your patch http://paste.openstack.org/show/724425/ 20:27:58 Just to circle back on why I'm proposing not to jump into microversions right now is by default, if you don't specify a microversion, you always get the oldest API. To me, since so far we are "additive" it seems simpler to go down the path I have proposed. 20:27:59 it's a big strange having CURRENT as v2.1 but href is v2.0 20:28:34 cgoncalve Strange, but the beauty of it.... grin 20:28:38 yeah, well 20:28:47 ideally i think we wouldn't have any version in the URL? 20:28:53 * rm_work shrugs 20:29:11 v2.1 indicates there is an expansion to the API, but since the v2.1 is fully compatible with the v2.0 version it can share a path 20:31:38 The alternative is to fork off paths for each dot release, or do the header microversion filter thing 20:31:41 I'd expect href ending with /v2 then :) 20:32:12 We could alias it if you want. We do need to keep /v2.0 for backward compatibility 20:32:43 We probably need to figure out how to handle the api-ref too 20:33:11 don't people normally just add "available in version 2.1 or greater" or whatever? 20:33:28 for new features 20:34:28 Yeah, probably. Part of the trouble here is the API woking group has zero guidelines or tools for this. 20:34:40 yeah it would be nice if that was like... a field 20:35:04 #link https://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html 20:36:36 Yeah, it would be nice if the api-ref template had a way to handle that. I will look into how to update the api-ref 20:37:38 This publishing practice means that you must write inline information when an API has a change release-to-release. Inline text descriptions are the only way to convey the corresponding release information to the documentation consumer. 20:37:44 To quote that doc... 20:37:49 #link https://docs.openstack.org/doc-contrib-guide/api-guides.html 20:39:26 So I guess comment on the patch? I am open to aliasing /v2 and switching the api-ref over to that if that is cleaner. Or we can keep going down the /v2.0 and versions v2.1, v2.2, etc. 20:42:32 Ok, I guess I will come up with something. 20:43:03 #topic Open Discussion 20:43:05 to me aliasing /v2 would make sense but I don't have a strong opinion on this, at least right now. I'd be fine with incremental /v2.x 20:43:12 Other topics today? 20:44:55 not specific to Octavia but I take that many folks have been waiting for it for some time now. Red Hat OpenStack Platform 13 (Queens-based) has been released today and it features Octavia full support 20:45:08 Wahoo! 20:45:13 Wahoo — 20:45:28 Congratulations folks that worked on OSP 13 support for Octavia. 20:45:32 If you ever need to install Octavia on OSP 12 I have some scripts… 20:45:54 xgerman_, good luck with that :-) 20:46:11 thanks, we will need it 20:46:25 xgerman_, or.. just OSP13 ;) 20:46:32 xgerman_, will you also write an upgrade script when the time comes? :) 20:46:46 I hope NOT… 20:47:06 lol, yeah, upgrade is going to be interesting 20:47:50 Well, if that is all, I will let us all get back to reviewing patches. 20:47:51 fear not! we have an upgrade guide upstream now \o/ 20:48:07 :-) 20:48:13 johnsom, that migration script will help us to move operators towards Octavia's direction. so it has *a lot* of value 20:48:23 :) 20:48:55 Yeah, it's not a "move from old provider x to new provider y", but it is a good first step and will help many folks. 20:49:27 Ok, folks, have a good week! 20:49:30 #endmeeting