03:01:54 <Sundar> #startmeeting openstack-cyborg
03:01:55 <openstack> Meeting 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:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:01:58 <openstack> The meeting name has been set to 'openstack_cyborg'
03:02:25 <Sundar> #topic Roll call
03:02:31 <Sundar> #info Sundar
03:02:43 <chenke> #info chenke
03:02:44 <s_shogo> #info s_shogo
03:02:50 <Yumeng> #info Yumeng
03:02:52 <brinzhang> #info brinzhang
03:03:11 <Sundar> #topic Agenda
03:03:44 <xinranwang> Hi
03:03:44 <xinranwang> #info xinranwang
03:03:57 <Yumeng> hi Xinran
03:04:37 <Li_Liu> #info Li_Liu
03:05:27 <Li_Liu> Hi guys
03:05:38 <Sundar> First, 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:06:08 <Sundar> But 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:47 <Li_Liu> Thanks a lot for all the great efforts Sundar
03:07:10 <Sundar> Welcome, Li_Liu.
03:07:14 <Sundar> However, 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:24 <brinzhang> I think this is a big loss for Cyborg and everyone.
03:07:35 <shaohe_feng73> hi all
03:07:47 <xinranwang> Thanks for your great efforts Sundar
03:07:47 <shaohe_feng73> sorry for late
03:07:58 <shaohe_feng73> something wrong with my network
03:08:39 <s_shogo> Thanks a lot, Sundar
03:08:56 <chenke> that's too regretful,
03:10:15 <brinzhang> We should imporve the priority to colse the Nova integration as soon as possible
03:10:16 <Sundar> It 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:38 <Yumeng> That's really depressing news for cyborg.  Thanks Sundar for all the progress you've made for cyborg.
03:10:56 <Sundar> brinzhang: Yes, I am pushing it almost every day. It is mostly small details now.
03:11:09 <Sundar> Yumeng and all: Thanks for your kind words.
03:11:21 <brinzhang> Sundar: yea, I see
03:11:23 <Li_Liu> Well, hope you can still come here on and off to chat with us :P
03:11:37 <zhurong> Sundar thanks for your leadership of Cyborg, you really did a great things for Cyborg
03:12:08 <Sundar> I am going to be around as much as I can. :)
03:12:32 <shaohe_feng73> so what's your next work? still cloud related?
03:12:48 <Sundar> Apart from the Nova integration, what else do you all see as the next thing I should do soon?
03:14:15 <brinzhang> Sundar: Aha, I would like to see you complete your instance ops spec https://review.opendev.org/#/c/605237/ :)
03:15:08 <Sundar> brinzhang: Ok :)  We had a discussion whether it really needs to be a spec, or should it be a doc.
03:15:36 <brinzhang> it just a document, it won't take up much of your time
03:15:44 <Sundar> Sure, I can do that
03:16:01 <Yumeng> I think V2 API and client are also important
03:16:20 <Yumeng> should be done asap
03:16:54 <Sundar> Yumeng: 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:17:03 <Yumeng> ops. sorry. that's Xinran and shogo's
03:17:47 <Sundar> np :)  Yes. I could probably review them. But, for the client, reviews from Monty etc. are more important, honestly.
03:18:08 <brinzhang> Yeah, the v2 API's SPEC has been merged, I think while the PoC code pushed, Sundar can review it while he is free
03:18:35 <Sundar> brinzhang: You mean microversion spec?
03:18:48 <brinzhang> yea
03:19:00 <xinranwang> Yes, for Sundar, the most important is nova integration. The rest, we can take it over if needed.
03:19:12 <shaohe_feng73> yes.
03:19:16 <shaohe_feng73> agree.
03:19:40 <xinranwang> I think brinzhang means the api updated spec.
03:19:53 <shaohe_feng73> not sure Sundar will start his new job.
03:20:12 <Sundar> Microversion 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:28 <chenke> Agree with xinran's idea.
03:20:49 <Sundar> xinranwang: In https://review.opendev.org/#/q/status:open+project:openstack/cyborg-specs, which one are you referring to?
03:20:57 <shaohe_feng73> hope these community jobs will increase his burden
03:21:17 <shaohe_feng73> will not
03:21:41 <brinzhang> Sundar: yes, you can ignore what I said, it's not true
03:21:59 <xinranwang> I think brinzhang means this one https://review.opendev.org/#/c/696012/?
03:22:39 <Sundar> shaohe_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:23:06 <brinzhang> xinranwang: right
03:24:46 <shaohe_feng73> sundar: Thank you for your professionalism
03:25:07 <Sundar> NP. Good. If any of you have any further thoughts or concerns, you can ping me on WeChat or send me email.
03:25:38 <Sundar> For the rest of today, we can probably go over the important patches?
03:26:28 <Sundar> Yumeng: how do you feel about tehe policy refresh stuff?
03:27:06 <Yumeng> yes. I have mailny arq:create policy to discuss with you guys
03:28:03 <Yumeng> and another two quick questions on device and device_profile API policies.
03:28:43 <Yumeng> this spec is almost done, Collen and Lance from keystone have reviwed it and gave us many suggestions.
03:29:21 <Yumeng> ok. let's start.
03:29:34 <Sundar> If 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:30:56 <Yumeng> yes. from my understanding, user from nova should be able to arq initial creation,not only admin.
03:31:14 <Yumeng> maybe by two ways: either the user create itself with a specific project_id in the request context;
03:31:29 <shaohe_feng73> green bitstream can be program by users, write?
03:31:54 <shaohe_feng73> s/write/right?
03:31:57 <shaohe_feng73> maybe not all
03:32:27 <shaohe_feng73> such as smartnic, had better let admin or deployer to do program.
03:32:37 <Li_Liu> "green bitstream" is an intel specific concept right?
03:33:25 <Sundar> To 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:39 <shaohe_feng73> yes, not sure what's name in other fpga?
03:33:52 <Sundar> shaohe_feng, Li_Liu: yes, green bitstream is intel-specific. But 'custom user logic' is a generic term.
03:34:05 <Li_Liu> i see
03:34:53 <Sundar> A 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:35:43 <shaohe_feng73> let's user shell and custom user logic term
03:36:13 <Sundar> Either 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:37:11 <brinzhang> how about arq:create us system_admin and project_admin role?
03:37:22 <brinzhang> s/us/use
03:37:52 <Sundar> brinzhang: then only admins can create VMs with accelerators.
03:38:37 <shaohe_feng73> we should think about project_admin can do any case
03:39:09 <shaohe_feng73> smartnic maybe not good for project_admin, only for system_admin
03:39:30 <brinzhang> In 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:41:09 <shaohe_feng73> In a really cloud ENV,  the system_admin maybe do some plan for their cloud, and decide the device/acc usage
03:41:19 <brinzhang> just allow *_admin to create a VM
03:41:59 <shaohe_feng73> that's not a right way.
03:42:15 <brinzhang> shaohe_feng73: yes, mostly the project_admin is an executor
03:42:44 <shaohe_feng73> but in different cloud EVN, cloud provider  define the policy.
03:43:05 <Sundar> brinzhang: 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:07 <shaohe_feng73> the policy can be changed.
03:43:52 <shaohe_feng73> we should do more for it.
03:44:10 <Sundar> shaohe_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:14 <brinzhang> Yeah, the policy can be change, we can only set default role of this
03:44:49 <shaohe_feng73> yes.
03:44:59 <shaohe_feng73> and we can import it later.
03:45:01 <shaohe_feng73> such as:
03:45:07 <Sundar> What if Cyborg creates an accelerator_admin role by default and let the operator map it to specific users?
03:45:57 <shaohe_feng73> such as the system_admin pre-configure
03:46:16 <Sundar> Sure, that's a safe default.
03:46:33 <shaohe_feng73> reserve some pr are not can be used for common users.
03:46:56 <shaohe_feng73> we can think about it later.
03:47:20 <shaohe_feng73> plan and write a new spec for it, maybe
03:47:28 <Sundar> I think it is good to exit this meeting with some decision. This could influence Yumeng's work on policy refresh.
03:48:37 <shaohe_feng73> maybe it does not matter. Cloud provider may not use our default policy.
03:49:43 <Sundar> To 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:51:15 <shaohe_feng73> OK, and improve it later.
03:51:46 <brinzhang> Sundar:agree, I think it makes sense, maybe we should give some warning in doc, if the default role was changed?
03:51:54 <shaohe_feng73> let system admin do some pre-configure for accelerator_user and accelerator_admin
03:52:29 <shaohe_feng73> NOTE it in the patch
03:52:46 <Sundar> Yumeng, Li_Liu, s_shogo, xinranwang, chenke: ^ agree?
03:53:17 <Li_Liu> seems fine to me
03:53:43 <s_shogo> agree, that seems to be straightforward.
03:53:59 <xinranwang> agree
03:54:01 <shaohe_feng73> anyway, we can distinguish these 2 roles later
03:54:16 <chenke> agree.
03:54:31 <Yumeng> looks fine for me .agree.
03:55:01 <Sundar> Excellent. That's a productive meeting. :)
03:55:24 <Sundar> #topic AoB
03:55:41 <Sundar> Since we are in the last 5 minutes, anything else to bring up?
03:55:51 <Yumeng> sorry, Sundar. another  two quick questions.
03:56:07 <Yumeng> device_profile create and delete, role "admin" required,  right?
03:56:26 <Yumeng> patch devices and deployables, role "admin" required, right?
03:56:57 <shaohe_feng73> project_admin can have their own DP.
03:57:20 <brinzhang> agree
03:57:33 <shaohe_feng73> patch devices is similar with program.
03:57:50 <shaohe_feng73> we should do more distinguish.
03:58:30 <brinzhang> system_admin and project_admin? if the project_admin can do, the system_admin also can do.
03:58:53 <Sundar> Agreed to both questions
03:59:00 <xinranwang> Yumeng:  which one you mean when you say "admin", system_admin or project admin
03:59:12 <shaohe_feng73> yes, limit project_admin.
03:59:44 <Sundar> patche devices: sys admin. patch deployables: accelerator_admin
04:00:00 <Sundar> devic eprofiles create, delete: sys admin
04:00:04 <shaohe_feng73> it is evil if one can do anything. :]
04:00:31 <xinranwang> Sundar:  I agree with you :)
04:00:43 <shaohe_feng73> DP can be project admin.
04:00:54 <Yumeng> Sundar: agree.
04:01:23 <shaohe_feng73> Did not agree with DP.
04:01:38 <Sundar> shaohe_feng73: what is "DP"?
04:01:53 <shaohe_feng73> device profiles
04:02:28 <Sundar> A 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:51 <shaohe_feng73> for， in really cloud sys admin can not prediction application scenarios
04:02:53 <Sundar> A project admin represents a tenant, and so cannot create flavors that he or she likes
04:04:07 <Sundar> If 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 that
04:04:14 <shaohe_feng73> so if no flavor or DP satisfy with him, what should do?
04:04:27 <Sundar> Ask the operator and agree to pay more ;)
04:04:47 <shaohe_feng73> so the operator help to create a New one?
04:04:56 <shaohe_feng73> that's OK.
04:04:59 <Sundar> yes, as with flavors
04:05:36 <shaohe_feng73> but in some private, the cloud provider can let tenant to create their own DP.
04:05:52 <shaohe_feng73> anyway the policy can change by themselves.
04:06:19 <shaohe_feng73> for private maybe no need bill
04:06:27 <Sundar> Well, I think a cloud admin can delegate roles to others. If they really want to.
04:06:57 <xinranwang> Yes, the policy we discussed here is more like general policy in openstack
04:07:09 <Sundar> xinranwang: Exactly
04:07:27 <brinzhang> current role just we set in Cyborg by default.
04:07:56 <Sundar> brinzhang: what do you mean?
04:08:30 <brinzhang> if the user want to change I think they already think twice
04:08:47 <shaohe_feng73> general  == public cloud?
04:09:02 <brinzhang> Sundar: I mean you ponit these policy is the default policy.
04:09:21 <brinzhang> patche devices: sys admin. patch deployables: accelerator_admin devic eprofiles create, delete: sys admin
04:09:39 <Sundar> Yes.
04:09:51 <xinranwang> If 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:10:30 <Sundar> Yes.
04:11:39 <Sundar> Quick 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:12:15 <Sundar> We can pick this up next week.
04:12:27 <shaohe_feng73> I guess Kolla.
04:12:37 <Sundar> Any other topic for today?
04:12:41 <brinzhang> Kolla
04:13:13 <brinzhang> I think there is a patch for improve UT need to talk
04:13:28 <brinzhang> that impact some patches to merge
04:13:41 <Sundar> brinzhang: Got it. I'll add it to next week's agenda.
04:14:03 <brinzhang> Sundar: ok~!
04:15:02 <brinzhang> Sundar: You can record https://review.opendev.org/#/c/702807
04:15:07 <Sundar> Meanwhile, 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:47 <Sundar> brinzhang: Will do
04:16:04 <Li_Liu> sounds good, will do
04:16:12 <Sundar> Thanks a lot, everybody. Have a good day! :)
04:16:13 <chenke> ok
04:16:16 <Sundar> #endmeeting