| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-02-06 | |||
| 03:07:47 | xinranwang | Thanks for your great efforts Sundar | |
| 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 | |