| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2020-02-06 | |||
| 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: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 | |
| 04:16:18 | chenke | bye | |
| 04:16:19 | openstack | Meeting ended Thu Feb 6 04:16:16 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 04:16:20 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.html | |
| 04:16:21 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.txt | |
| 04:16:22 | openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyborg.2020-02-06-03.01.log.html | |
| 04:16:36 | Li_Liu | thanks a lot . bye | |
| 04:18:07 | Yumeng | bye | |
| 04:19:02 | s_shogo | bye | |
| #openstack-cyborg - 2020-02-08 | |||
| 17:41:35 | openstackgerrit | Merged openstack/cyborg master: Define fake db objects for UT https://review.opendev.org/702807 | |