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