| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-06-05 | |||
| 03:06:10 | wangzhh | Coco said she has other bussiness. Will miss this meeting. | |
| 03:06:24 | Sundar | Please see the thread starting from http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006543.html | |
| 03:06:41 | Sundar | wangzhh, thanks for letting us know | |
| 03:07:38 | Sundar | For the client, we have 2 options: write our own plugin (as many other projects seem to have done) or integrate with openstackclient repo (less work, but need to depend on the repo owners for reviews) | |
| 03:08:56 | Sundar | For the 2nd option, there are some guidelines and rules, which seem ok to me. But we have to discuss with the repo owners about their opinions | |
| 03:08:57 | xinranwang | Hi all | |
| 03:09:04 | xinranwang | #info xinranwang | |
| 03:09:11 | Sundar | Hi xinranwang | |
| 03:09:34 | Sundar | Writing a plugin may not be that bad, given the previous examples | |
| 03:09:39 | Sundar | What do you all think? | |
| 03:09:58 | yikun | So, we have to choose one from these two option? | |
| 03:10:46 | Sundar | yikun, do you have any other option? These seem like the 2 ways that are recommended or have precedents. We could do neither and write our own client -- but that is not recommended | |
| 03:10:47 | wangzhh | yikun, I think so. Do u have other suggestions? | |
| 03:10:56 | xinranwang | I think writing our own plugin is better | |
| 03:11:16 | ikuo_o | Thanks for summarizing. | |
| 03:11:26 | xinranwang | More indenpendency | |
| 03:11:34 | wangzhh | Yes, I also vote the first one. Agree with xinran. | |
| 03:12:31 | ikuo_o | It is better to write plugin, but I heard the option is not prepared by OSC. | |
| 03:12:48 | ikuo_o | Maybe my misunderstanding... | |
| 03:12:49 | yikun | OK, just want to sure any other way to complete, and I also vote to the 1st | |
| 03:12:58 | Sundar | ikuo_o: "option is not prepared by OSC" -- what do you mean? | |
| 03:13:33 | Sundar | OSC folks are not recomending against plugin -- they gave us the options. | |
| 03:13:52 | xinranwang | please also consider the case where cyborg can run as a standalone project | |
| 03:14:24 | Sundar | xinranwang: Sure, both options should be compatible with standalone usage | |
| 03:15:17 | ikuo_o | If it is realized in other works, plugin is better I think. | |
| 03:15:17 | ikuo_o | I see. I thought the plugin option is difficult for OSC side, but maybe my misunderstanding | |
| 03:15:19 | wangzhh | Sundar, do u have any example of these two options? Maybe two different projects with two options. | |
| 03:15:51 | xinranwang | We do have the cyborgclient repo with some V1 APIs implemented, right? | |
| 03:16:00 | Sundar | wangzhh: There are many examples of plugins: https://docs.openstack.org/python-openstackclient/pike/contributor/plugins.html | |
| 03:16:06 | wangzhh | Thx. | |
| 03:16:20 | Biwei | https://github.com/openstack/python-cyborgclient is that what you are talking about? Xinran | |
| 03:17:11 | xinranwang | Biwei: Ah yes, thanks | |
| 03:17:14 | Sundar | wangzhh: Some examples of commands integrated with OSC: https://github.com/openstack/python-openstackclient/tree/master/openstackclient | |
| 03:17:22 | yikun | wangzhh: I think the nova is 2nd(https://github.com/openstack/python-openstackclient/blob/master/setup.cfg), and placement is 1st example | |
| 03:17:23 | Sundar | Includes compute, identity, etc. | |
| 03:17:52 | wangzhh | Cool, Thx Sundar, yikun. | |
| 03:17:52 | yikun | https://github.com/openstack/osc-placement | |
| 03:18:13 | Sundar | xinranwang: The cyborg client for v1 API is neither: it uses osc-like syntax but is not a plugin | |
| 03:18:34 | yikun | Can we complete it by 1st way first, and we our client is stable, and we switch it to 2nd way? | |
| 03:18:48 | Sundar | ikuo_o: IIUC, you are also voting for plugin? or are you still considering? | |
| 03:18:51 | yikun | Can we complete it by 1st way first, and when our client is stable, and we switch it to 2nd way? | |
| 03:19:15 | ikuo_o | Sundar: I vote plugin. | |
| 03:19:19 | Sundar | yikun: What would motivate us to switch like that? | |
| 03:20:03 | yikun | We need +2+a right at first, because we perhaps frequently at first version. | |
| 03:20:04 | xinranwang | Is there any necessity to switch to 2nd way? | |
| 03:20:33 | yikun | xinranwang: I think the only reason is sundar mentioned, the osc team want 2nd way. - -# | |
| 03:21:01 | Sundar | OK. Shall we say it is unanimously agreed that we will go with the plugin option (at least for now)? | |
| 03:21:21 | xinranwang | yikun: lol | |
| 03:21:26 | ikuo_o | ok | |
| 03:21:42 | xinranwang | Sundar: I am fine with 1st one | |
| 03:21:45 | Biwei | yes, plugin sounds good | |
| 03:22:15 | Sundar | #agreed Cyborg client v2 shall be written as a osc plugin. It was previously decided that it will use the openstack SDK. | |
| 03:22:25 | Sundar | Thanks, Biwei and all | |
| 03:22:45 | yikun | +1， and I think the placement repo would be a good example for us, https://github.com/openstack/osc-placement | |
| 03:22:53 | Sundar | #topic Cyborg API fixtures in Nova | |
| 03:23:08 | Sundar | Please see Line 409 in https://review.opendev.org/#/c/603955/13/specs/train/approved/nova-cyborg-interaction.rst,unified | |
| 03:23:32 | yikun | #link https://review.opendev.org/#/c/603955/13/specs/train/approved/nova-cyborg-interaction.rst@409 | |
| 03:23:46 | Sundar | Many Nova developers have asked for a functional test in Nova which will call fake CYborg API. This is not the same as a fake CYborg driver, which we discussed before | |
| 03:24:35 | Sundar | IIUC, it is enough to do tempest CI with real hardware (no fake driver needed). That is already driven by Xinran and Biwei | |
| 03:25:18 | Sundar | But it seems we still need to an upstream CI, not 3rd party CI, which can be a Cyborg API fixture | |
| 03:25:34 | Sundar | First, does anybody have any questions on that? | |
| 03:26:06 | Biwei | what do you mean by upstream CI? | |
| 03:26:25 | Biwei | and 3rd party CI | |
| 03:26:55 | ikuo_o | I want to know those too. | |
| 03:27:30 | Sundar | 3rd party CI involves equipment from a company outside of OpenStack open infra (Zuul). Upstream CI means that it is all in ZUul, maintained by the foundation, not another company | |
| 03:27:50 | Sundar | For example, Intel may set up a FPGA-based CI and integrate that with Zuul: that's 3rd party CI | |
| 03:28:17 | Sundar | If we have a CI running in a VM with devstack, that would be upstream | |
| 03:28:24 | Sundar | Good? | |
| 03:29:10 | yikun | I guess the comments from matt was talking about is add cyborg api fixture in nova test code? | |
| 03:29:25 | yikun | Like something, the placement done: https://github.com/openstack/nova/blob/master/nova/tests/functional/fixtures.py#L79-L90 | |
| 03:29:30 | Sundar | yikun: Yes | |
| 03:29:59 | Sundar | I think Nova developers are coming from the historical experience that 3rd party hardware/CI sometimes beaks, and may take time to fix. | |
| 03:30:06 | Sundar | *breaks | |
| 03:30:38 | Sundar | A non-hardware-dependent CI is easier to maintain by the community and more reliable, even if it is not an end-to-end test | |
| 03:30:51 | Biwei | ok I see | |
| 03:30:55 | xinranwang | I understand what 3rd parth CI do, but I am confused about what upstream CI do exactly | |
| 03:31:24 | xinranwang | is it used for let nova call fake Cyborg API? | |
| 03:31:37 | Sundar | xinranwang: They are functional or tempest tests that do not rely on specialize d hardware | |
| 03:32:07 | Sundar | Yes, when Nova patches are submitted, they will automatically run tests that will simulate caling Cyborg to get device profiles and ARQs | |
| 03:32:43 | Sundar | The functional test fixture will return some values without actually calling Cyborg | |
| 03:33:07 | Sundar | You could think of it as mocking CYborg API | |
| 03:33:12 | xinranwang | Ok, so no more fake driver required in upstream CI, just simulate API layer and return right data? | |
| 03:33:19 | Sundar | Yes | |
| 03:33:27 | ikuo_o | Sundar: do you mean we should make upstream CI instead the CI by Xinran and Biwei? | |
| 03:33:53 | xinranwang | Sundar: got it, thanks | |
| 03:34:02 | Sundar | ikuo_o: Xinran/Biwei will work on real hardware i.e. 3rd party CI | |
| 03:34:12 | Biwei | that sounds like a different effort from the tempest plugin. Do we need both? Sundar | |
| 03:34:26 | xinranwang | I think we need both. ;) | |
| 03:34:34 | Biwei | Oh got ya | |
| 03:34:44 | Sundar | If we do a fake Cyborg driver, we will be doing tempest tests 2 ways, which seems redundant. | |
| 03:35:02 | ikuo_o | I see. | |
| 03:35:28 | Sundar | The downside is that the tempest CI will test only FPGAs, not GPUs or anything else | |
| 03:35:47 | Sundar | The common Cyborg code will not be exercised by 3rd party tempest CI, as planned now | |
| 03:36:08 | Sundar | Sorry -- badly phrased | |
| 03:36:26 | Sundar | The Cyborg code for GPUs and other devices will not be tested by 3rd party tempest CI | |
| 03:38:27 | ikuo_o | Does FPGA mean Intel FPGA? | |
| 03:38:42 | Sundar | Yes | |
| 03:38:59 | Sundar | Depending on your interest, we could push for a fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test) | |
| 03:39:07 | Sundar | No need for both IMHO | |
| 03:40:04 | Sundar | With tempest, bugs in Cyborg will break Nova tests. | |