| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2018-08-13 | |||
| 14:16:32 | Li_Liu | Sundar, that is exposed by cyborg-api, not meat to be used by Agent | |
| 14:17:46 | Sundar | Li_Liu: Was that agreed only for GET, not for PUT/POST? | |
| 14:18:19 | shaohe_feng | wangzhh: good evening. | |
| 14:19:10 | wangzhh | shaohe_feng: good evening. :) | |
| 14:19:15 | Li_Liu | Sundar, PUT/POST are open to admin I think, in case they want to tune some of the deployables | |
| 14:20:18 | Sundar | Li_Liu: the issue there is that we will have to maintain backwards compat for REST APIs. That is going to constrain our development and/or cause upgrade issues. | |
| 14:21:13 | Li_Liu | wangzhh, do you have comments on this? | |
| 14:22:00 | wangzhh | Sundar, what do you mean about "we will have to maintain backwards compat for REST APIs. That is going to constrain our development and/or cause upgrade issues." | |
| 14:23:11 | wangzhh | Can u give me an example which current APIs can not handle? | |
| 14:23:32 | Sundar | wangzhh: In #link https://etherpad.openstack.org/p/cyborg-rocky-development (Line 44), if we allow PUT/POST in addition to get, we may have such considerations | |
| 14:25:15 | wangzhh | We have PATCH now. If we want to update deployable. we can use it. | |
| 14:25:46 | shaohe_feng | sure we should allow PUT/POST, that depends on | |
| 14:26:09 | Sundar | wangzhh: Can you elaborate? | |
| 14:26:35 | wangzhh | shaohe_feng: Do we need create deployable via API? | |
| 14:27:52 | shaohe_feng | That depends on. | |
| 14:28:07 | Li_Liu | wangzhh, maybe we should allow that for now | |
| 14:28:23 | shaohe_feng | at present, agent creates deployable. | |
| 14:28:30 | Li_Liu | to let admin able to add stuff in manaully | |
| 14:29:02 | Sundar | Li_Liu, shaohe: can you explain why that is necessary? And how we will ensure backwards compat and avoid upgrade issues? | |
| 14:29:04 | wangzhh | Sundar: https://github.com/openstack/cyborg/blob/719f3dee01b6f0b0f4f2ce9b45ffd4978eeac287/cyborg/api/controllers/v1/deployables.py#L217 | |
| 14:30:03 | shaohe_feng | Sundar: we should allow users to update some attribution of a deployable | |
| 14:30:30 | wangzhh | I agree that users need to update something. | |
| 14:31:20 | Sundar | By users, I hope you mean operators. End users (tenants) should not be touching this | |
| 14:31:22 | wangzhh | But can user create a new deployable? In which case? Could u give some example? | |
| 14:31:55 | Li_Liu | The users here should mean admin/operators | |
| 14:32:08 | shaohe_feng | ^ IMHO, Li_Liu, the intention of your attribution design should allow user to update them, right? | |
| 14:32:20 | Li_Liu | yes, indeed | |
| 14:32:30 | wangzhh | Agree. | |
| 14:32:50 | Sundar | If operators need a manual way, can't we provide a script of some kind? Before opening up REST APIs, we need to understand their implications. | |
| 14:33:06 | Li_Liu | I agree, right now Create api for deployables might not be very useful | |
| 14:34:15 | Li_Liu | Sundar, I assume the script you mena cyborg-pythonclient? | |
| 14:34:16 | shaohe_feng | Sundar: yes, at present it means admin/operations, Unless there are sufficient reasons that end users should update them | |
| 14:35:19 | wangzhh | Sundar, I think update is necessary. For example, I need change my deployable's name. Some attr which we can't collect from driver. | |
| 14:35:44 | Sundar | Li_Liu: isn't pythonclient a wrapper around the REST API? | |
| 14:36:19 | Li_Liu | Yes | |
| 14:36:23 | Sundar | wangzhh: Sure, we can provide some script that not guarantees backwards compat till it all matures | |
| 14:36:40 | Sundar | *does not guarantee | |
| 14:37:32 | Sundar | Perhaps @edleafe can comment but, my understand is that REST APIs need to be honored in future releases | |
| 14:37:42 | Sundar | *understanding | |
| 14:38:26 | Li_Liu | So you suggestion is take out the deployable creation rest api? | |
| 14:38:46 | edleafe | Sundar: it has nothing to do with REST - any published API should not be removed or modified | |
| 14:39:43 | Sundar | edleafe: What APIs do we publish to users apart from REST? RPC APIs are internal and can evolve across releases, right? | |
| 14:39:46 | edleafe | A public API is a contract with your users | |
| 14:40:26 | edleafe | I'm speaking more generally | |
| 14:40:57 | edleafe | Whether your API is REST, RPC, SOAP, or anything else: public APIs need to be maintained | |
| 14:42:16 | Sundar | If, say, Cyborg offers a RPC API to Nova or os-acc, we can evolve that in future releases based on mutual understanding, right? IOW, that doesn;t count as 'public' - exposed to users | |
| 14:43:04 | edleafe | I'm not following. If another service is relying on an API, then it's public | |
| 14:43:25 | wangzhh | Sundar, if we use script. It's hard to intergrate with other project or software. | |
| 14:43:50 | wangzhh | For example, If we want to update attr by horizon? | |
| 14:44:47 | wangzhh | Command line and script is not friendly. :) IMHO. | |
| 14:44:58 | xinran | If other service interact with cyborg there may be the rest ful apis | |
| 14:45:13 | wangzhh | Agree with xinran. | |
| 14:45:53 | Sundar | wangzhh: Before we make something public and incur all the costs for all future releases, let us keep it minimal. If it is not absolutely essential to do something with public APIs, we should look at alternatives first | |
| 14:46:40 | Sundar | edleafe: Has nova/os-vif/neutron RPC APIs never changed? I thought those have evolved too | |
| 14:47:54 | edleafe | Sundar: I don't really know - I haven't worked with Neutron or os-vif | |
| 14:47:58 | Li_Liu | Sundar, I am thinking about it in the other direction tho. I think there is no harm to open couple rest apis and maintain them. As we couldn't confine what the users can/want to do in their scenarios. | |
| 14:48:48 | Li_Liu | By offering something more, can open up more opportunities for them. | |
| 14:48:54 | edleafe | Li_Liu: you should always think very carefully before publishing an API | |
| 14:49:08 | Sundar | Li_Liu: That means keeping your deployables structure backwards compatible? Before we know all the use cases? | |
| 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 | |