| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-02-06 | |||
| 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? | |