| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2019-06-05 | |||
| 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. | |
| 03:40:16 | Sundar | But, of course, we will not have any bugs ;) | |
| 03:41:26 | ikuo_o | Thanks. should we choose the two option (fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test)) now? | |
| 03:41:41 | xinranwang | tempest test runs in real env, how to use fake driver with tempest | |
| 03:42:18 | Sundar | xinranwang: the fake driver will return driver OVOs and implement the same API calls as a regular driver | |
| 03:42:39 | Sundar | You mean you cannot put up a VM with a fake driver? | |
| 03:43:28 | xinranwang | yes, we cannot boot VM with accelerators with fake driver | |
| 03:44:08 | Sundar | ikuo_o: We have to implement _some_ tests for the Nova patches to merge. It looks like the 3rd party tempest may take sometime and it is not clear that Nova folks will accept that alone | |
| 03:44:57 | ikuo_o | I got it. | |
| 03:45:20 | Sundar | xinranwang: there may be some way to fake that success too? It has been suggested an an option by Nova folks too. E.g. Line 20 of https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg | |
| 03:46:51 | Sundar | Anyways, may be we can take this up in tomorrow's Zoom meeting, because we have only 15 minutes left for today | |
| 03:47:16 | xinranwang | Ok | |
| 03:47:20 | Sundar | #topic Cyborg specs | |
| 03:47:33 | Sundar | Device/driver discovery spec: https://review.opendev.org/#/c/593726 | |
| 03:48:03 | Sundar | We have already implemented it, though the spec is not merged. Do we need the spec? | |
| 03:48:53 | yikun | any different between specs and impletation? If not I think we didn't need it anymore | |
| 03:49:19 | ikuo_o | yikun +1 | |
| 03:49:29 | xinranwang | +1 | |
| 03:49:58 | Sundar | The spec was probably obsolete anyway :) So there may be differences. But that may not be relevant anyway. | |
| 03:50:46 | Sundar | Do the +1s mean 'we do not need it' or 'if no difference, we don't need it' ? | |
| 03:51:28 | ikuo_o | Thanks Sundar. Then the spec seems unnecessary | |
| 03:51:43 | ikuo_o | we do not need it +! | |
| 03:52:00 | Sundar | Good, thanks ikuo_o. I like that answer :) | |
| 03:52:21 | Sundar | I already abandoned it. I'll remove it from Nova spec as well | |
| 03:52:55 | Sundar | specs/index.rst: https://review.opendev.org/#/c/658498/ I think yikun already did that. SO, abandon this? | |
| 03:53:56 | yikun | https://review.opendev.org/#/c/651061/9/doc/source/index.rst@12 | |
| 03:53:58 | yikun | Yes | |
| 03:54:17 | yikun | I fixed it in the other merged patch. | |
| 03:54:25 | Sundar | Thanks, yikun. Done. | |
| 03:54:48 | Sundar | Please review these specs: https://review.opendev.org/#/c/602978/, https://review.opendev.org/#/c/605237/ | |
| 03:55:46 | yikun | OK, add to my review list | |
| 03:55:57 | Sundar | For device profiles, some more changes _may_ be needed in the future for 'nested magic'. See http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-04.log.html#t2019-06-04T13:17:48 | |
| 03:56:13 | Sundar | But we can always add a change spec | |
| 03:56:40 | Sundar | #topic Cyborg patches | |
| 03:57:00 | Sundar | Q: Why not use asserts? They are complementary to exceptions, IMHO | |
| 03:57:37 | Sundar | Like I said in the code reviews, other projects use them. And they are useful to check internal program logic. E.g. a function must return a list | |
| 03:58:11 | Sundar | If we make exceptions for everything, there will be too many exceptions or, worse, developers will not put the check | |
| 03:58:52 | Sundar | yikun said they produce unclear messages | |
| 03:59:20 | Sundar | But we can say: assert x == y: "Bad state for x, differ s from y" | |
| 03:59:53 | ikuo_o | "They" means exceptions? | |
| 04:00:01 | yikun | Both the ways of the assert or exception is okay to me, :) But I prefer to use the exception. | |
| 04:00:26 | Sundar | ikuo_o: "they" mean asserts | |
| 04:01:14 | Sundar | yikun: OK. For e.g., would you put an exception to check that a function returns a list? | |