| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-02-12 | |||
| 21:41:57 | openstackgerrit | Merged openstack/cyborg master: Add new DB schema: sqlachemy and alembic scripts. https://review.openstack.org/625630 | |
| #openstack-cyborg - 2019-02-13 | |||
| 03:09:14 | Li_Liu | Hi guys | |
| 03:09:18 | Li_Liu | let's get started | |
| 03:09:43 | Li_Liu | #startmeeting openstack-cyborg | |
| 03:09:44 | openstack | Meeting started Wed Feb 13 03:09:43 2019 UTC and is due to finish in 60 minutes. The chair is Li_Liu. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 03:09:45 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 03:09:47 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 03:09:55 | Li_Liu | #topic Roll Call | |
| 03:10:02 | Sundar | #info Sundar | |
| 03:10:04 | Li_Liu | #info Li_Liu | |
| 03:10:13 | xinranwang | #info xinranwang | |
| 03:10:22 | Yumeng_ | #info Yumeng | |
| 03:10:28 | Li_Liu | Hi guys | |
| 03:10:39 | Sundar | #help | |
| 03:10:45 | Sundar | Hi Li | |
| 03:10:49 | wangzhh | #info wangzh | |
| 03:11:07 | Li_Liu | one suggestion tho, can we move the engineering call to a different time? it's a bit close to the regular IRC | |
| 03:11:36 | Li_Liu | Say, move it to a date between 2 irc meetings | |
| 03:11:54 | Sundar | I am fine with other days. I think we did a Doodle poll and chose this | |
| 03:12:37 | Li_Liu | I feel like we just talked no long ago.. and don't have much update since then | |
| 03:12:41 | Sundar | May be we can do Thursday eve US time, Fri morn China time? | |
| 03:12:54 | Li_Liu | That sound fine to me | |
| 03:13:12 | Sundar | I see. I believe the agenda for theis call and the engineering call will be somewhat different | |
| 03:13:24 | Sundar | This call is about status updates, process etc. | |
| 03:13:36 | Sundar | Whereas the engineering call goes more into depth | |
| 03:13:56 | Li_Liu | I know, but moving them apart makes more sense | |
| 03:14:21 | Li_Liu | wangzh, do you know if coco is coming? | |
| 03:14:29 | Li_Liu | She's the super star right now :P | |
| 03:14:44 | wangzhh | Not sure. | |
| 03:14:51 | xinranwang | Friday is fine for me, better before 10:30. :) | |
| 03:15:20 | Li_Liu | #topic status updates | |
| 03:15:33 | Li_Liu | Good thing is her patch get merged | |
| 03:15:50 | Li_Liu | still waiting for the OVO one | |
| 03:16:01 | Li_Liu | Sundar, I saw you still have some comments | |
| 03:16:44 | Sundar | I noted that they are not blocking comments. We'll let the patch merge and update the details after that | |
| 03:16:44 | Yumeng_ | I have a quick question about db schema, should we also change the type of device to enum instead of string? | |
| 03:17:35 | Li_Liu | Sundar, could you give it a +2 then? | |
| 03:17:55 | Sundar | Li_Liu: Sure. But it is already merged? | |
| 03:18:38 | Li_Liu | Sundar, i mean this one https://review.openstack.org/#/c/624138/ | |
| 03:20:38 | Sundar | Li_Liu: Can we just address the comments that I did not mark as ignorable? | |
| 03:20:55 | Sundar | For example, the source file is called driver_handle.py instead of attach_handle.py | |
| 03:21:55 | Li_Liu | sure, I am just checking to see if the patch is ready to merge after the comments being addressed | |
| 03:22:24 | Li_Liu | that's cool | |
| 03:22:26 | Sundar | Yes, I think so. Just address the basics, and I'll give a +2 | |
| 03:23:03 | Li_Liu | Looking at the stories at https://storyboard.openstack.org/#!/story/2004249 | |
| 03:24:07 | Sundar | I think we should hold off on 27782. | |
| 03:24:37 | Li_Liu | why? | |
| 03:24:49 | Sundar | If we start adding stuff to placement now and change that after Stein, we have to do a reshaping of the provider tree and what not, which could be a pain for us, Nova or both | |
| 03:25:11 | Sundar | It is better to put that in the feature branch, get Nova to sign off, and then merge it | |
| 03:25:22 | Li_Liu | that one does not involve placement yet tho | |
| 03:25:39 | Li_Liu | it's just doing the update from the agent side | |
| 03:25:50 | Li_Liu | Hi Yikun | |
| 03:25:54 | Sundar | 27782: Conductor should update Placement | |
| 03:25:59 | yikun | hello | |
| 03:26:08 | yikun | soryy for late | |
| 03:26:20 | Sundar | Welcome, yikun. NP. | |
| 03:26:28 | yikun | Sundar: :) | |
| 03:26:50 | Li_Liu | Sundar, ah. my bad.. looked at a wrong one. | |
| 03:26:53 | Sundar | Good to have you join the team :) | |
| 03:27:25 | Sundar | Li_Liu: NP. The other 4 in that story are doable. | |
| 03:28:33 | Li_Liu | Sundar, can we borrow some code from your pilot branch for this? | |
| 03:28:46 | Li_Liu | I mean for the update placement piece | |
| 03:29:52 | Li_Liu | or quickly patch it up to work with placement for some simple demo | |
| 03:29:53 | Sundar | Li_Liu: for Placement? I don;t have it. :) I am directly writing a fake device by calling placement API from a script, rather than have the conductor take discovered devices and update Placement | |
| 03:30:10 | Li_Liu | I see | |
| 03:30:30 | Sundar | Yes, once we have the Cyborg master branch code, I will fold that into the feature branch somehow for a full end-to-end flow | |
| 03:30:32 | Li_Liu | ok, let's just focus on the rest 4 stories | |
| 03:30:37 | Li_Liu | for now | |
| 03:31:32 | Li_Liu | Yumeng was asking "I have a quick question about db schema, should we also change the type of device to enum instead of string?" | |
| 03:31:39 | Li_Liu | Sundar, could you comment on that? | |
| 03:32:33 | Sundar | Yumeng_, Li_Liu: Sure, makes sense to me. | |
| 03:32:35 | Li_Liu | Hi Shaohe | |
| 03:32:38 | Sundar | However, ... | |
| 03:32:51 | shaohe_feng_ | hi Li_Liu | |
| 03:33:26 | Sundar | There could be cards in the neat future that may involve multiple RCs. The device type wil translate into one of those RCs, e.g. CUSTOM_ACCELERATOR_FPGA. Others will be custom RCs | |
| 03:33:33 | Sundar | *near | |
| 03:34:35 | Sundar | yikun: I replied to your comments in https://review.openstack.org/#/c/630427/ | |
| 03:34:49 | Yumeng_ | Sundar, Li_Liu: Thx. Got it. Then I will do the change later. | |
| 03:34:50 | Li_Liu | in that case, string makes more sense | |
| 03:35:23 | yikun | Sundar: yep, I see, I was just a little wired why we should keep a arq obj in cyborg | |
| 03:35:24 | Li_Liu | Hi CoCo | |
| 03:36:03 | Coco_gao | Hi all | |
| 03:36:04 | yikun | IMO, if it's something like pcireq, it should be an obj in nova. | |
| 03:36:10 | Coco_gao | #info Coco_gao | |
| 03:36:38 | Sundar | yikun: The ARQ is a combination of a Neutron port and vif. It is used for binding and attaching. | |
| 03:36:57 | Sundar | It is defined between Nova and Cybprg | |
| 03:37:06 | yikun | and the other thing, about ARQ or AcceleratorRequst, It's okay to me in db or obj level, but I think we should spell completely in API at least. | |
| 03:37:43 | Li_Liu | For external APIs, sure | |
| 03:38:45 | Sundar | Ok | |
| 03:39:00 | Coco_gao | Spell completely is more common in OpenStack Projects, I agree | |
| 03:39:29 | Kevin_Zheng | like in most projects, we only use abbreviations for well-kown concepts like IPs, DNS | |
| 03:40:00 | Kevin_Zheng | we don't use this kind of abbreviations for some thing like this | |
| 03:40:21 | Li_Liu | thanks for the comments | |
| 03:40:42 | Kevin_Zheng | like we don't call GET /AC in placement, we callGET /allocation_candidates | |
| 03:41:03 | Coco_gao | Thanks for all this advice | |
| 03:41:40 | Sundar | So, we are talking only of URLs, not method names? | |
| 03:41:41 | Li_Liu | Coco, you can address them in a future patch when you have time | |
| 03:41:51 | Kevin_Zheng | and ARQ is a well-known abbreviation for Automatic Repeat-reQuest | |
| 03:42:05 | Kevin_Zheng | it could be really easy to get confused | |
| 03:42:12 | Li_Liu | lol | |