| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-06-19 | |||
| 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. | |