| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 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 | Sundar | mriedem: Cyborg API return values are documented -- now in the Nova spec but eventually in a Cyborg spec | |
| 17:36:55 | mriedem | Sundar: does cyborg use microversions? | |
| 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 | 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:01 | dansmith | yes | |
| 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 | |
| 17:50:34 | Sundar | dansmith: Great. I will update the spec to skip os-acc. Thanks a lot to you, sean-k-mooney and mriedem. | |
| 17:50:42 | Sundar | I still have the question on colocation | |
| 17:51:13 | Sundar | Re. request groups in device profiles, it is still not clear to me how we would handle co-location without them, i.e., we want 2 accelerators from 2 different RPs in the same device | |
| 17:51:42 | Sundar | sean-k-mooney: You mentioned NUMA ffinity in your rpelies oin the spec. I am looking at co-location within a device | |
| 17:53:21 | sean-k-mooney | Sundar why would you have 2 different RP on the same device instead of 2 inventories in 1 device | |
| 17:53:33 | Sundar | Because they have different traits | |
| 17:53:37 | sean-k-mooney | * 2 inventories in 1 rp | |
| 17:54:01 | sean-k-mooney | ok then have 1 RP for the devce and two nested rp for the two acllerators | |
| 17:54:20 | Sundar | Say an FPGA with 2 regions: one has compression, other has encryption and we want to gang them up together | |
| 17:54:27 | sean-k-mooney | then we can use in_tree=<device rp uuid> for the colocation | |
| 17:55:02 | dansmith | Sundar: those aren't traits, right? | |
| 17:55:11 | Sundar | sean-k-mooney: Would the traits be applied to the parent RP or the children RPs? Ans, more importantly, is that scenario working today? | |
| 17:55:12 | dansmith | Sundar: those are inventories on a single provider, no? | |
| 17:55:36 | Sundar | dansmith: No, they are in 2 different RPs, but on the same device (PCI card for e.g.) | |
| 17:55:47 | sean-k-mooney | Sundar: i was tinking the childe RPs | |
| 17:55:52 | dansmith | Sundar: in that case, what would the inventories be? | |
| 17:56:08 | Sundar | Because they represent different functions, and functions are traits, they would show up as 2 RPs | |
| 17:56:24 | sean-k-mooney | they are different resouce classes also | |