| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-06-09 | |||
| 06:04:15 | openstackgerrit | Brin Zhang proposed openstack/cyborg master: Remove openstackdocs bug config https://review.opendev.org/734401 | |
| 06:26:48 | openstackgerrit | Brin Zhang proposed openstack/cyborg master: Enable openstackdocs config to storyboard https://review.opendev.org/734401 | |
| 06:29:03 | openstackgerrit | Brin Zhang proposed openstack/cyborg master: Enable openstackdocs config to storyboard https://review.opendev.org/734401 | |
| 06:29:39 | openstackgerrit | Brin Zhang proposed openstack/python-cyborgclient master: Enable openstackdocs config to storyboard https://review.opendev.org/734403 | |
| 07:41:54 | openstackgerrit | Shogo Saito proposed openstack/python-cyborgclient master: Fix image get to use new osc release https://review.opendev.org/734431 | |
| 08:14:41 | openstackgerrit | Merged openstack/cyborg-specs master: Switch to newer openstackdocstheme and reno versions https://review.opendev.org/731956 | |
| 08:18:08 | openstackgerrit | Brin Zhang proposed openstack/cyborg-specs master: Update docs building https://review.opendev.org/723783 | |
| 08:19:51 | openstackgerrit | Brin Zhang proposed openstack/cyborg-specs master: Remove Babel https://review.opendev.org/723783 | |
| 09:54:09 | openstackgerrit | Hervé Beraud proposed openstack/python-cyborgclient master: Use unittest.mock instead of mock https://review.opendev.org/734506 | |
| 09:54:09 | openstackgerrit | Hervé Beraud proposed openstack/python-cyborgclient master: Use unittest.mock instead of mock https://review.opendev.org/734506 | |
| #openstack-cyborg - 2020-06-10 | |||
| 09:17:17 | openstackgerrit | Hervé Beraud proposed openstack/cyborg master: Use unittest.mock instead of mock https://review.opendev.org/734328 | |
| 09:17:17 | openstackgerrit | Hervé Beraud proposed openstack/cyborg master: Use unittest.mock instead of mock https://review.opendev.org/734328 | |
| #openstack-cyborg - 2020-06-11 | |||
| 02:23:16 | openstackgerrit | Merged openstack/python-cyborgclient master: Fix a config error ralated to entry point https://review.opendev.org/734006 | |
| 03:00:22 | chenke | HI | |
| 03:00:26 | Yumeng | hi all | |
| 03:00:48 | chenke | Hi yumeng. | |
| 03:00:56 | s_shogo | Hi all | |
| 03:01:43 | Yumeng | welcome back wangzhh ^^ | |
| 03:01:57 | wangzhh | Haha long time no see. | |
| 03:02:53 | xinranwang | Hi all | |
| 03:02:57 | Yumeng | quite a long time. | |
| 03:03:03 | wangzhh | Hi xinran~~ | |
| 03:03:30 | xinranwang | wow, long time no see ya | |
| 03:03:30 | wangzhh | Yep, I can contribute rencently | |
| 03:03:39 | Yumeng | wow, cool! | |
| 03:04:06 | Yumeng | Let's start the meeting! | |
| 03:04:07 | Yumeng | #startmeeting openstack-cyborg | |
| 03:04:08 | openstack | Meeting started Thu Jun 11 03:04:07 2020 UTC and is due to finish in 60 minutes. The chair is Yumeng. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 03:04:09 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 03:04:11 | openstack | The meeting name has been set to 'openstack_cyborg' | |
| 03:04:14 | Yumeng | #topic Roll call | |
| 03:04:27 | Yumeng | #infor Yumeng | |
| 03:04:36 | Sundar | Hi all | |
| 03:04:40 | Sundar | #info Sundar | |
| 03:04:41 | swp20 | Hi all | |
| 03:04:43 | wangzhh | #info wangzhh | |
| 03:04:50 | s_shogo | #info s_shogo | |
| 03:04:53 | xinranwang | #info xinranwang | |
| 03:04:54 | swp20 | #info swp20 | |
| 03:04:54 | chenke | #info chenke | |
| 03:05:00 | Yumeng | #topic Agenda | |
| 03:05:42 | Yumeng | we will start from SmartNic topic. | |
| 03:05:48 | Yumeng | #topic SmartNic | |
| 03:06:05 | Sundar | Thanks, Yumeng | |
| 03:06:26 | Sundar | I'd like to followup on our PTG discussion | |
| 03:06:56 | Sundar | Just to set the background: there are broadly two kinds of 'smart NICs'. A smart NIC may have a single ‘device’ that combines the accelerator and the NIC, or two (or more) components in a single PCI card, with separate accelerator and NIC components. | |
| 03:07:25 | Sundar | We should model the smart NIC as a single RP representing the combined accelerator/NIC for the first case. Agreed, right? | |
| 03:08:22 | Sundar | Yumeng, xinranwang, chenke, all : ^ | |
| 03:09:36 | Sundar | Anybody around?! | |
| 03:09:41 | chenke | HI sundar. | |
| 03:09:50 | wangzhh | I didn't follow for a long time, just listen at first.... | |
| 03:10:04 | Yumeng | yes, agree. I may miss some in the PTG. But agree. | |
| 03:10:21 | chenke | Do you means the first case is only one region ,right? | |
| 03:11:07 | Sundar | The concept of region is specific to FPGAs. A smart NIC may not have FPGAs. May be it is a NIC ASIC + many ARM cores. | |
| 03:11:30 | s_shogo | As a first step, that is good. agree. | |
| 03:11:52 | xinranwang | It may have fpga as well. I think we need consider that. I think subprovider can support this. | |
| 03:11:54 | Sundar | Great. For the second case, we could have a hierarchy with separate RPs for the accelerator and the NICs, and a top-level resource-less RP which aggregates all the children RPs and combines their traits | |
| 03:12:33 | Sundar | xinranwang: Of course. My point was, the concept of region can be used if it is a FPGA, not otherwise. | |
| 03:12:55 | chenke | Sundar ok. got it. | |
| 03:13:35 | Sundar | For example: N3000 may be modeled as two RPs - one for the FPGA and one for the 2 Fortville NICs. Perhaps each Fortville NIC cna be a separate RP. That is up to us. | |
| 03:13:54 | xinranwang | I agree. | |
| 03:14:49 | Sundar | Correspondingly, Cyborg will create a separate deployable for each component, and a top-level deployable that contains all component deployables. | |
| 03:15:38 | Sundar | The resources and traits of the children RPs are exposed in the top-level RP; similarly, the accelerators and attributes of children deployables are in the top-level deployable. | |
| 03:16:03 | xinranwang | It corresponds to the device topology. Cyborg can report like this. If we need interact with other project like neutron, we should consider more. Because neutron report to placement if bandwidth feature is enabled. | |
| 03:17:00 | Sundar | xinranwang: I am hoping that Cyborg can create RPs for all components, not leave it to neutron even for bandwidth provider. Otherwise, it gets a bit complicated. | |
| 03:17:20 | Sundar | Neutron can, of course, use the RP that Cyborg created | |
| 03:17:49 | xinranwang | The physnet is neutron who's in charge of, not sure cyborg should take it over. | |
| 03:18:10 | xinranwang | it a network concept | |
| 03:18:16 | xinranwang | s/it/it's | |
| 03:18:19 | Sundar | Yes. The physnet is best left to the admin or the OpenStack installer | |
| 03:18:47 | Sundar | Cyborg shouldn't get in the way. | |
| 03:19:23 | Sundar | However, we could model the physnet as a trait. Cyborg creates the NIC's RP but doesn't want to manage the physnet trait on that RP. | |
| 03:19:37 | xinranwang | what is neutron's bandwidth feature enabled, how will cyborg know that neutron report to placement as well. | |
| 03:19:44 | xinranwang | s/what is/what if | |
| 03:19:56 | Sundar | So, we can levae it to the admin or installer however they do it. That is how PCI whitelist handles physnet anyway. | |
| 03:20:47 | xinranwang | I am not sure this will be accepted by the community. I am still thinking about it. | |
| 03:21:03 | Sundar | xinranwang: Good point, I have thought about it. Hoping we can reach agreement with Neutron that they need not create RPs in this case. | |
| 03:21:51 | Sundar | What won;t be accepted:: phsynet as trait, or Cyborg creating the RPs for NICs? | |
| 03:22:32 | xinranwang | Anyway, I will propose a spec in nova community and everyone can discuss there. But I am still thinking about which solution I should choose to propose firstly, and others will be an alternative. | |
| 03:23:19 | Sundar | We should have some internal agreement hopefully before we approach others | |
| 03:24:39 | xinranwang | Yes, of course | |
| 03:24:42 | Sundar | Anyways, what do others think of Cyborg creating RPs for the NIC side too? It will do that for the first type where the accelerator and NIC are combined. To keep it uniform, we should do that for the second case too | |
| 03:25:16 | Sundar | Otherwise, we'll have different solutions for different types of smart NICs, depending on whether they have a single component or multiple components | |
| 03:26:36 | Sundar | Yumeng, chenke, s_shogo, all: ^ | |
| 03:27:42 | Yumeng | so if Admin use Placement CLI to set traits, then admin should know “physicalnet” and RP RC of this smartNIC. so does that mean admin needs to GET physicalnet first, then GET RP,RC, then report? | |
| 03:27:43 | Sundar | Anyway, I'll throw another idea in. Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. | |
| 03:28:36 | xinranwang | s_shogo: | |
| 03:28:42 | Sundar | Yumeng: the admin needs to get the RP for the NIC and set the trait there. he could do so via the installer | |
| 03:28:48 | xinranwang | Shogo, are you around? | |
| 03:29:35 | s_shogo | xinranwang: yes, I'm considering about that, with thinking about the operation of N3000.. | |
| 03:29:59 | Sundar | Good. Thanks, s_shogo | |
| 03:30:07 | Sundar | To repeat: Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. | |
| 03:30:23 | Sundar | That common device profile would look like this: | |
| 03:30:33 | chenke | Sundar: I am not familar with this. | |
| 03:30:58 | xinranwang | s_shogo: lol, np. Just for other things. Haibin can not access to IRC, and he met some problem with this https://review.opendev.org/#/c/698190/ , could you connect him, maybe by email? | |
| 03:31:45 | Sundar | chenke: ok, np | |
| 03:32:01 | Sundar | { "name": "my-smartnic-dp", | |
| 03:32:03 | s_shogo | Yes, I agree that from operator 's point of view > same way to treat device profile | |
| 03:32:18 | Sundar | { "name": "my-smartnic-dp", | |
| 03:32:26 | Sundar | "groups": [{ | |