09:00:47 #startmeeting blazar 09:00:48 Meeting started Tue Jun 19 09:00:47 2018 UTC and is due to finish in 60 minutes. The chair is masahito. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:52 The meeting name has been set to 'blazar' 09:01:00 #topic RollCall 09:01:21 o/ 09:01:42 today's agenda is 09:01:48 1. blazarclient 1.1.1 09:01:51 2. API changes 09:01:53 3. AOB 09:01:57 anything else? 09:02:06 hiro-kobayashi: hi 09:02:28 Hello! 09:02:35 hi all 09:02:41 hi all! 09:02:49 hi 09:03:02 priteau, bertys, tetsuro: hi 09:03:21 #topic blazarclient 1.1.1 09:03:50 Just a fyi, as we talked in the last meeting, I pushed a patch for blazarclient 1.1.1. 09:03:55 https://review.openstack.org/#/c/576402/ 09:04:24 The release includes the bug fix for multi region selection. 09:04:57 any comments? 09:05:04 Thanks masahito. I am working on setting up release notes for python-blazarclient, hoping to push it later today. I am not sure if this release commit will need to change. 09:06:09 priteau: thanks the note! Mainstream of the fix is for 2.0.0. I think it's okay to merge your patch later. 09:07:02 #topic API change 09:07:40 priteau and I talked the changes for API response in this patch. 09:07:45 https://review.openstack.org/#/c/573647/ 09:08:47 To follow the API guideline strictly, it looks like we need version up to changing response code. 09:08:54 http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html#evaluating-api-changes 09:09:19 I don’t think this kind of bug fix needs API version change 09:10:32 I am not necessarily saying that we should strictly follow the API guidelines, but we should all agree on the approach 09:10:36 The response code 403 was not intended. 09:10:56 Because Blazar doesn't have much adoption yet, it's better if we can make those API changes early 09:11:05 priteau: right. 09:11:16 hiro-kobayashi_: the intent of the guideline is that there might be some users catching a 403, because that's the current response 09:11:55 For example, on Chameleon, we have client code that knows that a 500 error returned by Blazar often means that no hosts are available 09:12:01 we have 3 types of change for the API in general. 1. Add new API schema, 2. add new key or query for the existing APIs and 3. change response code. 09:12:44 priteau: IMHO, that's why the guideline was defined. 09:13:25 to prevent the client(meaning CLI, GUI or users workflow) break. 09:14:16 Yes, that's my understanding. Though, for Blazar, realistically how many users are currently catching this 403 and wouldn't work with a 400? Probably none. 09:14:47 But as we are an official project now, I wanted to discuss and check whether we had to follow these guidelines 09:14:49 IMO, priteau's situation is great feadbacks for us. So Blazar's change should follow the feedback. 09:15:27 right. 09:15:56 masahito: I think it should be fine to change response codes as long as there is a release note documenting it 09:16:12 If we follow the guideline, does masa’s patch need Version update? 09:16:37 If you're ok, I'd like to fix the response code following API reference as much as possible in R or S cycle. 09:17:13 oh, sorry. thanks masahito! 09:17:39 hiro-kobayashi_: To follow the API guidelines, yes, we would need a version update. But if we all agree that we don't have to strictly follow the guideline for now (and if that's allowed for an official project), then we can make minor changes to the API without bumping the version. 09:18:01 And later that release, we could follow the guidline more strictly than now. 09:18:43 +1 09:18:59 hiro-kobayashi_: priteau's opition is right. The guideline assume the microversion API Nova or Neutron has already introduced. 09:19:35 Got it. I agree. let’s correct response code and document it in release notes. After that, let’s follow the guideline 09:20:09 bertys, tetsur___, what do you think? 09:20:23 priteau: thanks. 09:20:59 Having microversion now would be cheap but not free. 09:21:41 priteau: ok for me. 09:21:58 we would put the microversioning on the table for S cycle :-) 09:22:00 so I'm good with the conclusion to clean codes first with release notes, so that works for me. 09:22:27 tetsur___: means you volunteer? 09:22:39 masahito: this is still not a community goal AFAIK https://etherpad.openstack.org/p/community-goals 09:23:12 masahito: maybe immediate action item is to add blazar to https://developer.openstack.org/api-guide/quick-start/? 09:23:40 we do have https://developer.openstack.org/api-ref/reservation/ 09:23:55 bertys: Good catch! 09:24:12 bertys: right, the S release goals would be storyboard migration and cold upgrade. 09:24:48 bertys: And I thought there is already the link to the API reference. Thanks for letting me know. 09:25:06 bertys: I didn’t notice it. Thanks! 09:26:04 the doc links are very complicated ;-0 09:26:47 #agreed refactor response code as soon as possible, then follow the API guideline 09:27:07 masahito: I can work on cleaning response codes, started with https://review.openstack.org/#/c/575271/ so far :) 09:27:21 tetsur___: Great! 09:27:41 thanks tetsur___! 09:27:51 #todo Add a link to the API reference page 09:27:58 any comment? 09:29:13 #topic AOB 09:29:16 Also agreed write release notes? 09:29:37 of course 09:30:02 #agreed write a releasenote for the response code refactoring 09:30:33 priteau: thanks for the follow up :-) 09:30:50 I will update my -1s on reviews accordingly 09:31:12 thank you. 09:31:53 I have 2 updates 09:32:23 #1: I pushed a patch for cleaning-time 09:32:37 https://review.openstack.org/#/c/575021/ 09:33:20 masahito has already reviwed, thanks! 09:34:12 priteau: please check if it meets Chameleon’s operation 09:34:50 I will, though we don't yet use cleaning 09:35:02 thanks! 09:35:19 update #2 is for placement support 09:35:43 I pushed a spec for placement support 09:36:07 https://review.openstack.org/#/c/576343/ 09:36:25 based on the etherpad. 09:36:55 some sections are still WIP but I pushed it to start detailed discussion 09:37:25 The point is that my proposal still depends on the BlazarFilter 09:37:41 Thanks hiro-kobayashi_! 09:37:45 hiro-kobayashi_: Great jobs! 09:38:01 I tried to remove the filter by using traits but it smells bad to cdent 09:38:27 The cleaning time patch looks good to me because it can work even though the config is change later. 09:38:42 So my proposal is: 09:39:15 1st step: support Placement API but still dependes on the filter 09:39:44 2nd step: solve the dependency on the filter 09:40:02 My spec is for the 1st step 09:40:34 Is it okay? 09:41:29 It sounds reasonable. For the #2, the Placement support needs to care host reservation as well. 09:42:37 masahito: yes. the goal is both of host and instance reservation don’t depend on the BlaaFilter 09:43:42 that’s all Updates from me 09:43:58 The 1st step sounds sane to me. The filter is needed for today's placement as long as blazar says "we want to keep this node for this user" 09:44:15 hiro-kobayashi_: Thanks 09:44:51 tetsuro: Is there a BP or a patch that enables Blazar says that? 09:45:08 In placement side, no there is not. 09:45:44 got it. sounds we need a proposal. 09:47:15 ok. tetsuro: please log your comments on the gerrit 09:48:27 let's review the hiro-kobayashi_'s great patches! 09:48:31 sorry the network got down 09:48:34 anything else? 09:48:44 Yup anyway I'll comment on that spec 09:49:53 I Started contribution to blazar in response refactor (https://review.openstack.org/#/c/575271/) I have mentioned above^ and blazar-client (https://review.openstack.org/#/c/575686/). 09:50:03 Would be great to see you on the reviewer lists :) 09:50:27 that's all. 09:50:35 tetsuro_: Nice works! 09:50:59 Of course! thank you for starting to contribute to blazar! 09:51:23 The response code changes has trend in this team :-) 09:52:08 Blazar team has good improvements. 09:53:11 OK, looks nothing more. Let's end the meeting early and back to review. 09:53:34 thanks all. 09:53:37 thanks! 09:53:37 thanks and good bye all! 09:53:39 bye. 09:53:48 #endmeeting