| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 17:17:11 | Sundar | Folks, there is a Cyborg client: https://github.com/openstack/python-cyborgclient | |
| 17:17:43 | sean-k-mooney | Sundar: yes there is but that is really the commandline client right | |
| 17:17:56 | Sundar | Yes ^ | |
| 17:18:09 | dansmith | but still, | |
| 17:18:20 | Sundar | I am just pointing out that it exists and is different from os-acc | |
| 17:18:20 | dansmith | no different than cinderclient or neutronclient right? | |
| 17:18:21 | sean-k-mooney | the openstack sdk in theory is ment to replace the python-client | |
| 17:18:31 | sean-k-mooney | dansmith: ture | |
| 17:19:24 | dansmith | isn't the only reason we're going to have os-acc over cyborgclient is for the object definitions? | |
| 17:19:27 | dansmith | a la os-vif | |
| 17:19:31 | sean-k-mooney | if gibi's rp mapping code is generic enough nova could reuseit before calling into the sdk or cyborge client to update cyborge | |
| 17:19:54 | sean-k-mooney | dansmith: that is one of the main reasons yes | |
| 17:20:32 | Sundar | dansmith: yes, and for conversions to/from such objects. For example, if a Cyborg API returns a JSON, os-acc would convert that to an OVO. | |
| 17:21:05 | dansmith | Sundar: that doesn't make any sense | |
| 17:21:11 | dansmith | or.. I hope you're just planning to return the serialized object.. :) | |
| 17:23:22 | Sundar | dansmith: The return values from Cyborg API are not necessariy the OVOs defined in os-acc. They are meant to be neutral, used even in scenarios where Cyborg may be used stand-alone | |
| 17:23:45 | dansmith | Sundar: well there's probably not much point in the OVOs then at that point | |
| 17:24:24 | sean-k-mooney | if we just use the python client or sdk we can just use python classes | |
| 17:24:28 | Sundar | dansmith: if you are OK with providing a versioned JSON to Nova as a return value from Cyborg API, that is fine too | |
| 17:24:41 | sean-k-mooney | and if we have jason scema definitions for the cyboge api we can validate them | |
| 17:24:42 | openstackgerrit | Jack Ding proposed openstack/nova master: Add HPET timer support for x86 guests https://review.openstack.org/605902 | |
| 17:26:40 | Sundar | dansmith: sean-k-mooney: Are we now saying os-acc is not adding much value, and Nova can directly call Cyborg APIs? | |
| 17:27:00 | dansmith | Sundar: nova is going to use some sort of client regardless | |
| 17:27:35 | Sundar | Yes, agreed ^ | |
| 17:27:36 | dansmith | Sundar: honestly, I'm not sure where we're at now.. I thought os-acc was going to be the only clienty thing and that it was going to define object models to be passed over the api between the services | |
| 17:27:45 | dansmith | sounds like that's not clear | |
| 17:27:53 | dansmith | and there is another cyborg api client already | |
| 17:27:57 | dansmith | so I dunno | |
| 17:28:02 | Sundar | dansmith: I agree with that! That's what I thought too | |
| 17:28:46 | Sundar | If Cyborg returns a JSON value, os-acc could subject that to JSON schema valiadation, like what Sean said | |
| 17:28:53 | mriedem | i assume sean-k-mooney wanted os-acc to do ovo translation stuff ala the long-held dream of ovo version negotiation for nova/neutron and os-vif | |
| 17:28:55 | sean-k-mooney | Sundar: you raise tho in that case the python classes that define the cyborge api resocues before they are converted to json would live in os-acc in that case | |
| 17:29:19 | sean-k-mooney | mriedem: that would be nice but not requrired | |
| 17:29:38 | sean-k-mooney | mriedem: i was hoping it would work like neutron-lib which contians the api defitions | |
| 17:29:42 | mriedem | sounds like we're building in more complexity than we really need right now | |
| 17:29:54 | mriedem | if nova just needs to call apis, then cyborgclient is the way to go | |
| 17:30:06 | mriedem | adding in ovo sugar later via an os-acc library could be done when needed | |
| 17:30:56 | dansmith | Sundar: any client can/would/should do schema validation | |
| 17:31:02 | sean-k-mooney | mriedem: one thing i would however is that we do not need to make regualr commits to nova to account for change to the cyborg api | |
| 17:31:07 | dansmith | Sundar: not sure why that means os-acc should be separate | |
| 17:31:22 | dansmith | sean-k-mooney: that's the case for any client | |
| 17:31:35 | sean-k-mooney | sure | |
| 17:32:18 | Sundar | dansmith: The current Cyborg client is not designed to convert the return values of APIs to what Nova expects. We would need something on top of that, and that could be os-acc | |
| 17:32:20 | sean-k-mooney | i think os-acc orginally came about because of the desire to be able to talk to the cyborg agent on the same host as the nova agent | |
| 17:32:31 | sean-k-mooney | that is not part of the spec anymore | |
| 17:32:59 | mriedem | most of the existing python-*client projects in openstack don't do response validation, they just take the response payload and throw it into a dict-like object | |
| 17:33:00 | dansmith | Sundar: nova can digest whatever the client returns | |
| 17:33:14 | sean-k-mooney | Sundar: or we define a set of class the represent the public api and nova will jsut use that | |
| 17:33:16 | dansmith | Sundar: we don't need a whole library to turn one dict into another | |
| 17:33:18 | mriedem | the caller needs to understand what is in that object, field-wise, based on version | |
| 17:34:22 | sean-k-mooney | mriedem: yes that is true which is totlly fine for stable apis | |
| 17:35:36 | sean-k-mooney | the cyborge api is not mature and stable yet and that might lead to a non zero amount of curn on the nova side to handel unless the python cyborge client can provide a semi stable subset we can use | |
| 17:36:03 | Sundar | mriedem: sena-k-mooney: Cyborg API is versioned. In the event of changes, we would move to v2 | |
| 17:36:47 | sean-k-mooney | Sundar: sure but nova would have to be addapted to V2 | |
| 17:36:55 | mriedem | Sundar: does cyborg use microversions? | |
| 17:36:55 | Sundar | mriedem: Cyborg API return values are documented -- now in the Nova spec but eventually in a Cyborg spec | |
| 17:37:13 | Sundar | mriedem: No, not today. | |
| 17:37:48 | mriedem | are there plans to? or just bump major versions whenever there is an api change? | |
| 17:38:10 | mriedem | GET /v65/accelerators | |
| 17:38:31 | mriedem | anyway, again, probably not really necessary for this conversation for what nova needs | |
| 17:38:39 | Sundar | mriedem: Currently, I haven't planned on microversions. I think you mean a microversion per API call? | |
| 17:38:51 | mriedem | microversions are per request yes | |
| 17:39:06 | mriedem | if not specified, there is a minimum default | |
| 17:39:14 | mriedem | 2.1 for nova, but i'd expect 1.0 or something for cyborg | |
| 17:40:07 | Sundar | If we go with major versions alone, would moving to microversions later cause upgrade issues? Not if we bump major version *and* introduce microversions with that, I suppose? | |
| 17:40:46 | mriedem | nova had v2.0 and then microversions were added in 2.1, which was backward compatible with v2.0 | |
| 17:40:48 | sean-k-mooney | Sundar: the difference is ususally you dont run multiple majour virsions at the same time | |
| 17:41:10 | mriedem | nova was going to have a v3 but that became v2.1 | |
| 17:41:24 | Sundar | Sounds good | |
| 17:41:28 | mriedem | cinder had v1 and v2, | |
| 17:41:32 | mriedem | and they added microversions in v3.0 | |
| 17:41:40 | mriedem | so it sounds like you'd be following the cinder model | |
| 17:41:51 | sean-k-mooney | Sundar: in a singel boot request we could call cyborge with multiple versions if it supported microversions | |
| 17:42:16 | mriedem | anywho | |
| 17:42:17 | sean-k-mooney | e.g bind with 1.1, program with 1.5 | |
| 17:42:38 | mriedem | the advantages of microversions isn't really necessary for what nova needs initially with cyborg | |
| 17:42:49 | Sundar | Hmm, ok. I need to think about that. Given the long task list for Cyborg in Stein, may be we can introduce microversions later, as needed | |
| 17:43:20 | mriedem | and it sounds like we don't need something translating JSON responses to OVOs | |
| 17:43:21 | sean-k-mooney | Sundar: what is the status fo teh deployable api endpoint currently | |
| 17:43:34 | Sundar | dansmith: sean-k-mooney: mriedem: What I am gathering is, we need a client for Nova to call Cyborg. That can be just the Cyborg client, as os-acc is not adding much value. Is that correct? | |
| 17:43:35 | mriedem | so what i'm hearing is nova just needs cyborgclient | |
| 17:43:43 | mriedem | Sundar: i think so | |
| 17:44:04 | mriedem | before we make this all so complicated that we never get anything done, we should probably start with that | |
| 17:44:08 | sean-k-mooney | if we can reuse gibi's resouce prvider mapping code for cyborge then yes | |
| 17:45:01 | Sundar | sean-k-mooney: is that a long haul? Can we reasonably expect that to get in by, say, Jan? | |
| 17:46:07 | gibi | Sundar: the non-generic mapping code is up in gerrit, I just got the comment yesterday that it can be done a lot more generic way so I'm working on that right now. I think this week I can publish the generic code | |
| 17:46:24 | gibi | Sundar: https://review.openstack.org/#/c/616239 | |
| 17:46:32 | Sundar | gibi: Excellent, thanks! | |
| 17:46:38 | dansmith | Sundar: as we have said, serializing all of this work is definitely going to blow all your timelines | |
| 17:47:17 | sean-k-mooney | Sundar: has any work progressed on the ci front | |
| 17:47:21 | Sundar | dansmith: sean-k-mooney: Can you please state 'for the record' that you are ok with dispensing os-acc and having Nova call Cyborg directly? | |
| 17:48:03 | Sundar | sean-k-mooney: The concept of Deployables is being reworked to map to RPs. What do you mean by 'CI front'? Zuul checking for Cyborg? | |
| 17:48:11 | sean-k-mooney | Sundar: yes we can call directly with out os-acc via the python clients. | |
| 17:48:15 | dansmith | Sundar: once again, nova will use a client library and not call directly. I do not care what the name of that thing is | |
| 17:48:54 | sean-k-mooney | im agreeing with dan by teh way eventhough we said it differently | |
| 17:49:01 | dansmith | yes | |
| 17:49:01 | Sundar | dansmith: If it is the standard Cyborg client, Nova will have to do the necessary conversions to/from JSON. Hance the question | |
| 17:49:23 | sean-k-mooney | what i meant for the ci front is we talk about the need to do some basic integration testing | |
| 17:49:24 | dansmith | Sundar: when nova uses a client library, it has to deal with the output of that client | |
| 17:49:43 | dansmith | Sundar: no client library returns exactly what we need with no massaging, of course | |