| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-03-13 | |||
| 03:31:50 | Li_Liu | no problem on my side | |
| 03:31:55 | shaohe_feng_ | I agree | |
| 03:31:58 | Coco_gao | OK, thank you are for the advice. | |
| 03:32:05 | Coco_gao | all | |
| 03:32:07 | wangzhh | Of course. But how to handle device like gpu, <device_name>_<address>? | |
| 03:32:24 | Sundar | Coco_gao: I think it is ok to make it unique because: there is some proposed convention to name nested RPs like '<hostname>_<numaNode>_<x>' and x must be unique within a node anyway for us. | |
| 03:32:25 | shaohe_feng_ | just keep id/uuid unique. it it machine readable. | |
| 03:33:13 | shaohe_feng_ | unique in a node is ok. | |
| 03:33:18 | wangzhh | shaohe, when driver report a device, it does not have a uuid. | |
| 03:33:31 | shaohe_feng_ | not need global | |
| 03:33:49 | shaohe_feng_ | wangzhh: agent gen one for it. :) | |
| 03:34:05 | shaohe_feng_ | bus is also unique. | |
| 03:34:17 | shaohe_feng_ | bus is also machine readable. | |
| 03:34:30 | Coco_gao | Sundar, the problem is how to generate x to make sure same card is using the same x when reporting. | |
| 03:34:56 | wangzhh | shaohe, agent will generate the uuid every time? | |
| 03:35:08 | shaohe_feng_ | wangzhh: no. just once. | |
| 03:35:16 | shaohe_feng_ | wangzhh: it need to check the bus. | |
| 03:35:35 | shaohe_feng_ | wangzhh: on a node, bus is used for machine read . | |
| 03:35:51 | shaohe_feng_ | on a cluster, uuid is used for machine read | |
| 03:36:06 | Sundar | There may not be a PCI bdf in all hypervisors. | |
| 03:36:09 | wangzhh | shaohe, I suppose you mean to generate it at first time. | |
| 03:36:23 | shaohe_feng_ | Coco_gao: the x can be generated by the bus. | |
| 03:36:33 | shaohe_feng_ | Coco_gao: let me show you an example | |
| 03:36:37 | shaohe_feng_ | wangzhh: yes. | |
| 03:36:44 | Coco_gao | thanks shaohe | |
| 03:36:51 | Li_Liu | if there's no bdf, can we use uuid? | |
| 03:37:35 | shaohe_feng_ | Li_Liu: there's another identification without bdf | |
| 03:37:36 | shaohe_feng_ | for | |
| 03:37:38 | wangzhh | But agent doesn't know which time it is. | |
| 03:37:51 | wangzhh | shaohe_feng_ | |
| 03:38:13 | shaohe_feng_ | wangzhh: it need to check. if the bus not in the db, then it is the first time. | |
| 03:38:14 | Li_Liu | shaohe_feng_, sure that also works | |
| 03:38:38 | shaohe_feng_ | seems mdev has a uuid. | |
| 03:38:48 | shaohe_feng_ | and usb has it own bus. | |
| 03:38:53 | Sundar | The driver should report a unique id within the node for each device. It could be PCI bdf for libvirt or whatever is unique for PowerVM and others | |
| 03:38:54 | wangzhh | If so, agent should query db first. do something like diff? | |
| 03:39:08 | Sundar | Then that could be the x factor | |
| 03:39:37 | Sundar | wangzhh: No, agent should not query db. For 2 reasons: scaling, upgrades can change db schema | |
| 03:39:46 | shaohe_feng_ | wangzhh: yes. wen agent start. ti should sync with db firstly | |
| 03:39:47 | wangzhh | +1 | |
| 03:39:50 | shaohe_feng_ | when | |
| 03:40:31 | wangzhh | shaohe_feng_ agent doesn't query db now. | |
| 03:40:33 | shaohe_feng_ | Sundar: no, it should sync when it start. and can keep the info in cache. | |
| 03:40:57 | Sundar | Agent should not keep state. Even if it reads db at startup, it cannot assume that it will remain in sync, because operator can update config | |
| 03:41:25 | Sundar | No cache, please. We will hit all kinds of issues with stale caches, aging, etc. | |
| 03:41:28 | Li_Liu | shaohe_feng_, is the cache only containing the information related to the node? | |
| 03:41:39 | shaohe_feng_ | yes. | |
| 03:41:41 | wangzhh | Agree with sundar at this part. :) | |
| 03:41:49 | shaohe_feng_ | it's own node info. | |
| 03:42:12 | shaohe_feng_ | let me show you what I do. | |
| 03:42:20 | Li_Liu | Sundar, I think it should be ok if it only holds its own information in cache | |
| 03:42:53 | wangzhh | shaohe_feng_ haha talk is cheap, show me your code. :) | |
| 03:42:54 | Sundar | Li_Liu: The operator may want to disable or enable specific devices, or do other config. | |
| 03:43:21 | shaohe_feng_ | wangzhh: yes, I do show you code | |
| 03:43:28 | Coco_gao | before diff, the agent should get the old driver ovo, is that from db or cache? | |
| 03:43:30 | wangzhh | Cool. | |
| 03:43:34 | shaohe_feng_ | wangzhh: I have implemented it. | |
| 03:43:43 | Sundar | Li_Liu: Then we have to propagate such changes to each agent, ensure that it has received it, etc. The agent doesn't need any state for discovery -- just add a unique field that driver reports. | |
| 03:43:53 | shaohe_feng_ | I report the placement by: device_name@host this is unique | |
| 03:44:07 | shaohe_feng_ | and I just pud the device_name in cyborg db | |
| 03:44:27 | shaohe_feng_ | it can works well, no any conflict, | |
| 03:44:28 | Coco_gao | I agree with shaohe. | |
| 03:44:51 | shaohe_feng_ | for placement use device_name@host for index. | |
| 03:45:02 | Sundar | Coco_gao: Again, there are some conventions proposed for nested RP names. I am still trying to find the spec/doc where I saw that. | |
| 03:45:06 | shaohe_feng_ | but cyborg does not use device_name for index. | |
| 03:46:54 | shaohe_feng_ | Sundar: that's 2 things, but if you want to keep it same. it is OK. | |
| 03:47:50 | Sundar | shaohe_feng: There's no point in making them different. The only reason why we have a deployable name is to report to placement | |
| 03:47:51 | shaohe_feng_ | the big problems it not this. | |
| 03:48:20 | Li_Liu | Sundar, please help to find out the conventions. shaohe_feng_, could you share you code with us? | |
| 03:48:37 | shaohe_feng_ | the big problems is enumeration. | |
| 03:48:41 | xinranwang | maybe keep deployable name unique on same compute, and add hostname like "@host" when report to placement. | |
| 03:48:45 | Li_Liu | It seems we need some further discussion on this issue, we can discuss it in tomorrow's zoom sync | |
| 03:48:55 | xinranwang | i believe that's what shaohe_feng_ did. | |
| 03:49:37 | shaohe_feng_ | Li_Liu: if restart, and some change on the host. the enumeration may change the bus of a same device. | |
| 03:50:05 | Li_Liu | shaohe_feng_, yea, I know | |
| 03:50:15 | shaohe_feng_ | I means cloud provider may resize the hardware on the host | |
| 03:50:24 | shaohe_feng_ | so that's we really need to care | |
| 03:51:08 | shaohe_feng_ | after all, the machine need bus to identify a device not the name. | |
| 03:51:56 | shaohe_feng_ | Li_Liu: yes. maybe we care the same thing. | |
| 03:52:32 | Li_Liu | shaohe_feng_, driver should do the mapping from bus to device name/id I believe | |
| 03:53:01 | shaohe_feng_ | Li_Liu: yes, that's what we need to improve. | |
| 03:54:40 | Li_Liu | ok | |
| 03:55:12 | Sundar | @all: Please look at https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/stein/approved/numa-topology-with-rps.rst?h=refs/changes/24/552924/14#n163 | |
| 03:55:28 | Coco_gao | shaohe_feng, that will be ok if name change, the conductor will delete the old device with name1 and add new device to db with name2. But actually, the db is exactly the same with the real situation. | |
| 03:55:43 | Li_Liu | Since it's pretty late for me here. Let's close it up and discuss more detail in tomorrow's sync up | |
| 03:56:05 | shaohe_feng_ | Li_Liu: OK. | |
| 03:56:33 | Coco_gao | but that name change for one device is not supposed to be frequent. | |
| 03:56:50 | shaohe_feng_ | Coco_gao: yes. not frequently. | |
| 03:57:17 | shaohe_feng_ | seldom resize the baremetal | |
| 03:59:41 | Li_Liu | Alright, let's call the meeting for today. Have a good night/day where ever you are | |
| 03:59:45 | Li_Liu | #endmeeting | |
| 03:59:47 | openstack | Meeting ended Wed Mar 13 03:59:45 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 03:59:48 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-03-13-03.01.html | |
| 03:59:49 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-03-13-03.01.txt | |
| 03:59:50 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-03-13-03.01.log.html | |
| 13:16:27 | diga | Hello everyone | |
| 13:16:33 | diga | do we have meeting today ? | |
| #openstack-cyborg - 2019-03-18 | |||
| 03:07:13 | openstackgerrit | chenker proposed openstack/cyborg master: Add the module used but not be imported https://review.openstack.org/643842 | |
| 03:11:10 | openstackgerrit | chenker proposed openstack/cyborg master: Add the module used but not be imported https://review.openstack.org/643842 | |
| 08:09:20 | openstackgerrit | chenker proposed openstack/cyborg master: Fix method 'test_discover' assertError in test_driver.py https://review.openstack.org/643874 | |