Wednesday, 2019-06-05

*** Sundar has quit IRC01:30
*** Sundar has joined #openstack-cyborg01:56
*** Sundar has quit IRC02:03
*** Sundar has joined #openstack-cyborg02:58
*** Biwei has joined #openstack-cyborg02:59
SundarHi Biwei03:00
BiweiHi Sundar03:00
*** wangzhh has joined #openstack-cyborg03:00
SundarHi wangzhh03:01
wangzhhHi Sundar.03:01
ikuo_oHi Sundar03:01
SundarHi ikuo_o03:01
wangzhhHi ikuo_o03:01
SundarLet's wait a min for others to join03:01
ikuo_oHi wangzhh03:01
Sundar#startmeeting openstack-cyborg03:03
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.03:03
*** openstack changes topic to " (Meeting topic: openstack-cyborg)"03:03
openstackThe meeting name has been set to 'openstack_cyborg'03:03
Sundar#topic Roll call03:03
*** openstack changes topic to "Roll call (Meeting topic: openstack-cyborg)"03:03
Sundar#info Sundar03:03
Sundarwangzhh, ikuo_o, Biwei: o/03:04
yikun#info yikun03:04
wangzhh#info wangzhh03:04
ikuo_o#info ikuo_o03:04
SundarHi yikun03:04
Biwei#info Biwei03:04
yikunhey, Sundar03:04
SundarANything to add to that?03:05
*** xinranwang has joined #openstack-cyborg03:05
Sundar#topic Python cyborg client decision03:06
*** openstack changes topic to "Python cyborg client decision (Meeting topic: openstack-cyborg)"03:06
wangzhhCoco said she has other bussiness. Will miss this meeting.03:06
SundarPlease see the thread starting from
Sundarwangzhh, thanks for letting us know03:06
SundarFor 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
SundarFor 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 opinions03:08
xinranwangHi all03:08
xinranwang#info xinranwang03:09
SundarHi xinranwang03:09
SundarWriting a plugin may not be that bad, given the previous examples03:09
SundarWhat do you all think?03:09
yikunSo, we have to choose one from these two option?03:09
Sundaryikun, 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 recommended03:10
wangzhhyikun, I think so. Do u have other suggestions?03:10
xinranwangI think writing our own plugin is better03:10
ikuo_oThanks for summarizing.03:11
xinranwangMore indenpendency03:11
wangzhhYes, I also vote the first one. Agree with xinran.03:11
ikuo_oIt is better to write plugin, but I heard the option is not prepared by OSC.03:12
ikuo_oMaybe my misunderstanding...03:12
yikunOK, just want to sure any other way to complete, and I also vote to the 1st03:12
Sundarikuo_o: "option is not prepared by OSC" -- what do you mean?03:12
SundarOSC folks are not recomending against plugin -- they gave us the options.03:13
xinranwangplease also consider the case where cyborg can run as a standalone project03:13
Sundarxinranwang: Sure, both options should be compatible with standalone usage03:14
ikuo_oI see. I thought the plugin option is difficult for OSC side, but maybe my misunderstanding03:15
ikuo_oIf it is realized in other works, plugin is better I think.03:15
wangzhhSundar, do u have any example of these two options? Maybe two different projects with two options.03:15
xinranwangWe do have the cyborgclient repo with some V1 APIs implemented, right?03:15
Sundarwangzhh: There are many examples of plugins:
Biwei is that what you are talking about? Xinran03:16
xinranwangBiwei:  Ah yes, thanks03:17
Sundarwangzhh: Some examples of commands integrated with OSC:
yikunwangzhh: I think the nova is 2nd(, and placement is 1st example03:17
SundarIncludes compute, identity, etc.03:17
wangzhhCool, Thx Sundar, yikun.03:17
Sundarxinranwang: The cyborg client for v1 API is neither: it uses osc-like syntax but is not a plugin03:18
yikunCan we complete it by 1st way first, and we our client is stable, and we switch it to 2nd way?03:18
Sundarikuo_o: IIUC, you are also voting for plugin? or are you still considering?03:18
yikunCan we complete it by 1st way first, and when our client is stable, and we switch it to 2nd way?03:18
ikuo_oSundar: I vote plugin.03:19
Sundaryikun: What would motivate us to switch like that?03:19
yikunWe need +2+a right at first, because we perhaps frequently at first version.03:20
xinranwangIs there  any necessity to switch to 2nd way?03:20
yikunxinranwang: I think the only reason is sundar mentioned, the osc team want 2nd way. - -#03:20
SundarOK. Shall we say it is unanimously agreed that we will go with the plugin option (at least for now)?03:21
xinranwangyikun:  lol03:21
xinranwangSundar:  I am fine with 1st one03:21
Biweiyes, plugin sounds good03: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
SundarThanks, Biwei and all03:22
yikun+1, and I think the placement repo would be a good example for us,
Sundar#topic Cyborg API fixtures in Nova03:22
*** openstack changes topic to "Cyborg API fixtures in Nova (Meeting topic: openstack-cyborg)"03:22
SundarPlease see Line 409 in,unified03:23
SundarMany 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 before03:23
SundarIIUC, it is enough to do tempest CI with real hardware (no fake driver needed). That is already driven by Xinran and Biwei03:24
SundarBut it seems we still need to an upstream CI, not 3rd party CI, which can be a Cyborg API fixture03:25
SundarFirst, does anybody have any questions on that?03:25
Biweiwhat do you mean by upstream CI?03:26
Biweiand 3rd party CI03:26
ikuo_oI want to know those too.03:26
Sundar3rd 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 company03:27
SundarFor example, Intel may set up a FPGA-based CI and integrate that with Zuul: that's 3rd party CI03:27
SundarIf we have a CI running in a VM with devstack, that would be upstream03:28
yikunI guess the comments from matt was talking about is add cyborg api fixture in nova test code?03:29
yikunLike something, the placement done:
Sundaryikun: Yes03:29
SundarI think Nova developers are coming from the historical experience that 3rd party hardware/CI sometimes beaks, and may take time to fix.03:29
SundarA non-hardware-dependent CI is easier to maintain by the community and more reliable, even if it is not an end-to-end test03:30
Biweiok I see03:30
xinranwangI understand what 3rd parth CI do, but I am confused about what upstream CI do exactly03:30
xinranwangis it used for let nova call fake Cyborg API?03:31
Sundarxinranwang: They are functional or tempest tests that do not rely on specialize d hardware03:31
SundarYes, when Nova patches are submitted, they will automatically run tests that will simulate caling Cyborg to get device profiles and ARQs03:32
SundarThe functional test fixture will return some values without actually calling Cyborg03:32
SundarYou could think of it as mocking CYborg API03:33
xinranwangOk, so no more fake driver required in upstream CI, just simulate API layer and return right data?03:33
ikuo_oSundar: do you mean we should make upstream CI instead the CI by Xinran and Biwei?03:33
xinranwangSundar:  got it, thanks03:33
Sundarikuo_o: Xinran/Biwei will work on real hardware i.e. 3rd party CI03:34
Biweithat sounds like a different effort from the tempest plugin. Do we need both? Sundar03:34
xinranwangI think we need both.  ;)03:34
BiweiOh got ya03:34
SundarIf we do a fake Cyborg driver, we will be doing tempest tests 2 ways, which seems redundant.03:34
ikuo_oI see.03:35
SundarThe downside is that the tempest CI will test only FPGAs, not GPUs or anything else03:35
SundarThe common Cyborg code will not be exercised by 3rd party tempest CI, as planned now03:35
SundarSorry -- badly phrased03:36
SundarThe Cyborg code for GPUs and other devices will not be tested by 3rd party tempest CI03:36
ikuo_oDoes FPGA mean Intel FPGA?03:38
SundarDepending on your interest, we could push for a fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test)03:38
SundarNo need for both IMHO03:39
SundarWith tempest, bugs in Cyborg will break Nova tests.03:40
SundarBut, of course, we will not have any bugs ;)03:40
ikuo_oThanks. should we choose the two option (fake GPU/generic driver (with tempest) OR fake Cyborg API (functional test)) now?03:41
xinranwangtempest test runs in real env, how to use fake driver with tempest03:41
Sundarxinranwang: the fake driver will return driver OVOs and implement the same API calls as a regular driver03:42
SundarYou mean you cannot put up a VM with a fake driver?03:42
xinranwangyes, we cannot boot VM with accelerators with fake driver03:43
Sundarikuo_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 alone03:44
ikuo_oI got it.03:44
Sundarxinranwang: 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
SundarAnyways, may be we can take this up in tomorrow's Zoom meeting, because we have only 15 minutes left for today03:46
Sundar#topic Cyborg specs03:47
*** openstack changes topic to "Cyborg specs (Meeting topic: openstack-cyborg)"03:47
SundarDevice/driver discovery spec:
SundarWe have already implemented it, though the spec is not merged. Do we need the spec?03:48
yikunany different between specs and impletation? If not I think we didn't need it anymore03:48
ikuo_oyikun +103:49
SundarThe spec was probably obsolete anyway :) So there may be differences. But that may not be relevant anyway.03:49
SundarDo the +1s mean 'we do not need it' or 'if no difference, we don't need it' ?03:50
ikuo_oThanks Sundar. Then the spec seems unnecessary03:51
ikuo_owe do not need it +!03:51
SundarGood, thanks ikuo_o. I like that answer :)03:52
SundarI already abandoned it. I'll remove it from Nova spec as well03:52
Sundarspecs/index.rst: I think yikun already did that. SO, abandon this?03:52
yikunI fixed it in the other merged patch.03:54
SundarThanks, yikun. Done.03:54
SundarPlease review these specs:,
yikunOK, add to my review list03:55
SundarFor device profiles, some more changes _may_ be needed in the future for 'nested magic'. See
SundarBut we can always add a change spec03:56
Sundar#topic Cyborg patches03:56
*** openstack changes topic to "Cyborg patches (Meeting topic: openstack-cyborg)"03:56
SundarQ: Why not use asserts? They are complementary to exceptions, IMHO03:57
SundarLike 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 list03:57
SundarIf we make exceptions for everything, there will be too many exceptions or, worse, developers will not put the check03:58
Sundaryikun said they produce unclear messages03:58
SundarBut we can say: assert x == y: "Bad state for x, differ s from y"03:59
ikuo_o"They" means exceptions?03:59
yikunBoth the ways of the assert or exception is okay to me, :) But I prefer to use the exception.04:00
Sundarikuo_o: "they" mean asserts04:00
Sundaryikun: OK. For e.g., would you put an exception to check that a function returns a list?04:01
SundarAnyways, this is food for thought :)04:03
yikunOK, I think assert and exception has their use case. :) so, I said, both okay to me04:03
SundarIf you are all ok, I'll leave the asserts in the code. IMHO, it is a good practice, recommended in software engineering books04:03
Sundaryikun, ok. Thanks ;)04:03
Sundar#topic AoB04:04
*** openstack changes topic to "AoB (Meeting topic: openstack-cyborg)"04:04
SundarThere is a Zoom meeting tomorrow04:04
SundarMostly to wrap up the spec and patch reviews as much as possible04:04
ikuo_oOk, I will see you tomorrow.04:04
Sundarikuo_o and all, see you all tomorrow :)04:05
yikunok will join it, and thereare some patches need you guys eyes:04:05
yikun^ the generic driver spec have been approved, and the patch is ready for review.04:05
yikun^ also the huawei ascend driver is also ready to merged04:05
SundarGreat, will review04:05
yikunany question, you can leave your comments, thanks. :)04:05
SundarGood day, everybody!04:05
*** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)"04:05
openstackMeeting ended Wed Jun  5 04:05:41 2019 UTC.  Information about MeetBot at . (v 0.1.4)04:05
openstackMinutes (text):
*** Biwei has quit IRC04:06
*** Sundar has quit IRC04:13
*** links has joined #openstack-cyborg04:26
*** ikuo_o has quit IRC06:28
*** helenafm has joined #openstack-cyborg07:42
*** openstackgerrit has quit IRC08:47
*** jaypipes has joined #openstack-cyborg12:28
*** links has quit IRC14:45
*** helenafm has quit IRC15:39
*** Sundar has joined #openstack-cyborg15:54
edleafeSundar: I saw this comment:
edleafeSundar: and wanted to let you know that there may be interest at IBM in also hosting a 3rd party CI for accelerators on Power hardware16:03
edleafeNothing definite yet, but they generally want to keep up with x86 testing16:03
Sundaredleafe: GTK. Thanks. Please let us know what accelerators you plan to include16:07
edleafeSundar: will do16:07
*** Sundar has quit IRC18:21
Li_LiuSundar, I am still fighting the jetlag... will try my best for the zoom meeting night21:00
*** Sundar has joined #openstack-cyborg21:21
*** Sundar has quit IRC21:52

Generated by 2.15.3 by Marius Gedminas - find it at!