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> I see. I thought the plugin option is difficult for OSC side, but maybe my misunderstanding
03:15:17 <ikuo_o> If it is realized in other works, plugin is better I think.
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 <yikun> https://github.com/openstack/osc-placement
03:17:52 <wangzhh> Cool, Thx Sundar, yikun.
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.
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?
04:03:07 <Sundar> Anyways, this is food for thought :)
04:03:37 <yikun> OK, I think assert and exception has their use case. :) so, I said, both okay to me
04:03:44 <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:54 <Sundar> yikun, ok. Thanks ;)
04:04:02 <ikuo_o> Sure.
04:04:11 <Sundar> #topic AoB
04:04:17 <Sundar> There is a Zoom meeting tomorrow
04:04:36 <Sundar> Mostly to wrap up the spec and patch reviews as much as possible
04:04:45 <ikuo_o> Ok, I will see you tomorrow.
04:05:01 <Sundar> ikuo_o and all, see you all tomorrow :)
04:05:08 <yikun> ok will join it, and thereare some patches need you guys eyes:
04:05:15 <yikun> https://review.opendev.org/#/c/658987
04:05:15 <yikun> ^ the generic driver spec have been approved, and the patch is ready for review.
04:05:15 <yikun> https://review.opendev.org/#/c/660874/
04:05:15 <yikun> ^ also the huawei ascend driver is also ready to merged
04:05:29 <Sundar> Great, will review
04:05:35 <yikun> any question, you can leave your comments, thanks. :)
04:05:37 <Sundar> Good day, everybody!
04:05:41 <Sundar> #endmeeting