09:00:07 #startmeeting blazar 09:00:08 Meeting started Tue Oct 9 09:00:07 2018 UTC and is due to finish in 60 minutes. The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:11 The meeting name has been set to 'blazar' 09:00:15 #topic Roll call 09:00:18 o/ 09:00:23 Good morning Blazar folks! 09:00:31 Or good evening for some 09:00:38 Good evening :-) 09:00:50 o/ 09:01:16 o/ 09:01:25 Agenda for today: 09:01:33 1. Project Update @ Berlin Summit 09:01:37 2. stein-1 milestone 09:01:40 3. OpenStack-wide Goals 09:01:43 4. AOB 09:02:07 #topic Project Update @ Berlin Summit 09:03:12 I asked if there was a specific slide template to use. We can reuse one that was provided at the Sydney summit, but it's not mandatory. 09:03:30 I created a file based on this template. 09:04:13 Thanks, I received your invite mail. 09:04:51 #link https://docs.google.com/presentation/d/1nsuiQe72E0cYELSI8qLmNwVm4SOXzuf01akzqKEZ1TE/edit?usp=sharing 09:05:10 I saw that, too. 09:05:59 tetsuro, bertys: If you have Google-enabled email addresses that you want to use to contribute to the slides, please share them with me and I will add you 09:06:43 priteau: will do offline. Thanks 09:07:04 I don't really want to allow anyone with the link to edit since it can be found in IRC logs 09:07:41 Could you add me as tnakamura.openstack@gmail.com? 09:08:03 Done 09:08:36 I also created a Google Drive folder to keep all our presentations in one place 09:08:50 thx! 09:09:05 Currently there is the Boston project update, Vancouver project onboarding, and Berlin project update 09:09:24 masahito: I think in Vancouver there was also a project update? 09:09:33 I'll add Vancouver project update. 09:09:55 Thank you! 09:11:58 masahito: Do you want to contribute Rocky update and I will work on the Stein goals? 09:12:12 It would be nice to have some information from tetsuro about placement integration goals 09:12:42 Sure I can add that into the project update 09:14:26 We don't have to stick exactly to the template so if you feel the order needs to be changed, don't hesitate to propose it. 09:15:00 I copy, captain. 09:15:44 In terms of speakers, I was thinking: masahito for "What is Blazar" + Rocky features, followed by me for Stein + beyond Stein, and Bertrand for cross-project work (if we use this slide), how to give feedback and how to contribute 09:16:44 make sense. 09:17:44 make sense. 09:18:50 I will propose something for slides 6 to 8, thanks 09:19:07 Thanks bertys! 09:19:14 Let's move on. 09:19:26 #topic stein-1 milestone 09:19:54 #link https://launchpad.net/blazar/+milestone/stein-1 09:20:12 Stein-1 is Oct 22 - Oct 26 09:20:27 That's just two weeks away 09:21:17 I have been very busy on another project but will do my best to submit patches that I've already implemented for Chameleon 09:22:02 I would like to propose that we move the "Implement network reservation feature" blueprint to stein-2. I am working on this, and so is masahito, but a lot more work is needed. 09:22:25 I'm working on network reservation now. I plan to push my spec in this week. 09:22:55 Thanks masahito. I am still prototyping an approach on the VLAN reservation side 09:23:08 priteau: We're planning to have two reservations, floating ip and VLAN. How about to separate the two? 09:24:00 The original BP is named BASIC network reservation. It has less meanings. 09:24:36 They are quite different resources, they could be implemented by separate plugins sharing some common code and Neutron client wrapper. 09:25:55 right. 09:27:26 If they're going to be two different plugins, we should have different specs respectively, IMO. 09:28:10 yes. My spec focuses on floating ip reservation/plugin. 09:29:03 I agree. And based on the two specs, we can see how much overlap there is and whether it makes sense to merge into a common plugin. 09:30:42 tetsuro: How is it progressing on the placement side? 09:31:19 Nova is ready for using nested providers 09:32:02 since https://review.openstack.org/#/c/585672/10 is gone this week 09:33:13 https://review.openstack.org/#/c/584625/4 is ready for review in blazar's side. 09:33:14 Nice work. 09:33:30 OK, will review. 09:33:41 Thanks a lot 09:34:09 Nice 09:35:38 tetsuro: Do you know what is required for https://blueprints.launchpad.net/blazar/+spec/no-affinity-instance-reservation 09:36:35 I think I sorted out that in the last PTG etherpad 09:37:15 https://etherpad.openstack.org/p/blazar-ptg-stein from Line 57 09:37:31 Great 09:38:31 Let's keep it for stein-1, but we can move to stein-2 if more time is needed. 09:38:47 Any other comment regarding the stein-1 milestone? 09:40:37 I pushed some patches sticked to s-1 milestone. Please review this if you all have time :-) 09:42:14 Thanks masahito 09:42:33 Resource allocation review is still on my TODO list 09:42:49 Let's move to the next topic 09:42:53 #topic OpenStack-wide Goals 09:43:27 There was some discussion on the dev list about the maturity of the oslo.upgradecheck library 09:43:34 #link http://lists.openstack.org/pipermail/openstack-dev/2018-October/135502.html 09:44:51 Matt Riedemann recommends to wait until interface changes are finalized before merging upgrade checkers using the library 09:46:34 I will wait until these changes are finalized to write and submit a patch for a Blazar noop checker 09:46:47 yes. 09:47:33 The client and library final release is s-3 milestone usually. So don't need to be hurry. 09:49:02 If we can have it ready early it's less to worry about in late cycle though :-) 09:49:05 IMO, other projects, like neutron in the above mail, plan to have noop checker. We can re-use the patch for Blazar 09:49:13 That's my plan 09:50:03 10 minutes left, let's move to AOB 09:50:06 #topic AOB 09:50:37 I reviewed the instance reservation scenario topic 09:50:39 #link https://review.openstack.org/#/q/topic:bug/1714438 09:51:09 I left a -1 on https://review.openstack.org/#/c/604939/ because I don't understand why we need to delete the reservation. 09:51:15 masahito: could you please explain? 09:51:42 yup. 09:54:16 In the real, there is no race condition the scenario test could hit. 09:55:28 But under Tempest there is? 09:55:41 As create_server() does, any resources created in a test scenario are deleted at end of each tests, meanings in dearDown. 09:57:32 If we have create_lease() which adds the created resource to addCleanup, the cleanup code is not needed. 09:58:57 That's why I commented "to avoid unexpected race condition". 09:59:10 So it's for the scenarios where a lease/reservation is still active? 10:00:04 but test_lease_expiration and test_update_instance_reservation both run: self.assertTrue(lease['status'] == 'TERMINATED') 10:00:29 Isn't it enough to ensure no race condition? 10:01:54 We've ran out of time. We can continue discussion on Gerrit. 10:01:58 right. I expect there is no race condition. 10:02:03 Or in #openstack-blazar 10:02:11 #endmeeting