16:02:23 #startmeeting blazar 16:02:24 Meeting started Thu Apr 9 16:02:23 2020 UTC and is due to finish in 60 minutes. The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:28 The meeting name has been set to 'blazar' 16:02:39 #topic Roll call 16:02:54 jakecoll here 16:03:10 Hi jakecoll 16:04:33 #topic Ussuri release 16:06:00 jakecoll: I spent more time recently testing the network reservation patch. Unfortunately I found many bugs, not yet flagged on Gerrit. It needs a lot more work before being merged. 16:06:17 What were the issue you saw? 16:07:26 Well, it doesn't work at all, for various reasons 16:07:45 Some segment_id -> segmentation_id renames still missing 16:08:06 Soft delete code present without the required support in DB layer 16:08:28 Authentication with Keystone on DevStack doesn't work because the URL is constructed differently 16:08:33 I don't see any segment_id when I search my repo 16:09:16 VXLAN IDs > 4094 rejected 16:09:30 oh wait 16:09:47 some code didn't get added to my last push. Christ. 16:10:02 I see it in the diff. Just pushed patch. 16:11:14 hello, sorry to be running a bit late 16:11:51 Which URL for devstack-keystone auth? 16:12:50 jakecoll: You can see how the existing neutron client is constructed here: https://opendev.org/openstack/blazar/src/branch/master/blazar/utils/openstack/neutron.py#L59-L63 16:13:23 I have a work-in-progress patch to fix most these issues. I managed to create a network, but not yet to delete it. 16:14:08 Given how many issues are not caught by unit tests, we really need integration tests (Tempest) for this feature 16:14:42 I would prefer to ship solid code in Victoria than broken code in Ussuri 16:18:04 And the Ussuri client is getting released now, so the feature would only be half-complete anyway 16:21:27 What do you think? 16:22:39 We'd really prefer to get this out 16:22:55 When is the deadline on the client? 16:24:51 The final release for client libraries is today. There were no patches pending approval so I've already approved it. 16:25:17 alright 16:27:40 This experience makes me think plugins need to be compartmentalized. 16:27:50 The only scenario where I can see the service-side code ship in Ussuri is if we have a fully tested patch + tempest scenario in the next few days, so we could have time to review by Ussuri RC1 16:28:23 diurnalist: what do you think? 16:31:45 My preference would still be to take a bit more time to make this solid and ship it in Victoria. If it merges early in the Victoria cycle it would be a clean backport to Ussuri for your fork anyway. 16:32:14 That depends more on Jason and Kate 16:32:25 My guess is that probably won't happen 16:33:49 neither of us have implemented a tempest test before so there will be overhead learning how that works 16:34:13 I agree that a tempest test would make things feel more solid, is it possible we could get help with that? 16:35:22 You can find existing scenarios at https://opendev.org/openstack/blazar-tempest-plugin/src/branch/master/blazar_tempest_plugin/tests/scenario 16:36:12 how does one test a tempest test? do you just make zuul do it? 16:39:17 If you want to run it locally you would need to set up tempest with a custom version of blazar-tempest-plugin. An alternative is to just push the new scenario to the blazar-tempest-plugin repo and let Zuul test it, but for a new feature this might lead to many iterations (each one taking 1+ hour) 16:39:31 :(( 16:40:29 I'll try to dig up instructions to run blazar tempest scenarios manually, I haven't done so in a long time 16:40:47 long story short, it sounds like this isn't going to make ussuri if these are the new conditions for its inclusion 16:42:35 i think we'll need jake's time on other projects starting next week 16:43:51 if i get some free time i might look in to tempest for the feature myself, but it's unrealistic to expect it in the coming days 16:47:43 I've mentioned that we should have a tempest scenario in the last meeting, but it's really after manually testing the change that I realised it isn't yet in a state to be merged. 16:48:29 The tempest scenario is really a tool to verify that the code is working. Unfortunately it seems unit tests are not enough for this. 16:49:36 i understand, i'm just saying we can't deliver it in the near future, so this is not going to make ussuri in that case 16:50:43 Understood. That's unfortunate, but it's the right decision to make. There is no point in shipping broken code. 16:52:38 Almost out of time. Anything else to discuss? 16:54:02 to anticipate future issues: is there guidance on what will require tempest tests? 16:55:27 In general any major feature, but it's more up to the experience with the code. For example for floating IP reservation I did extensive manual testing so I was confident it was working well. 16:55:44 (it is still a TODO item to add a scenario test for floating IP though) 16:58:08 yes, i was noticing there was not one for floating IPs 16:58:40 i'll think about what we might need to bring for usage enforcement 16:59:36 Generally I would also recommend testing major patches on devstack. It's clear in this case that some Chameleon bits stayed included by mistake. 17:02:28 And you can run tempest inside it of course 17:02:48 We're out of time, I'll be in touch if I can find some tempest pointers for you 17:03:06 Have a good Easter! 17:03:10 #endmeeting