| *** Sundar has quit IRC | 01:30 | |
| *** Sundar has joined #openstack-cyborg | 01:56 | |
| *** Sundar has quit IRC | 02:03 | |
| *** Sundar has joined #openstack-cyborg | 02:58 | |
| *** Biwei has joined #openstack-cyborg | 02:59 | |
| Sundar | Hi Biwei | 03:00 |
|---|---|---|
| Biwei | Hi Sundar | 03:00 |
| *** wangzhh has joined #openstack-cyborg | 03:00 | |
| Sundar | Hi wangzhh | 03:01 |
| wangzhh | Hi Sundar. | 03:01 |
| ikuo_o | Hi Sundar | 03:01 |
| Sundar | Hi ikuo_o | 03:01 |
| wangzhh | Hi ikuo_o | 03:01 |
| Sundar | Let's wait a min for others to join | 03:01 |
| ikuo_o | Hi wangzhh | 03:01 |
| Sundar | #startmeeting openstack-cyborg | 03:03 |
| openstack | Meeting started Wed Jun 5 03:03:04 2019 UTC and is due to finish in 60 minutes. The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot. | 03:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 03:03 |
| *** openstack changes topic to " (Meeting topic: openstack-cyborg)" | 03:03 | |
| openstack | The meeting name has been set to 'openstack_cyborg' | 03:03 |
| Sundar | #topic Roll call | 03:03 |
| *** openstack changes topic to "Roll call (Meeting topic: openstack-cyborg)" | 03:03 | |
| Sundar | #info Sundar | 03:03 |
| Sundar | wangzhh, ikuo_o, Biwei: o/ | 03:04 |
| yikun | #info yikun | 03:04 |
| wangzhh | #info wangzhh | 03:04 |
| ikuo_o | #info ikuo_o | 03:04 |
| Sundar | Hi yikun | 03:04 |
| Biwei | #info Biwei | 03:04 |
| yikun | hey, Sundar | 03:04 |
| Sundar | Agenda: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda | 03:05 |
| Sundar | ANything to add to that? | 03:05 |
| *** xinranwang has joined #openstack-cyborg | 03:05 | |
| Sundar | #topic Python cyborg client decision | 03:06 |
| *** openstack changes topic to "Python cyborg client decision (Meeting topic: openstack-cyborg)" | 03:06 | |
| wangzhh | Coco said she has other bussiness. Will miss this meeting. | 03:06 |
| Sundar | Please see the thread starting from http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006543.html | 03:06 |
| Sundar | wangzhh, thanks for letting us know | 03:06 |
| 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:07 |
| 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 |
| xinranwang | Hi all | 03:08 |
| xinranwang | #info xinranwang | 03:09 |
| Sundar | Hi xinranwang | 03:09 |
| Sundar | Writing a plugin may not be that bad, given the previous examples | 03:09 |
| Sundar | What do you all think? | 03:09 |
| yikun | So, we have to choose one from these two option? | 03:09 |
| 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 |
| wangzhh | yikun, I think so. Do u have other suggestions? | 03:10 |
| xinranwang | I think writing our own plugin is better | 03:10 |
| ikuo_o | Thanks for summarizing. | 03:11 |
| xinranwang | More indenpendency | 03:11 |
| wangzhh | Yes, I also vote the first one. Agree with xinran. | 03:11 |
| ikuo_o | It is better to write plugin, but I heard the option is not prepared by OSC. | 03:12 |
| ikuo_o | Maybe my misunderstanding... | 03:12 |
| yikun | OK, just want to sure any other way to complete, and I also vote to the 1st | 03:12 |
| Sundar | ikuo_o: "option is not prepared by OSC" -- what do you mean? | 03:12 |
| Sundar | OSC folks are not recomending against plugin -- they gave us the options. | 03:13 |
| xinranwang | please also consider the case where cyborg can run as a standalone project | 03:13 |
| Sundar | xinranwang: Sure, both options should be compatible with standalone usage | 03:14 |
| ikuo_o | I see. I thought the plugin option is difficult for OSC side, but maybe my misunderstanding | 03:15 |
| ikuo_o | If it is realized in other works, plugin is better I think. | 03:15 |
| wangzhh | Sundar, do u have any example of these two options? Maybe two different projects with two options. | 03:15 |
| xinranwang | We do have the cyborgclient repo with some V1 APIs implemented, right? | 03:15 |
| Sundar | wangzhh: There are many examples of plugins: https://docs.openstack.org/python-openstackclient/pike/contributor/plugins.html | 03:16 |
| wangzhh | Thx. | 03:16 |
| Biwei | https://github.com/openstack/python-cyborgclient is that what you are talking about? Xinran | 03:16 |
| xinranwang | Biwei: Ah yes, thanks | 03:17 |
| Sundar | wangzhh: Some examples of commands integrated with OSC: https://github.com/openstack/python-openstackclient/tree/master/openstackclient | 03:17 |
| 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 |
| Sundar | Includes compute, identity, etc. | 03:17 |
| yikun | https://github.com/openstack/osc-placement | 03:17 |
| wangzhh | Cool, Thx Sundar, yikun. | 03:17 |
| Sundar | xinranwang: The cyborg client for v1 API is neither: it uses osc-like syntax but is not a plugin | 03:18 |
| yikun | Can we complete it by 1st way first, and we our client is stable, and we switch it to 2nd way? | 03:18 |
| Sundar | ikuo_o: IIUC, you are also voting for plugin? or are you still considering? | 03:18 |
| yikun | Can we complete it by 1st way first, and when our client is stable, and we switch it to 2nd way? | 03:18 |
| ikuo_o | Sundar: I vote plugin. | 03:19 |
| Sundar | yikun: What would motivate us to switch like that? | 03:19 |
| yikun | We need +2+a right at first, because we perhaps frequently at first version. | 03:20 |
| xinranwang | Is there any necessity to switch to 2nd way? | 03:20 |
| yikun | xinranwang: I think the only reason is sundar mentioned, the osc team want 2nd way. - -# | 03:20 |
| Sundar | OK. Shall we say it is unanimously agreed that we will go with the plugin option (at least for now)? | 03:21 |
| xinranwang | yikun: lol | 03:21 |
| ikuo_o | ok | 03:21 |
| xinranwang | Sundar: I am fine with 1st one | 03:21 |
| Biwei | yes, plugin sounds good | 03:21 |
| 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 |
| Sundar | Thanks, Biwei and all | 03:22 |
| yikun | +1， and I think the placement repo would be a good example for us, https://github.com/openstack/osc-placement | 03:22 |
| Sundar | #topic Cyborg API fixtures in Nova | 03:22 |
| *** openstack changes topic to "Cyborg API fixtures in Nova (Meeting topic: openstack-cyborg)" | 03:22 | |
| Sundar | Please see Line 409 in https://review.opendev.org/#/c/603955/13/specs/train/approved/nova-cyborg-interaction.rst,unified | 03:23 |
| yikun | #link https://review.opendev.org/#/c/603955/13/specs/train/approved/nova-cyborg-interaction.rst@409 | 03:23 |
| 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:23 |
| 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:24 |
| Sundar | But it seems we still need to an upstream CI, not 3rd party CI, which can be a Cyborg API fixture | 03:25 |
| Sundar | First, does anybody have any questions on that? | 03:25 |
| Biwei | what do you mean by upstream CI? | 03:26 |
| Biwei | and 3rd party CI | 03:26 |
| ikuo_o | I want to know those too. | 03:26 |
| 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 |
| Sundar | For example, Intel may set up a FPGA-based CI and integrate that with Zuul: that's 3rd party CI | 03:27 |
| Sundar | If we have a CI running in a VM with devstack, that would be upstream | 03:28 |
| Sundar | Good? | 03:28 |
| yikun | I guess the comments from matt was talking about is add cyborg api fixture in nova test code? | 03:29 |
| yikun | Like something, the placement done: https://github.com/openstack/nova/blob/master/nova/tests/functional/fixtures.py#L79-L90 | 03:29 |
| Sundar | yikun: Yes | 03:29 |
| 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:29 |
| Sundar | *breaks | 03:30 |
| 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 |
| Biwei | ok I see | 03:30 |
| xinranwang | I understand what 3rd parth CI do, but I am confused about what upstream CI do exactly | 03:30 |
| xinranwang | is it used for let nova call fake Cyborg API? | 03:31 |
| Sundar | xinranwang: They are functional or tempest tests that do not rely on specialize d hardware | 03:31 |
| 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 |
| Sundar | The functional test fixture will return some values without actually calling Cyborg | 03:32 |
| Sundar | You could think of it as mocking CYborg API | 03:33 |
| xinranwang | Ok, so no more fake driver required in upstream CI, just simulate API layer and return right data? | 03:33 |
| Sundar | Yes | 03:33 |
| ikuo_o | Sundar: do you mean we should make upstream CI instead the CI by Xinran and Biwei? | 03:33 |
| xinranwang | Sundar: got it, thanks | 03:33 |
| Sundar | ikuo_o: Xinran/Biwei will work on real hardware i.e. 3rd party CI | 03:34 |
| Biwei | that sounds like a different effort from the tempest plugin. Do we need both? Sundar | 03:34 |
| xinranwang | I think we need both. ;) | 03:34 |
| Biwei | Oh got ya | 03:34 |
| Sundar | If we do a fake Cyborg driver, we will be doing tempest tests 2 ways, which seems redundant. | 03:34 |
| ikuo_o | I see. | 03:35 |
| Sundar | The downside is that the tempest CI will test only FPGAs, not GPUs or anything else | 03:35 |
| Sundar | The common Cyborg code will not be exercised by 3rd party tempest CI, as planned now | 03:35 |
| Sundar | Sorry -- badly phrased | 03:36 |
| Sundar | The Cyborg code for GPUs and other devices will not be tested by 3rd party tempest CI | 03:36 |
| ikuo_o | Does FPGA mean Intel FPGA? | 03:38 |
| Sundar | Yes | 03:38 |
| Sundar | Depending on your interest, we could push for a fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test) | 03:38 |
| Sundar | No need for both IMHO | 03:39 |
| Sundar | With tempest, bugs in Cyborg will break Nova tests. | 03:40 |
| Sundar | But, of course, we will not have any bugs ;) | 03:40 |
| ikuo_o | Thanks. should we choose the two option (fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test)) now? | 03:41 |
| xinranwang | tempest test runs in real env, how to use fake driver with tempest | 03:41 |
| Sundar | xinranwang: the fake driver will return driver OVOs and implement the same API calls as a regular driver | 03:42 |
| Sundar | You mean you cannot put up a VM with a fake driver? | 03:42 |
| xinranwang | yes, we cannot boot VM with accelerators with fake driver | 03:43 |
| 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 |
| ikuo_o | I got it. | 03:44 |
| 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:45 |
| Sundar | Anyways, may be we can take this up in tomorrow's Zoom meeting, because we have only 15 minutes left for today | 03:46 |
| xinranwang | Ok | 03:47 |
| Sundar | #topic Cyborg specs | 03:47 |
| *** openstack changes topic to "Cyborg specs (Meeting topic: openstack-cyborg)" | 03:47 | |
| Sundar | Device/driver discovery spec: https://review.opendev.org/#/c/593726 | 03:47 |
| Sundar | We have already implemented it, though the spec is not merged. Do we need the spec? | 03:48 |
| yikun | any different between specs and impletation? If not I think we didn't need it anymore | 03:48 |
| ikuo_o | yikun +1 | 03:49 |
| xinranwang | +1 | 03:49 |
| Sundar | The spec was probably obsolete anyway :) So there may be differences. But that may not be relevant anyway. | 03:49 |
| Sundar | Do the +1s mean 'we do not need it' or 'if no difference, we don't need it' ? | 03:50 |
| ikuo_o | Thanks Sundar. Then the spec seems unnecessary | 03:51 |
| ikuo_o | we do not need it +! | 03:51 |
| Sundar | Good, thanks ikuo_o. I like that answer :) | 03:52 |
| Sundar | I already abandoned it. I'll remove it from Nova spec as well | 03:52 |
| Sundar | specs/index.rst: https://review.opendev.org/#/c/658498/ I think yikun already did that. SO, abandon this? | 03:52 |
| yikun | https://review.opendev.org/#/c/651061/9/doc/source/index.rst@12 | 03:53 |
| yikun | Yes | 03:53 |
| yikun | I fixed it in the other merged patch. | 03:54 |
| Sundar | Thanks, yikun. Done. | 03:54 |
| Sundar | Please review these specs: https://review.opendev.org/#/c/602978/, https://review.opendev.org/#/c/605237/ | 03:54 |
| yikun | OK, add to my review list | 03:55 |
| 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:55 |
| Sundar | But we can always add a change spec | 03:56 |
| Sundar | #topic Cyborg patches | 03:56 |
| *** openstack changes topic to "Cyborg patches (Meeting topic: openstack-cyborg)" | 03:56 | |
| Sundar | Q: Why not use asserts? They are complementary to exceptions, IMHO | 03:57 |
| 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:57 |
| Sundar | If we make exceptions for everything, there will be too many exceptions or, worse, developers will not put the check | 03:58 |
| Sundar | yikun said they produce unclear messages | 03:58 |
| Sundar | But we can say: assert x == y: "Bad state for x, differ s from y" | 03:59 |
| ikuo_o | "They" means exceptions? | 03:59 |
| yikun | Both the ways of the assert or exception is okay to me, :) But I prefer to use the exception. | 04:00 |
| Sundar | ikuo_o: "they" mean asserts | 04:00 |
| Sundar | yikun: OK. For e.g., would you put an exception to check that a function returns a list? | 04:01 |
| Sundar | Anyways, this is food for thought :) | 04:03 |
| yikun | OK, I think assert and exception has their use case. :) so, I said, both okay to me | 04:03 |
| Sundar | If you are all ok, I'll leave the asserts in the code. IMHO, it is a good practice, recommended in software engineering books | 04:03 |
| Sundar | yikun, ok. Thanks ;) | 04:03 |
| ikuo_o | Sure. | 04:04 |
| Sundar | #topic AoB | 04:04 |
| *** openstack changes topic to "AoB (Meeting topic: openstack-cyborg)" | 04:04 | |
| Sundar | There is a Zoom meeting tomorrow | 04:04 |
| Sundar | Mostly to wrap up the spec and patch reviews as much as possible | 04:04 |
| ikuo_o | Ok, I will see you tomorrow. | 04:04 |
| Sundar | ikuo_o and all, see you all tomorrow :) | 04:05 |
| yikun | ok will join it, and thereare some patches need you guys eyes: | 04:05 |
| yikun | https://review.opendev.org/#/c/658987 | 04:05 |
| yikun | ^ the generic driver spec have been approved, and the patch is ready for review. | 04:05 |
| yikun | https://review.opendev.org/#/c/660874/ | 04:05 |
| yikun | ^ also the huawei ascend driver is also ready to merged | 04:05 |
| Sundar | Great, will review | 04:05 |
| yikun | any question, you can leave your comments, thanks. :) | 04:05 |
| Sundar | Good day, everybody! | 04:05 |
| Sundar | #endmeeting | 04:05 |
| ikuo_o | Bye. | 04:05 |
| *** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)" | 04:05 | |
| openstack | Meeting ended Wed Jun 5 04:05:41 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 04:05 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-06-05-03.03.html | 04:05 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-06-05-03.03.txt | 04:05 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2019/openstack_cyborg.2019-06-05-03.03.log.html | 04:05 |
| Biwei | Bye | 04:05 |
| *** Biwei has quit IRC | 04:06 | |
| *** Sundar has quit IRC | 04:13 | |
| *** links has joined #openstack-cyborg | 04:26 | |
| *** ikuo_o has quit IRC | 06:28 | |
| *** helenafm has joined #openstack-cyborg | 07:42 | |
| *** openstackgerrit has quit IRC | 08:47 | |
| *** jaypipes has joined #openstack-cyborg | 12:28 | |
| *** links has quit IRC | 14:45 | |
| *** helenafm has quit IRC | 15:39 | |
| *** Sundar has joined #openstack-cyborg | 15:54 | |
| edleafe | Sundar: I saw this comment: https://leafe.com/timeline/%23openstack-cyborg/2019-06-05T03:36:26 | 16:02 |
| edleafe | Sundar: and wanted to let you know that there may be interest at IBM in also hosting a 3rd party CI for accelerators on Power hardware | 16:03 |
| edleafe | Nothing definite yet, but they generally want to keep up with x86 testing | 16:03 |
| Sundar | edleafe: GTK. Thanks. Please let us know what accelerators you plan to include | 16:07 |
| edleafe | Sundar: will do | 16:07 |
| *** Sundar has quit IRC | 18:21 | |
| Li_Liu | Sundar, I am still fighting the jetlag... will try my best for the zoom meeting night | 21:00 |
| *** Sundar has joined #openstack-cyborg | 21:21 | |
| *** Sundar has quit IRC | 21:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!