Earlier  
Posted Nick Remark
#openstack-cyborg - 2019-06-05
03:01:34 wangzhh Hi ikuo_o
03:01:44 Sundar Let's wait a min for others to join
03:01:49 ikuo_o Hi wangzhh
03:03:04 Sundar #startmeeting openstack-cyborg
03:03:05 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:06 openstack Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:03:08 openstack The meeting name has been set to 'openstack_cyborg'
03:03:16 Sundar #topic Roll call
03:03:36 Sundar #info Sundar
03:04:24 Sundar wangzhh, ikuo_o, Biwei: o/
03:04:34 yikun #info yikun
03:04:41 wangzhh #info wangzhh
03:04:45 ikuo_o #info ikuo_o
03:04:47 Sundar Hi yikun
03:04:56 Biwei #info Biwei
03:04:58 yikun hey, Sundar
03:05:07 Sundar Agenda: https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda
03:05:13 Sundar ANything to add to that?
03:06:05 Sundar #topic Python cyborg client decision
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

Earlier   Later