09:01:15 #startmeeting blazar 09:01:16 Meeting started Tue Jan 23 09:01:15 2018 UTC and is due to finish in 60 minutes. The chair is masahito. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:01:20 The meeting name has been set to 'blazar' 09:01:30 #topic RollCall 09:01:39 o/ 09:01:41 o/ 09:02:40 today's agenda is 09:02:45 1. PTG planning 09:02:51 2. Q-3 milestone 09:02:53 3. AOB 09:02:56 anything else? 09:03:04 bertys, hiro-kobayashi: hi 09:03:12 Hello 09:03:15 OpenStack Summit Vancouver CFP? 09:03:17 priteau: hello 09:03:33 hiro-kobayashi: got it. 09:03:44 Then, let's start. 09:03:52 #topic PTG planning 09:04:37 As announced in openstack-dev ML, Blazar team meeting is on Monday and Tuesday in the upcoming PTG. 09:06:23 We expected two days meeting. So it's enough days for us. 09:07:00 And if we need additional days, we can gather on Wednesday :-) 09:07:11 any comment? 09:07:43 masahito: I have started editing the Blazar PTG etherpad 09:07:53 #link https://etherpad.openstack.org/p/blazar-ptg-rocky 09:08:01 Few ideas added 09:08:08 I might skip some of the discussion on Tuesday morning, to attend the Scientific SIG meeting 09:08:28 bertys_: thanks! 09:09:36 priteau: Nice. If you get some requirements for Blazar, we can talk it in the afternoon. 09:11:36 Absolutely 09:11:43 Before I forget it. Will we have Blazar team dinner? 09:12:04 +1 09:12:22 I thought Monday or Tuesday looks good for us. 09:12:57 both Monday or Tuesday would work for me 09:13:00 +1 for Monday 09:13:22 both of days would work for me 09:14:03 okay. Monday works for us. 09:15:11 Does someone lead the plan? 09:15:36 I'm not sure there is an restraunt around the venue. 09:15:47 Anyone knows good restaurant? If not, I can lead the plan ;-) 09:16:57 hiro-kobayashi: thanks! 09:17:11 I have never been to Dublin 09:17:31 I'm okay any restaurant. So please pick up as your preference ;-) 09:18:29 okay 09:18:42 I'll pick up candidates. 09:19:29 Seems like there is quite a lot of choice nearby 09:20:10 Sounds nice. 09:21:16 Then let's move on to next. 09:21:24 #topic Q-3 milestone 09:21:57 This week is Q-3 milestone in release schedule. https://releases.openstack.org/queens/schedule.html 09:22:38 In addition, final release of client libraries. 09:24:02 I plan to release our client libraries with 1.0.0 version numbering as we discuss. 09:24:26 I have 2 patches to be merged before it: 09:24:29 https://review.openstack.org/#/c/533504/ 09:24:35 And plan to add 1.0.0b3 tag for blazar itself. 09:24:38 https://review.openstack.org/#/c/535574/ 09:24:54 How do you think for the blazar's version numbering? 09:25:00 Both of them are related to Python3. 09:25:05 Should we use 0.4.0b3? 09:25:31 Didn't we discuss last week to move to 1.0? 09:25:33 masahito: sorry for interrupt... 09:25:56 hiro-kobayashi: np :-) 09:26:17 So we use 1.0 and write some notes? 09:27:17 priteau: yes. It's just a clarification. 09:27:27 hiro-kobayashi: I think tso. 09:28:45 hiro-kobayashi: I adde +2s for the two patches 09:29:39 masahito: Thanks! 09:30:10 I don't see any patches for blazarnova, blazar_dashboard and blazar_tempest repositories. So I put the tag on their current master topic. 09:31:06 s/master topic/master commit/ 09:31:23 I've pushed some patches for those repository. it's about Python3. 09:32:18 sorry, I used wrong query. 09:32:23 https://review.openstack.org/#/c/535572/ 09:32:33 https://review.openstack.org/#/c/535668/ 09:33:32 For blazar-dashboard, I've pushed some patches but they don't need to be merged before Q-3. 09:34:16 priteau: Could you review the two patches? https://review.openstack.org/#/c/533504 and https://review.openstack.org/#/c/535668 09:34:41 I am looking at the first already 09:35:13 I am just a bit confused by the changes to format_output_data 09:35:33 to the test specifically 09:35:44 IIRC, blazar-dashboard and tempest is non-server repository, so it's an official release for Queens. 09:37:23 priteau: the original test data looked inappropriate. So I updated them. How do you think? 09:37:58 Yes, the input changes are good, we should use real types 09:38:09 But why is the dict output a byte string? 09:38:14 this: 09:38:15 'key_dict': b'{"key": "value"}', 09:39:12 Because of jsonutils.dump_as_bytes, I guess 09:40:01 I have to -1 this patch 09:40:13 This is what happens in my environment: 09:40:18 (py36) [priteau@raider python-blazarclient (master *>)]$ blazar lease-show 51c2b3c2-7d02-41af-a1ce-84c2afc66e5a 09:40:18 sequence item 0: expected str instance, bytes found 09:40:29 py27 works fine 09:41:57 I posted the error on Gerrit 09:42:09 This is using blazarclient against our Chameleon deployment 09:42:36 Thanks. I'll check it later. It's interesting that it passes py35 but not py36 09:43:15 The unit tests pass on my machine 09:43:24 It's manual testing against the API that fail 09:43:48 priteau: got it. 09:44:05 thanks for testing it on manually. 09:44:27 I've tested just tox tersts. So more investigation may be needed. 09:44:45 In tempest we use a custom REST client so python-blazarclient is never tested against a real API... 09:44:47 s/tersts/tests/ 09:45:00 It looks like we need test in manual before removeing non-voting flag for py35 testing. 09:45:43 masahito: I remember you had good arguments about using a custom REST client for Tempest, but maybe we should have a (non-voting?) Tempest test using python-blazarclient? 09:45:44 priteau: agree 09:46:39 priteau: sounds reasonable. 09:47:41 Or run the scenario both with blazarclient and without blazarclient in current scenario tests. 09:48:06 either okay for me. 09:48:59 Okay, then let's discuss on this offline. If we need advise, we can ask QA team in openstack-dev ML. 09:49:09 But I thought the argument was that it would be difficult to merge API changes because of the need to synchronize blazarclient with those changes as well 09:49:39 Since the job is voting 09:49:50 Although, I think this is what Depends-On is for 09:50:16 Yes, I think we can use Depends-On for that. 09:51:58 There was twh arguments. First one is what you describe. Second one is the API call test with blazrclient can't detect API schema error if we implemented blazar and blazarclient with wrong schema. 09:52:27 s/twh arguments/ my two arguments/ 09:53:54 both with blazarclient and without blazarclient looks good. 09:54:08 last 5 mins. 09:54:43 masahito: I am not sure I understand the second argument. What if the Tempest REST client uses the wrong schema too? 09:58:42 For example, if a BP tries to add 'foo' key in create lease API but implements it with 'bar' in blazar and blazarclient, the tempest can't detect the error. 09:59:40 Tempest tests should follow only API schema listed in API reference, shouldn't follow client. 10:01:06 We could have two types of scenarios in Tempest, API schema test and Scenario test. 10:01:43 For first test, we should tempest's original client. For second test, it's okay to use blazarclient. 10:02:16 btw, running out time. Please move to #openstack-blazar to continue :-) 10:02:31 ok 10:02:58 masahito: I didn't realize we had API schema tests, where are they? 10:03:20 OK let's move 10:03:26 thanks all. 10:03:29 #endmeeting