Thursday, 2020-02-06

*** igordc has quit IRC00:08
*** TxGirlGeek has joined #openstack-cyborg00:16
*** TxGirlGe_ has quit IRC00:21
*** dustinc has quit IRC00:25
*** dustinc has joined #openstack-cyborg00:25
*** ildikov has quit IRC00:25
*** donnyd has quit IRC00:25
*** donnyd has joined #openstack-cyborg00:25
*** ildikov has joined #openstack-cyborg00:27
*** openstackstatus has quit IRC00:28
*** TxGirlGeek has quit IRC00:49
*** brinzhang has joined #openstack-cyborg00:56
*** brinzhang has quit IRC02:04
*** brinzhang has joined #openstack-cyborg02:05
*** brinzhang has quit IRC02:06
*** brinzhang has joined #openstack-cyborg02:07
*** s_shogo has joined #openstack-cyborg02:09
*** chenke has joined #openstack-cyborg02:17
*** Yumeng has joined #openstack-cyborg02:37
*** Sundar has joined #openstack-cyborg02:46
*** xinranwang has joined #openstack-cyborg02:59
SundarHello all03:00
Yumenghi Sundar03:00
s_shogoHi Sundar03:01
brinzhangHi Sundar03:01
SundarGood, we have many people already :)03:01
Yumenghi  11:01:0203:01
Sundar#startmeeting03:01
openstackSundar: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'03:01
chenkeHi03:01
Sundar#startmeeting openstack-cyborg03:01
openstackMeeting started Thu Feb  6 03:01:54 2020 UTC and is due to finish in 60 minutes.  The chair is Sundar. Information about MeetBot at http://wiki.debian.org/MeetBot.03:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.03:01
*** openstack changes topic to " (Meeting topic: openstack-cyborg)"03:01
openstackThe meeting name has been set to 'openstack_cyborg'03:01
Sundar#topic Roll call03:02
*** openstack changes topic to "Roll call (Meeting topic: openstack-cyborg)"03:02
Sundar#info Sundar03:02
chenke#info chenke03:02
s_shogo#info s_shogo03:02
Yumeng#info Yumeng03:02
brinzhang#info brinzhang03:02
Sundar#topic Agenda03:03
*** openstack changes topic to "Agenda (Meeting topic: openstack-cyborg)"03:03
xinranwangHi03:03
xinranwang#info xinranwang03:03
Yumenghi Xinran03:03
*** zhurong has joined #openstack-cyborg03:04
Li_Liu#info Li_Liu03:04
Li_LiuHi guys03:05
SundarFirst, I'd like to start by saying that Cyborg has been a long journey for me, in my current role at Intel. I have been spending anywhere from 50-100% of my time on it, with the rest going to some Kubernetes efforts for FPGA.03:05
SundarBut my role is changing, and it seems unlikely that I can stay engaged with Cyborg to the same extent. :(  It is a big disappointment for me.03:06
Li_LiuThanks a lot for all the great efforts Sundar03:06
SundarWelcome, Li_Liu.03:07
SundarHowever, I am trying hard to close the Nova integration as quickly as I can. For the rest, I think we have a good blueprint for further development.03:07
*** shaohe_feng73 has joined #openstack-cyborg03:07
brinzhangI think this is a big loss for Cyborg and everyone.03:07
shaohe_feng73hi all03:07
xinranwangThanks for your great efforts Sundar03:07
shaohe_feng73sorry for late03:07
shaohe_feng73something wrong with my network03:07
s_shogoThanks a lot, Sundar03:08
chenkethat's too regretful,03:08
brinzhangWe should imporve the priority to colse the Nova integration as soon as possible03:10
SundarIt is great that we have so many smart and enthusiastic developers in Cyborg who have lots of interest in seeing it succeed. I am sure you will all carry this forward. To be sure, OpenStack in Asia is expected to grow fast, much faster than the rest of the world. So, adoption by those companies is reassuring.03:10
YumengThat's really depressing news for cyborg.  Thanks Sundar for all the progress you've made for cyborg.03:10
Sundarbrinzhang: Yes, I am pushing it almost every day. It is mostly small details now.03:10
SundarYumeng and all: Thanks for your kind words.03:11
brinzhangSundar: yea, I see03:11
Li_LiuWell, hope you can still come here on and off to chat with us :P03:11
zhurongSundar thanks for your leadership of Cyborg, you really did a great things for Cyborg03:11
SundarI am going to be around as much as I can. :)03:12
shaohe_feng73so what's your next work? still cloud related?03:12
SundarApart from the Nova integration, what else do you all see as the next thing I should do soon?03:12
brinzhangSundar: Aha, I would like to see you complete your instance ops spec https://review.opendev.org/#/c/605237/ :)03:14
Sundarbrinzhang: Ok :)  We had a discussion whether it really needs to be a spec, or should it be a doc.03:15
brinzhangit just a document, it won't take up much of your time03:15
SundarSure, I can do that03:15
YumengI think V2 API and client are also important03:16
Yumengshould be done asap03:16
SundarYumeng: Yes. But Shogo is driving the client well, and you are all involved in different v2 APIs. Is there anything for me to do there?03:16
Yumengops. sorry. that's Xinran and shogo's03:17
Sundarnp :)  Yes. I could probably review them. But, for the client, reviews from Monty etc. are more important, honestly.03:17
brinzhangYeah, the v2 API's SPEC has been merged, I think while the PoC code pushed, Sundar can review it while he is free03:18
Sundarbrinzhang: You mean microversion spec?03:18
brinzhangyea03:18
xinranwangYes, for Sundar, the most important is nova integration. The rest, we can take it over if needed.03:19
shaohe_feng73yes.03:19
shaohe_feng73agree.03:19
xinranwangI think brinzhang means the api updated spec.03:19
shaohe_feng73not sure Sundar will start his new job.03:19
SundarMicroversion spec is merged. I think https://review.opendev.org/608624 is obsolete. Anyway we actually got most of the code in. So I may abandon it.03:20
chenkeAgree with xinran's idea.03:20
Sundarxinranwang: In https://review.opendev.org/#/q/status:open+project:openstack/cyborg-specs, which one are you referring to?03:20
shaohe_feng73hope these community jobs will increase his burden03:20
shaohe_feng73will not03:21
brinzhangSundar: yes, you can ignore what I said, it's not true03:21
xinranwangI think brinzhang means this one https://review.opendev.org/#/c/696012/?03:21
Sundarshaohe_feng: I plan to hang around for some time, may be till the end of U release if possible, or a few weeks in the worst case. I don't feel comfortable dropping the ball abruptly.03:22
brinzhangxinranwang: right03:23
shaohe_feng73sundar: Thank you for your professionalism03:24
SundarNP. Good. If any of you have any further thoughts or concerns, you can ping me on WeChat or send me email.03:25
SundarFor the rest of today, we can probably go over the important patches?03:25
SundarYumeng: how do you feel about tehe policy refresh stuff?03:26
Yumengyes. I have mailny arq:create policy to discuss with you guys03:27
Yumengand another two quick questions on device and device_profile API policies.03:28
Yumengthis spec is almost done, Collen and Lance from keystone have reviwed it and gave us many suggestions.03:28
Yumengok. let's start.03:29
SundarIf arq:create is open for all users, anybody who creates an ARQ can also start a bind, which can program devices. That is a security issue. But, if we make it admin only, most users cannot launch a VM. That is the issue, right?03:29
Yumengyes. from my understanding, user from nova should be able to arq initial creation,not only admin.03:30
Yumengmaybe by two ways: either the user create itself with a specific project_id in the request context;03:31
shaohe_feng73green bitstream can be program by users, write?03:31
shaohe_feng73s/write/right?03:31
shaohe_feng73maybe not all03:31
shaohe_feng73such as smartnic, had better let admin or deployer to do program.03:32
Li_Liu"green bitstream" is an intel specific concept right?03:32
SundarTo me, it seems that we need two specific roles: accelerator_user and accelerator_programmer (need better name). Only users/tenants who have that role can do the resp. functions.03:33
shaohe_feng73yes, not sure what's name in other fpga?03:33
Sundarshaohe_feng, Li_Liu: yes, green bitstream is intel-specific. But 'custom user logic' is a generic term.03:33
Li_Liui see03:34
SundarA FPGA may be programmed as a whole chip. But, if it allows partial reconfiguration, we could have a shell (blue bits) and custom user logic (green bits). The blue/green terminology is old even within Intel.03:34
shaohe_feng73let's user shell and custom user logic term03:35
SundarEither way, to program the custom user logic in an FPGA, or the device configuration Huawei Ascend chip, etc., we need a specific role that is allowed to configure devices, i.e., 'accelerator_programmer'. Right?03:36
brinzhanghow about arq:create us system_admin and project_admin role?03:37
brinzhangs/us/use03:37
Sundarbrinzhang: then only admins can create VMs with accelerators.03:37
shaohe_feng73we should think about project_admin can do any case03:38
shaohe_feng73smartnic maybe not good for project_admin, only for system_admin03:39
brinzhangIn our customer scenario, ordinary users need to issue an application to use the VM. I think it is possible to use the admin role, and the project administrator issues the VM to the user (allowing batches).03:39
shaohe_feng73In a really cloud ENV,  the system_admin maybe do some plan for their cloud, and decide the device/acc usage03:41
brinzhangjust allow *_admin to create a VM03:41
shaohe_feng73that's not a right way.03:41
brinzhangshaohe_feng73: yes, mostly the project_admin is an executor03:42
shaohe_feng73but in different cloud EVN, cloud provider  define the policy.03:42
Sundarbrinzhang: So, for a user to create a VM with accelerators, they must file a request with the project admin. Not truly self-service.03:43
shaohe_feng73the policy can be changed.03:43
shaohe_feng73we should do more for it.03:43
Sundarshaohe_feng: Yes. We should have some recommendation for the operators. We could make it admin only by default, and ask the operators to create accelerator_admin role as needed. Or, Cyborg could create that role by default.03:44
brinzhangYeah, the policy can be change, we can only set default role of this03:44
shaohe_feng73yes.03:44
shaohe_feng73and we can import it later.03:44
shaohe_feng73such as:03:45
SundarWhat if Cyborg creates an accelerator_admin role by default and let the operator map it to specific users?03:45
shaohe_feng73such as the system_admin pre-configure03:45
SundarSure, that's a safe default.03:46
shaohe_feng73reserve some pr are not can be used for common users.03:46
shaohe_feng73we can think about it later.03:46
shaohe_feng73plan and write a new spec for it, maybe03:47
SundarI think it is good to exit this meeting with some decision. This could influence Yumeng's work on policy refresh.03:47
shaohe_feng73maybe it does not matter. Cloud provider may not use our default policy.03:48
SundarTo be specific, the proposal is: Cyborg should create accelerator_user and accelerator_admin roles by default, map them both to project_admin by default, and document that operators should update them as needed. Agree or disagree?03:49
shaohe_feng73OK, and improve it later.03:51
brinzhangSundar:agree, I think it makes sense, maybe we should give some warning in doc, if the default role was changed?03:51
shaohe_feng73let system admin do some pre-configure for accelerator_user and accelerator_admin03:51
shaohe_feng73NOTE it in the patch03:52
SundarYumeng, Li_Liu, s_shogo, xinranwang, chenke: ^ agree?03:52
Li_Liuseems fine to me03:53
s_shogoagree, that seems to be straightforward.03:53
xinranwangagree03:53
shaohe_feng73anyway, we can distinguish these 2 roles later03:54
chenkeagree.03:54
Yumenglooks fine for me .agree.03:54
SundarExcellent. That's a productive meeting. :)03:55
Sundar#topic AoB03:55
*** openstack changes topic to "AoB (Meeting topic: openstack-cyborg)"03:55
SundarSince we are in the last 5 minutes, anything else to bring up?03:55
Yumengsorry, Sundar. another  two quick questions.03:55
Yumengdevice_profile create and delete, role "admin" required,  right?03:56
Yumengpatch devices and deployables, role "admin" required, right?03:56
shaohe_feng73project_admin can have their own DP.03:56
brinzhangagree03:57
shaohe_feng73patch devices is similar with program.03:57
shaohe_feng73we should do more distinguish.03:57
brinzhangsystem_admin and project_admin? if the project_admin can do, the system_admin also can do.03:58
SundarAgreed to both questions03:58
xinranwangYumeng:  which one you mean when you say "admin", system_admin or project admin03:59
shaohe_feng73yes, limit project_admin.03:59
Sundarpatche devices: sys admin. patch deployables: accelerator_admin03:59
Sundardevic eprofiles create, delete: sys admin04:00
shaohe_feng73it is evil if one can do anything. :]04:00
xinranwangSundar:  I agree with you :)04:00
shaohe_feng73DP can be project admin.04:00
YumengSundar: agree.04:00
shaohe_feng73Did not agree with DP.04:01
Sundarshaohe_feng73: what is "DP"?04:01
shaohe_feng73device profiles04:01
SundarA device profile is similar to a flvaor. Only the system admin can create flavors, because it is often used for billing and accounting.04:02
shaohe_feng73for, in really cloud sys admin can not prediction application scenarios04:02
SundarA project admin represents a tenant, and so cannot create flavors that he or she likes04:02
SundarIf you look at AWS for instance, you will see pre-ceated VM templates, like M1, F1, etc. all with different amounts of GPUs or FPGAs. They bill the user based on that. The operator has to decide aht they support -- tenants (like project admins) cannot decide that04:04
shaohe_feng73so if no flavor or DP satisfy with him, what should do?04:04
SundarAsk the operator and agree to pay more ;)04:04
shaohe_feng73so the operator help to create a New one?04:04
shaohe_feng73that's OK.04:04
Sundaryes, as with flavors04:04
shaohe_feng73but in some private, the cloud provider can let tenant to create their own DP.04:05
shaohe_feng73anyway the policy can change by themselves.04:05
shaohe_feng73for private maybe no need bill04:06
SundarWell, I think a cloud admin can delegate roles to others. If they really want to.04:06
xinranwangYes, the policy we discussed here is more like general policy in openstack04:06
Sundarxinranwang: Exactly04:07
brinzhangcurrent role just we set in Cyborg by default.04:07
Sundarbrinzhang: what do you mean?04:07
brinzhangif the user want to change I think they already think twice04:08
shaohe_feng73general  == public cloud?04:08
brinzhangSundar: I mean you ponit these policy is the default policy.04:09
brinzhangpatche devices: sys admin. patch deployables: accelerator_admin devic eprofiles create, delete: sys admin04:09
SundarYes.04:09
xinranwangIf cloud provider want the add or change the policy, they can do by themselves. from this point of view, I agree with shaohe_feng73.04:09
SundarYes.04:10
SundarQuick question to all: don't ave to answer right now. Re. Cyborg in various openStack installers, my understanding is Red Hat is not widely used in China, so I need not push for RDO much. But containers like Kolla and LOCI are more important, right?04:11
SundarWe can pick this up next week.04:12
shaohe_feng73I guess Kolla.04:12
SundarAny other topic for today?04:12
brinzhangKolla04:12
brinzhangI think there is a patch for improve UT need to talk04:13
brinzhangthat impact some patches to merge04:13
Sundarbrinzhang: Got it. I'll add it to next week's agenda.04:13
brinzhangSundar: ok~!04:14
brinzhangSundar: You can record https://review.opendev.org/#/c/70280704:15
SundarMeanwhile, the patch that is blocking Nova series merging is https://review.opendev.org/698846. Let's see if we can expedite that and the patches it depends on. In particular, please give +2 to https://review.opendev.org/#/c/703253/ ! :)04:15
Sundarbrinzhang: Will do04:15
Li_Liusounds good, will do04:16
SundarThanks a lot, everybody. Have a good day! :)04:16
chenkeok04:16
Sundar#endmeeting04:16
*** openstack changes topic to "Pending patches (Meeting topic: openstack-cyborg)"04:16
chenkebye04:16
openstackMeeting ended Thu Feb  6 04:16:16 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)04:16
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.html04:16
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.txt04:16
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.log.html04:16
Li_Liuthanks a lot . bye04:16
Yumengbye04:18
s_shogobye04:19
*** s_shogo has quit IRC04:19
*** shaohe_feng73 has left #openstack-cyborg04:19
*** shaohe_feng73 has joined #openstack-cyborg04:19
*** tetsuro has joined #openstack-cyborg04:27
*** tetsuro has quit IRC04:34
*** tetsuro has joined #openstack-cyborg04:37
*** zhurong has quit IRC04:41
*** Sundar has quit IRC04:54
*** zhurong has joined #openstack-cyborg05:07
*** shaohe_feng73 has quit IRC05:28
*** sean-k-mooney has quit IRC05:53
*** sean-k-mooney has joined #openstack-cyborg05:55
*** brinzhang has quit IRC06:32
*** links has joined #openstack-cyborg06:32
*** brinzhang has joined #openstack-cyborg06:32
*** brinzhang has quit IRC06:35
*** brinzhang has joined #openstack-cyborg06:36
*** zhurong has quit IRC06:42
*** sean-k-mooney has quit IRC07:01
*** sean-k-mooney has joined #openstack-cyborg07:03
*** xinranwang has quit IRC08:06
*** brinzhang_ has joined #openstack-cyborg08:27
*** brinzhang_ has quit IRC08:28
*** brinzhang_ has joined #openstack-cyborg08:29
*** brinzhang has quit IRC08:31
*** brinzhang_ has quit IRC08:44
*** brinzhang has joined #openstack-cyborg08:46
*** brinzhang has quit IRC08:46
*** brinzhang has joined #openstack-cyborg09:19
*** davidsha has joined #openstack-cyborg10:06
*** gmann has quit IRC13:23
*** irclogbot_0 has quit IRC13:26
*** irclogbot_3 has joined #openstack-cyborg13:29
*** links has quit IRC13:32
*** TxGirlGeek has joined #openstack-cyborg16:23
*** TxGirlGeek has quit IRC16:27
*** TxGirlGeek has joined #openstack-cyborg17:03
*** davidsha has quit IRC17:42
*** chenke has quit IRC19:32
*** Yumeng has quit IRC19:32
*** openstackstatus has joined #openstack-cyborg19:56
*** ChanServ sets mode: +v openstackstatus19:56
*** efried has quit IRC20:47
*** efried has joined #openstack-cyborg20:48
*** irclogbot_3 has quit IRC20:53
*** irclogbot_2 has joined #openstack-cyborg20:53
*** brinzhang_ has joined #openstack-cyborg23:47
*** brinzhang has quit IRC23:51

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!