03:01:46 <Sundar> #startmeeting openstack-cyborg 03:01:47 <openstack> Meeting started Wed Jun 19 03:01:46 2019 UTC and is due to finish in 60 minutes. The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:01:50 <openstack> The meeting name has been set to 'openstack_cyborg' 03:01:58 <Sundar> #topic Roll call 03:02:16 <Sundar> #info Sundar 03:02:19 <Biwei> #info Biwei 03:02:28 <Coco_gao> #info Coco_gao 03:02:49 <Sundar> Hi Biwei, Coco_gao 03:02:57 <Biwei> Hi Sundar 03:03:30 <Sundar> Let's wait a minute for folks to join 03:03:35 <Sundar> Hi wangzhh 03:03:41 <Coco_gao> I am sorry that I may miss two week's meeting 03:03:47 <wangzhh> Hi Sundar. :) 03:04:14 <Sundar> Coco_gao: You will miss next 2 weeks? 03:04:31 <Coco_gao> Nope 03:04:34 <Coco_gao> I missed 03:04:55 <Sundar> Ah, got it. NP. 03:04:58 <Coco_gao> last two week's meeting. 03:05:02 <Sundar> Agenda: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda 03:05:49 <Sundar> Please take a look. 03:05:55 <ikuo_o> #info ikuo_o 03:06:10 <Sundar> Anything to be added to the agenda? 03:06:45 <Sundar> #topic Device profile names 03:07:16 <Sundar> One question that has come up, esp. in the review of https://review.opendev.org/#/c/626057/, is whether device profiles are unique, or should be unique 03:07:56 <Sundar> My answer is in the response to the comment in Line 466 of https://review.opendev.org/#/c/626057/10/cyborg/db/sqlalchemy/api.py 03:08:06 <Sundar> Please take a look first. Then, we'll discuss. 03:09:06 <Sundar> Can you all see it? 03:09:48 <wangzhh> Yep. 03:11:17 <wangzhh> As my comment in line. The name should be unique. 03:11:35 <Coco_gao> In the db, it was unique 03:12:24 <Coco_gao> I see Li posted that the name should not be used to identify. 03:12:59 <Sundar> wangzhh: https://review.opendev.org/gitweb?p=openstack/cyborg.git;f=cyborg/db/sqlalchemy/models.py;hb=refs/changes/57/626057/10#l183 03:13:04 <Sundar> It is unique in the db 03:13:51 <Sundar> Coco_gao: given my response, do you agree that names must be unique and should be used to identify DPs? I am ok with using UUIDs also, if there is a need 03:15:43 <wangzhh> Cool. I think it's better to identify DP with UUID. 03:15:49 <Coco_gao> For other projects, we usually use UUIDs not the names. 03:16:52 <Coco_gao> +1 better to use UUID 03:17:27 <Sundar> Yes. But, if we use UUIDs in all APIs, the operator would have to embed DP uuids in flavors, instead of names. 03:18:26 <wangzhh> We just use UUIDs in internal API. For the rest api, name is more friendly. 03:18:50 <ikuo_o> Can we find UUIDs from name by using APIs? 03:19:14 <wangzhh> Just like nova. We can support nova show VM_UUID/VN_NAME. 03:19:17 <Sundar> ikuo_o: Yes, at the cost of a db access 03:19:38 <ikuo_o> thanks. 03:20:08 <Sundar> wangzhh: Internal APIs -- e.g. from API layer to object layer -- can use UUIDs. The problem then is that the API layer needs to do a db lookup to get the uuid from the name, right? 03:20:26 <wangzhh> Yes. 03:20:58 <Coco_gao> So the name should also be unique? 03:21:22 <Coco_gao> one uuid corrosponds to one name? 03:21:47 <Sundar> Coco_gao: The name has to be unique anyway. If not, when the operator puts a dp name in a flavor, it would be ambiguous. 03:21:56 <Sundar> Yes, one uuid == one name 03:22:40 <Sundar> I think an API to rename a device profile would have to use UUIDs. We don't have that today. 03:23:00 <Sundar> We can do that in the future once Cyborg is is use 03:23:05 <Sundar> *in use 03:23:10 <Coco_gao> Agree 03:23:28 <wangzhh> +1 Great. 03:23:38 <Coco_gao> UUIDs is not urgent before Cyborg is in use 03:24:23 <Coco_gao> If we have time, better to add that, but that's not urgent so far. 03:25:21 <Sundar> One caveat: we have /v2/device_profiles/{name} as a valid URL 03:25:46 <Sundar> So, if we want a specific UUID, it would have to be a query like: /v2/device_profiles?uuid={uuid} 03:26:35 <Sundar> But Nova does not use the former: it only does /v2/device_profiles?nam={name} 03:26:48 <Sundar> So, we have some flexibility to change the former 03:29:57 <Sundar> Any thoughts? 03:31:10 <Coco_gao> You mean we should focus on the name API then see if we need UUID API? 03:31:19 <Sundar> Yes 03:31:25 <ikuo_o> I'm sorry I have to leave now... if any question to NTT, yuki_t will answer. 03:31:34 <Coco_gao> seems good for me 03:31:51 <Sundar> Take care, ikuo_o. 03:32:00 <wangzhh> Emmm, fine. 03:32:01 <Sundar> Thanks, Coco_gao. 03:32:33 <Sundar> wangzhh: Thanks 03:32:48 <Sundar> #topic Format for controlpath_id and attach_handles 03:33:37 <Sundar> Pleasee line 79 https://review.opendev.org/#/c/626057/10/cyborg/accelerator/drivers/fpga/intel/driver.py 03:34:17 <Sundar> The intended usage of controlpathid_info and attach_handle_info, IMHO, are like {domain: 0, bus: ... } 03:34:33 <Sundar> But apparently it got encoded as a string '0000:05...' 03:34:59 <Sundar> IMHO, that is not good because it is an implcit syntax. That may possibly vary among systems? 03:35:13 <Sundar> It is better to make it an explicit dictionary or JSOn string 03:36:36 <Sundar> Thoughts? 03:37:55 <Coco_gao> Agree to use JSON string and change the related patches. 03:38:15 <Sundar> Good, thanks 03:38:58 <wangzhh> All look good to me. Just effort. 03:39:27 <Sundar> wangzhh: Yes. Hopefully, only the driver report needs to be changed? 03:39:37 <Sundar> It is a string either way 03:40:02 <Coco_gao> Dose the json string have the specific keys? 03:40:02 <wangzhh> Yes. I think so. 03:40:08 <Sundar> Cool 03:40:11 <Sundar> #topic Need to close specs 03:40:21 <Coco_gao> only domain and bus? 03:40:24 <Sundar> Train release schedule: https://releases.openstack.org/train/schedule.html 03:40:30 <Coco_gao> or it varies? 03:40:34 <Sundar> Coco_gao: No, all 4. 03:40:53 <Sundar> I had "..." for other 2 03:41:07 <Sundar> We are past Milestone 1 of Train 03:41:23 <Coco_gao> Maybe we add a ovo for that? 03:41:24 <Sundar> I am a little concerned that the core specs are not still not reviewed. 03:41:25 <openstackgerrit> ShaoHe Feng proposed openstack/cyborg master: bug fix: deploy every cyborg components correctly https://review.opendev.org/659292 03:41:49 <Sundar> Nova-Cyborg spec got two +2s and singificant +1s. So, that is on track 03:42:10 <Coco_gao> the workflow is not +1? 03:43:19 <Coco_gao> OK, I will review the specs as soon as possible. 03:43:32 <Coco_gao> and update related pathes. 03:43:35 <Sundar> Well, one reviewer posed a question. So, it was decided not to merge the spec till I answered the question. I did that today and updated the spec. 03:43:56 <Sundar> Thanks, Coco_gao 03:43:58 <Coco_gao> I see 03:44:06 <Coco_gao> Thank you for you efforts 03:44:12 <Sundar> In the list https://review.opendev.org/#/q/status:open+project:openstack/cyborg-specs+owner:Sundar, please review just the top 3 03:44:35 <Coco_gao> It always not easy to merge nova code. 03:44:54 <Sundar> Or Nova specs :) 03:45:39 <Sundar> I suggest we use the Zoom meeting time tomorrow to review the Cyborg specs. 03:45:45 <Coco_gao> OK. 03:45:49 <Coco_gao> I will join then 03:45:59 <Sundar> Great 03:46:08 <wangzhh> OK. Got it. 03:46:28 <Coco_gao> what's the time? 03:46:38 <Sundar> Cool. Hope Li_Liu and others can join. Can one of you please ping them? 03:46:58 <Sundar> UTC 0130 (China @9:30 am Thu; US West Coast @6:30 pm Wed) 03:47:03 <Coco_gao> I will ping Li to see if he has time. 03:47:53 <wangzhh> We can ping others in the wechat group. @ everyone. 03:48:17 <Coco_gao> yes 03:48:17 <Sundar> Sure 03:48:33 <Sundar> #topic AoB 03:48:37 <wangzhh> BTW, NTT guys... 03:48:49 <Coco_gao> Yes, will NTT jion? 03:49:12 <Sundar> yuki_t: Can you join and ask ikuo_o too? 03:49:16 <wangzhh> They can't access wechat, may miss the message. 03:49:34 <Coco_gao> Sundar maybe you can send the meeting invitation? 03:49:58 <Sundar> I will email ikuo_o. I can resend the Zoom meeting invitation to all of you. 03:50:10 <Coco_gao> that's good 03:50:19 <wangzhh> OK 03:50:39 <Coco_gao> Bye, Sundar, have a good night~ 03:50:54 <Sundar> Sent now 03:51:06 <Sundar> Thanks, all. Have a good day. 03:51:13 <Sundar> #endmeeting