20:00:08 #startmeeting Octavia 20:00:09 Meeting started Wed Jan 31 20:00:08 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:12 The meeting name has been set to 'octavia' 20:00:17 o/ 20:00:22 o/ 20:00:22 o/ 20:00:29 hi 20:00:34 Hi folks! 20:00:44 o/ 20:00:45 \o 20:00:52 hi 20:01:03 #topic Announcements 20:01:14 Queens RC1 is next week! 20:01:21 #link https://releases.openstack.org/queens/schedule.html 20:01:40 I think if we can get the priority patches in we might just have one RC. 20:01:49 Priority bug/patch list for Queens 20:01:56 #link https://etherpad.openstack.org/p/Octavia-Queens-Priority-Review 20:02:07 That link is also in the normal topic for our IRC channel 20:02:33 Also note, PTL nominations for Rocky are open 20:02:39 #link https://governance.openstack.org/election/ 20:02:52 And finally: 20:02:54 PTG Dublin - Price Increase this Thursday 20:03:01 #link https://rockyptg.eventbrite.com/ 20:03:14 If you have not yet registered for the PTG in Dublin, the price goes up tomorrow. 20:03:27 don’t forget to mention the deprecation 20:03:46 Oh, and one last thing: We announced the deprecation of neutron-lbaas and neutron-lbaas-dashboard. 20:04:19 xgerman_ Way to spoil the bit announcement... grin 20:04:39 It's the next topic on the agenda anyway. 20:04:46 Any other announcements? 20:05:10 #topic Neutron-lbaas and neutron-lbaas-dashboard deprecation announced 20:05:18 #link http://lists.openstack.org/pipermail/openstack-dev/2018-January/126836.html 20:05:39 Per the vote last week I have sent out the announcements to both the dev and operator mailing lists. 20:05:58 I have also put together an FAQ page we can point folks to: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation 20:06:26 So far the response has been positive, but it is still early. 20:06:34 Any questions or comments about the deprecation? 20:06:48 I'm working on the documentation and code patches for that today. 20:07:15 johnsom: thank you! 20:07:47 You are welcome. Grin 20:08:18 Ok, if there isn't more to discuss on the deprecation I will move on in the agenda. 20:08:37 #topic Brief progress reports / bugs needing review 20:09:16 Between working on the deprecation and FAQ I have been working through the bugs that were on our priority list for Queens. 20:09:40 do we have etherpad for that ? 20:09:51 like for the patches ? 20:10:10 Alex_Staf Yes, it's part of the priority review etherpad I mentioned above. 20:10:15 #link https://etherpad.openstack.org/p/Octavia-Queens-Priority-Review 20:10:28 johnsom, cool tnx 20:11:01 I think we are down to two issues, one of which may not make queens (amp flitering) as it's going to be a sizable patch with some risk. 20:11:28 The other is the VIP port passed in that has port security disabled. 20:11:49 There is a patch up for that, but I think it might be the wrong approach. I need to review it again. 20:12:34 My first thought is we should just turn port security back on for the port, similar to how we take control of the security group on the port. But, that is just top of mind thinking. 20:13:07 If there are other bugs in the queens code you think we should work on or get into queens, please let me know as soon as you can. 20:13:57 As always, please review and vote on those patches up for priority review for queens. 20:14:24 I still have some release notes work to do on the projects as well. I think I only have a patch up for dashboard. 20:14:47 Any other progress updates? 20:15:32 #topic Octavia testing planning 20:15:40 #link https://etherpad.openstack.org/p/octavia-testing-planning 20:15:45 and 20:15:51 #link https://docs.google.com/spreadsheets/d/1QpP1DBrx7MKwZeXnSjGr4ru-z5WHCQDN4yse-MuWIG4/edit#gid=0 20:16:15 We started this discussion last week, but didn't really finish. 20:16:40 So this is the initial execution plan . I took it on myself to draft a list and have your comments . 20:17:11 I have been looking at the tempest docs as I have time: 20:17:12 #link https://docs.openstack.org/tempest/latest/index.html 20:17:40 It helps clarify the intent behind the API/Scenario tests. 20:17:50 cool I will review it 20:18:41 The one part that we have some confusion in our project is the functional API tests vs. the tempest API tests. 20:18:49 I will need someone to joint the effort though I am junior regarding python 20:19:30 Ok, no problem. Feel free to ask in the openstack-lbaas room, we are happy to help. 20:19:32 if there is a duplication we should let one of them go 20:19:36 aren’t they now allowing other languages? 20:20:06 I am also happy to look at specifics if you have questions, etc. Given everything that is going on in the next month or so I can't sign up to pair program on it however. 20:20:18 xgerman_ No 20:20:40 johnsom, I totally understand 20:21:22 xgerman_ There is documentation as to how another language could be added, but that roadmap has not been completed for anything other than python. Plus there are guidelines as to what tests are required. 20:21:55 #link https://governance.openstack.org/tc/reference/project-testing-interface.html 20:22:03 ok, depending how motivate Alex_Staf is to avoid python :-) 20:22:19 Hah things have gotten... Tight here. It's going to be difficult for a bit to do too much more than reviews 20:22:39 Yeah, if you really wanted to spend a bunch of time on an alternate language, here are the requirements: 20:22:41 #link https://governance.openstack.org/tc/reference/new-language-requirements.html 20:22:55 I don't recommend it or you will get started sometime in 2020 20:22:57 grin 20:23:12 Uhh, I'd stick to Python, lol 20:23:19 xgerman_, at this moment python is the only code I am junior in 20:23:42 + junior is my top coding rank :P 20:23:43 Alex_Staf You can pick it up quick, plus we are here to help 20:23:48 You'll learn quickly :) 20:24:01 what is the alternative coding language ? 20:24:10 Currently, nonee 20:24:17 great then :) 20:24:25 Go has been proposed, but has not met the requirements bar yet 20:25:11 Basically, fastest path to tests for Octavia is to use python and the existing frameworks. 20:25:44 +1 20:25:50 johnsom, as I thought so no surprises here 20:26:04 Also, FYI, check with the team before looking at how other projects do things. Some projects still have bad habits/old code that may lead you down a bad path. (neutron tempest for example) 20:26:37 There are good examples out there, but some bad ones too 20:26:40 johnsom, cool, as I remember designate are ok 20:26:52 Yeah, designate is in pretty good shape. 20:27:11 The #openstack-qa channel is available too for testing questions. 20:27:46 ack 20:27:53 Alex_Staf are there specific topics you would like to cover here? 20:28:35 johnsom, not now but as I know my self I will have a lot of questions soon ( like the alexQuestions etherpad I have :)) 20:29:16 I will try to adjust my hours partly better to have your attention. If I will not be able to do that cgoncalves will get my question list :) 20:29:44 Ok, sounds good. 20:30:04 For the record, with regard to the functional vs scenario test "duplication", I am generally in favor of keeping everything that exists currently, as there is a very important distinction between out of tree tests that require a working stack, and the in-tree tests that will run with minimal setup 20:30:18 I would gladly help whenever I can :) 20:30:41 So I don't really consider there to be any duplication, in fact 20:30:49 rm_mobile I lean this way too. I really like our current functional API tests, but I also see the need for the tempest-plugin API tests. 20:31:05 Yes, I believe we will need both 20:31:33 there is only limited time in the gate 20:31:43 If we decide otherwise in the future we can always bring that up again in a meeting. 20:31:51 +1 20:32:25 Yes, the functional tests are fast, the tempest API tests are slower, but not really the problem that the scenarios pose 20:33:02 I expect we can still run the tempest API tests with no-op drivers right? Since scenario actually tests the code paths. 20:33:47 tempest API should also include negative tests, which we don't have a lot of in the functional test space. 20:34:26 For example, loading an encyclopedia set into the description fields 20:34:53 Ok, other discussion on this or should we move on with the agenda? 20:35:22 #topic Add api call that will indicate amphora image VERSION ( image name in glance is not enough) RFE 20:35:30 #link https://storyboard.openstack.org/#!/story/2001491 20:35:54 Alex_Staf I think this one is also yours. 20:36:17 johnsom, yep 20:36:35 I have added a few comments there. I hope others will as well. 20:36:38 This one is relevant for the future when updates and upgrades will be executed 20:36:44 Is there anything more to discuss on this? 20:36:45 johnsom++ 20:37:04 Alex_Staf: having the glance image id in the amp table isn't enough? this is provided that we can get it in a GET /amphora/ call 20:37:15 If the purpose of this is clear and accepted then no 20:38:10 I am good with the "store glance image ID" concept for sure. 20:38:15 well, operators need to do some work… like giving their images meaningful names 20:38:23 rm_mobile promised he would convince johnsom to have it included in for queens :P 20:38:46 just kidding. it would land only in rocky 20:38:49 Ha, well, a trail of broken promises.... grin 20:39:07 cgoncalves, we need to have n API list that will show the version field and the operator will see the differences in the LB versions . 20:39:20 Yeah, rocky would be good. 20:39:42 Alex_Staf: the glance image would go in https://developer.openstack.org/api-ref/load-balancer/v2/index.html#show-amphora-details 20:39:46 There is probably some work to get that amp details API cleaned up and exposed. 20:39:47 I don’t want the amp table to become a mini-configuration-management system 20:40:05 rm_mobile: right? 20:40:06 and if the image builder will use some info to generate a glance image with proper name fitting to the used image name and version this could be SUPER high level usablity for the operators 20:40:27 doesn’t glance have meta tags 20:40:42 we can print the command to upload with the tags… 20:40:50 after the diskimagebuilder ran 20:40:53 What I don't want is "amphora list" to require calls to each amphora. An amphora show details is ok, but list should really just pull from the DB 20:41:06 xgerman_: it does. octavia picks the last created image in case there are several with same tag 20:41:24 yeah, and we can have more than one tag 20:41:29 and one can say version 20:41:41 Well, metadata tags are different than image tags. 20:41:45 Let's not confuse that. 20:42:13 Also, metadata is an extension if I remember properly, so may not be available in all deployments, so we need to use it carefully 20:42:49 #link https://developer.openstack.org/api-ref/image/v2/metadefs-index.html 20:43:01 correct. I actually read xgerman_ msg as "glance tags" instead of "glance meta tags" 20:43:21 I believe he also wanted to say glance image tags 20:43:34 hmm, I saw the meta so went in that direction 20:43:34 ok, my intent is to leverage glance for all that image version stuff — you would think they have ways to support that ;-) 20:44:04 Well, they don't even have a description field, so.... 20:44:53 * xgerman_ was wondering why we have xcel sreadhseets with image names 20:46:19 I think the summary is, comment on the RFE. Tracking the image-id in the DB is pretty straight forward and useful. If we go deeper into the amp details and call the amp REST API we need to watch the performance impact. etc... 20:47:01 You can still post patches that are feature enhancements BTW, we just won't merge them until Rocky is open. Which if all goes well with RC1 might be pretty soon. 20:47:35 #topic CLI for driver specific features 20:47:41 #link https://etherpad.openstack.org/p/octavia-drivers-osc 20:47:51 We had etherpad voting going on for this one. 20:48:39 Next steps I see is I need to go work with the OpenStack client folks and negotiate our naming. 20:49:27 Ah sorry got distracted -- yeah I'll be able to propose the patch to include just image ID, just haven't prioritized since it couldn't merge yet anyway and it'll be simple to do 20:49:32 It looks like "openstack octavia amphora" is currently in the lead. My concern is they may not let a project name in the OSC namespace or may complain about it. But, I will propose it and see what we get. 20:50:08 Any other discussion on this one? 20:50:10 johnsom: there's 'openstack congress' for one 20:50:17 Ah, good to know 20:50:38 I still think openstack loadbalancer DRIVER amphora 20:50:41 :) 20:51:01 Yeah, that was my vote too 20:51:08 I just want to follow our API layout 20:51:28 Which puts Octavia at the same level as Loadbalancer 20:51:39 Make sense 20:51:43 But octavia is a drvier for loadbalancer 20:51:54 I will give it a go by running it by the OSC folks. 20:52:09 ok, let’s see what they think and then we can re-vote 20:52:10 Alex_Staf: yes and no :) 20:52:21 Yeah that'd be my fallback vote 20:52:32 If we did ranked voting 20:52:44 Alex_Staf: 'octavia' is the name of the project but also the same name is used as driver naming (which once more I'd be in favor of renaming it) 20:52:58 #topic Open Discussion 20:53:09 Ha, well, that was timing wasn't it 20:53:11 Yeah I've been thinking about that too 20:53:40 cgoncalves, I wil lrephrase then : Octavia is a loadbalancing improving project :) hence it is to improve loadbalancer . 20:53:49 This is the topic of should we split out the "octavia driver" (the reference implementation) into it's own repo. 20:53:52 Ok I can live with top 2 options anyhow :) 20:53:52 Would it be confusing to rename it the "amphora driver"? ;) 20:54:16 yes 20:54:29 but people are so confused anyway 20:54:31 rm_mobile I think so as amphora has it's own definition about being a load balancing "engine" 20:54:32 rm_mobile: I'd find another name. what's the top-level of 'amphora' if there's such 20:54:35 then the cli will be openstack loadbalancer amphora ... ? or openstack amphora ? 20:54:47 Alex_Staf: TBD 20:54:52 #link https://docs.openstack.org/octavia/latest/reference/glossary.html 20:55:09 yeah, let’s do some focus group esting for names 20:55:15 Sigh 20:55:29 Yes, but thinking about it, what this driver does is "provide amphora to do Loadbalancing" 20:55:34 Maybe the first decision is if we split it out. 20:55:43 Yes naming is hard 20:55:50 Then, if we decide to, think about a name 20:55:53 So I wonder how much work this will be 20:56:03 And if we can even possibly get it done 20:56:13 A bit. It's the bulk of the code we currently have 20:56:25 if we split it pout we potentially will need octavia-lib 20:56:29 It would basically leave the API behind 20:56:35 Because it will have to practically halt most other work on things like our flows? 20:56:39 johnsom: I'd vote for keeping community-supported reference implementation in-tree and vendor specific out of tree, like neutron ml2 20:56:43 so why don’t we split the API out, then? 20:57:10 but agree with cgoncalves 20:57:13 xgerman Similar work, more confusion IMO 20:57:23 That also does make sense. Which would mean no split 20:57:26 lets deprecate octavia and create an octavia-ng project :P 20:57:47 cgoncalves That has been my thought as well. Splitting out has implications of how far we split things, etc. 20:58:10 amphora was used to store mainly wing 20:58:11 * johnsom glares at cgoncalves for even mentioning it. 20:58:12 wine 20:58:31 johnsom: agreed. but xgerman_ 's suggestion of octavia-lib isn't totally crazy 20:58:31 I think also oil and grains? 20:58:34 hence top level of wine is vineyard 20:58:37 johnsom: :DDD 20:58:47 nice name vineyard 20:58:52 time to move to harder liquor 20:58:52 :) 20:58:57 xgerman_, +1 20:59:05 hah! 20:59:09 Dublin will be soon enough... 20:59:14 Ok, one minute left 20:59:47 quick update regarding octavia-tripleo integration. there has been good progress in that field 20:59:47 Thanks for joining folks! Have good rest of your week and do some reviews... grin 20:59:48 "Amphorae were used in vast numbers for the transport and storage of various products, both liquid and dry, but mostly for wine" 21:00:03 johnsom, good time of day guys :) ( or night ) 21:00:10 #endmeeting