| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-08-13 | |||
| 14:49:16 | edleafe | Li_Liu: https://blog.leafe.com/api-longevity/ | |
| 14:50:19 | shaohe_feng | Yes, API should be carefully, as edleafe said it is a contract :) | |
| 14:51:02 | Li_Liu | For sure, I am not saying we should do it without a thought :) | |
| 14:51:38 | wangzhh | Nova have API version to handle these issue. | |
| 14:51:57 | Sundar | shaohe: Not just the API. It will constrain how you can evolve the data structure that we call Deployable. How do we add new fields, drop old fields, or change the meaning/type/format of any field? | |
| 14:54:44 | Coco_gao | Hi | |
| 14:55:06 | shaohe_feng | Sundar: yes, we need a API version for them. | |
| 14:55:09 | edleafe | Sundar: you're describing alpha development, where things can be added/removed/changed. Is that you would describe Cyborg's current state? | |
| 14:55:10 | wangzhh | CoCo, Good evening. :) | |
| 14:55:16 | shaohe_feng | Coco_gao: evening. | |
| 14:55:47 | Sundar | wangzhh, shaohe, IIUC, having API versions does not mean that older versions can be dropped. They are still public | |
| 14:56:17 | Coco_gao | #evening or morning, everyone. | |
| 14:57:40 | edleafe | Sundar: exactly. The point of API versioning is that the default never changes, but users can opt in to a newer version | |
| 14:57:40 | Sundar | edleafe: Not quite, I am just advocating minimal public APIs till Cyborg has got some adoption and use cases are known and well-supported | |
| 14:57:48 | shaohe_feng | Sundar: yes. They are still public. For the end users's app still use older versions, depends on older instead of latest. | |
| 14:57:51 | wangzhh | Yep. LTS. But it can be dropped after depatched declaration. | |
| 14:58:06 | Li_Liu | As edleafe said, Cyborg is still at its very early dev stage | |
| 14:58:47 | Sundar | When you introduce API v2 with many changes, you still have to maintain v1 at least for some time. That means handling upgrades, conversions without breaking old functionality. | |
| 14:59:15 | edleafe | I would think that given Cyborg's early development status, that any APIs you create are labeled as alpha, with a note that they may be changed in the future | |
| 14:59:35 | edleafe | Sundar: some would contend that you have to maintain v1 forever. | |
| 14:59:41 | edleafe | (not me, though!) | |
| 15:00:13 | Sundar | edleafe: iIf we can mark REST APIs as alpha, that will be great | |
| 15:00:38 | Li_Liu | I think that's want we should be doing for now | |
| 15:00:48 | wangzhh | Sundar, all that mean that we should do with thought. Instead of not to do. | |
| 15:01:31 | edleafe | Sundar: http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html#new-or-experimental-services-and-versioning | |
| 15:02:46 | Sundar | Thanks, edleafe | |
| 15:02:49 | Sundar | Folks, shall we agree to mark Deployables API as alpha (subject to change without backwards compat) for now? | |
| 15:03:26 | Li_Liu | I vote yes | |
| 15:04:27 | wangzhh | Agree with Sundar. :) :) :) :) | |
| 15:04:46 | shaohe_feng | agree | |
| 15:05:28 | xinran | agree | |
| 15:05:31 | Coco_gao | I agree, I think maybe the alpha is the version when cyborg finish interactions with nova. Before that, cyborg is not workable by users. | |
| 15:06:06 | Sundar | Great! Thanks, guys. :) | |
| 15:06:17 | shaohe_feng | Sundar: you should take more time/though on how to define the API. Post your ideas and let we discuss together. | |
| 15:07:24 | shaohe_feng | Sundar: have you consider the API that nova how to apply an accelerators from cyborg? | |
| 15:08:45 | Sundar | shaohe: Yes, that should be part of the os-acc spec. We are still in the stage of getting agreement on the overall workflows and interactions. But I agree we should document that in detail | |
| 15:09:12 | shaohe_feng | Sundar: and also the parameters that API supports. | |
| 15:10:09 | Sundar | Sure. Please see https://review.openstack.org/#/c/577438/6/doc/source/specs/rocky/approved/compute-node.rst Line 525 for example | |
| 15:11:31 | shaohe_feng | Sundar: OK, for example, as a user I want to apply a accelerator, accelerator type is FPGA instead of GPU, vendor is intel, model is A10, and it's function is Crypto. | |
| 15:12:01 | shaohe_feng | Sundar: maybe more parameters will be extended. | |
| 15:13:16 | Li_Liu | shaohe_feng, use the attribute in deployables, if the fields are not supported | |
| 15:13:24 | shaohe_feng | Sundar: these parameters, nova will extract for your defined traits/RC in the flavor | |
| 15:13:34 | Sundar | Operators will define flavors based on the attributes you mentioned, and users will pick one of the flavors. The accelerator requirement is conveyed though extra specs, and that is aprt of these function signatures | |
| 15:13:57 | shaohe_feng | Li_Liu: Yes, I already use attribute :) | |
| 15:14:01 | Li_Liu | right now, when creating Deployables any parameters that are not native to deployable, will be added to the attribute_list | |
| 15:14:58 | shaohe_feng | yes. I did use attribute as this way. | |
| 15:15:42 | shaohe_feng | Sundar: also can we support to apply batch accelerators in that API? | |
| 15:16:12 | Sundar | shaohe: if you mean that a sigle VM may want more than one accelerator, sure. | |
| 15:16:30 | shaohe_feng | Sundar: for example, I want 2 accelerator, both accelerator type is FPGA, vendor is intel, model is A10, and it's function is Crypto. | |
| 15:16:58 | Coco_gao | Have we make an agreement on users' input, parameters or sections we may support by now? | |
| 15:17:02 | Sundar | Currently, the API gets a list of device RPs selected by Nova, and extra specs. But that is not ideal. Still trying to think of a better way | |
| 15:17:05 | shaohe_feng | Sundar: or I want 2 different accelerators, one is GPU another is FPGA? | |
| 15:17:53 | Sundar | shaohe: All that should be possible. The currently proposed APIs can technically handle them, but we can probably improve upon them | |
| 15:18:27 | shaohe_feng | Coco_gao: Sundar is working on them. | |
| 15:18:28 | shaohe_feng | Sundar when will we see your API define? | |
| 15:19:00 | shaohe_feng | Sundar: one api to apply 2 accelerators instead of two api call? | |
| 15:19:17 | Sundar | shaohe: I am updating the os-acc spec. It should be out by this week, if not in next couple of days. | |
| 15:19:54 | shaohe_feng | Sundar: nice. | |
| 15:19:57 | Sundar | shaohe: The current API looks something like: prepareVANs(device_rp[], extra_specs, instance_info) | |
| 15:20:02 | Coco_gao | Great jobs. | |
| 15:20:27 | Li_Liu | ok | |
| 15:20:32 | Sundar | The extra specs will contain the details of the user request, like: CUSTOM_ACCELERATOR_FPGA=2 and the traits | |
| 15:20:52 | Sundar | The device_rp[] will contain the device resource providers selected by Nova for each of those accelerators | |
| 15:21:08 | shaohe_feng | Sundar: anyway, the api should well match the user the expect accelerators | |
| 15:21:18 | Li_Liu | device_rp is a list, and extra_specs will be applicable to all the RPs in the list? | |
| 15:21:54 | Sundar | The problem is, how do we correlate each device_rp to a specific accelerator in extra specs. If we can massociate each user request with its own device RP, that will simplify our livs | |
| 15:23:51 | Li_Liu | can we make extra_specs a list as well? | |
| 15:23:56 | Sundar | Li_Liu: yes. The extra specs may contain groups based on granular request syntax #link https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/granular-resource-requests.html | |
| 15:24:13 | Sundar | The extra specs is a pre-defined thing coming from Nova. | |
| 15:24:35 | Li_Liu | ah, ok | |
| 15:24:36 | Sundar | Not sure if we can modify it. Still looking into that | |
| 15:25:31 | openstackgerrit | OpenStack Release Bot proposed openstack/cyborg master: Update reno for stable/rocky https://review.openstack.org/591423 | |
| 15:26:15 | shaohe_feng | I have already use resource groups to support batch accelerators :) | |
| 15:26:59 | shaohe_feng | Sundar: remind, have you notify rodrego that you and Coco_gao are refactoring the new returning data of the driver? | |
| 15:27:25 | Sundar | Oh yes. | |
| 15:27:34 | shaohe_feng | Good | |
| 15:27:46 | Sundar | We are currently looking at making the current driver patch work with Zuul | |
| 15:27:52 | shaohe_feng | Coco_gao: how is the refactor going on. | |
| 15:28:43 | Coco_gao | yeah, I am working on it right now. Still need to test the code by now. | |
| 15:29:10 | Sundar | Coco_gao: we probably need to sync up. Are you using OVOs? | |
| 15:29:33 | shaohe_feng | Coco_gao: good. Guess other developers are depending on your change. | |
| 15:29:56 | shaohe_feng | Sundar: have resolve the OPAE package install in Zuul? | |
| 15:29:59 | wangzhh | Coco:Good job. Plz don't forget test with my GPU driver. | |
| 15:30:34 | Coco_gao | Our Datacenter is going to move to other location, so the test work need to be done several days later. | |
| 15:31:31 | Coco_gao | Sundar, you mean VersionedObject? | |
| 15:31:31 | Sundar | shaohe: Rodrigo and I discussed the pkg install, and he is making changes | |
| 15:31:39 | Sundar | Coco_gao: yes | |
| 15:32:17 | Coco_gao | yes, I am using VersionedObject | |
| 15:32:17 | Sundar | We should update the spec before submitting the patch? | |
| 15:32:59 | shaohe_feng | Sundar: good. | |
| 15:33:05 | Sundar | I am still backlogged on os-acc. I'll update the driver/agent spec. Coco_gao, I cna send you an early version for review | |
| 15:33:17 | shaohe_feng | Sundar: you should sync up with Coco_gao well. | |
| 15:33:51 | shaohe_feng | Li_Liu: do we have deadline for this refactor? | |
| 15:33:51 | Sundar | Yes | |
| 15:34:08 | Coco_gao | I don't know | |
| 15:34:29 | Coco_gao | maybe we can discuss the deadline. | |
| 15:35:41 | Li_Liu | shaohe_feng, if you wanna catch the Rocky release, then Aug 20 - Aug 24 | |
| 15:35:53 | Li_Liu | but if not, there's not hard deadline on this | |
| 15:36:00 | Coco_gao | Sundar, any detailed questions or informations , plz send me an email(gaojh4@lenovo.com) | |
| 15:36:13 | shaohe_feng | yes, Your working is very important. for other drivers base on your work. | |