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