| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 17:05:21 | Sundar | Taking a step back: pretty much everything that needs to be done either requires Cyborg db access or device poking via Cyborg drivers. | |
| 17:06:05 | dansmith | Sundar: you understand you can't poke the cyborg db from os-acc or nova though right? | |
| 17:06:40 | Sundar | dansmith: Yea, thats why I am saying os-acc needs to call Cyborg API | |
| 17:07:03 | dansmith | yeah | |
| 17:07:19 | dansmith | I definitely never saw where in the spec it said that os-acc would talk directly to the cyborg db | |
| 17:07:20 | sean-k-mooney | Sundar: and simlarly do you want os-acc to be able interact with the device directly? i assume no | |
| 17:07:52 | Sundar | Yup, no direct access | |
| 17:08:14 | mriedem | i think the confusion was because of this question / statement earlier, which prompted me to ask about direct db access: | |
| 17:08:15 | mriedem | (10:10:21 AM) Sundar: I still have some questions on what jaypipes expects. The os-acc is not going to handle devices by itself. It neds access to Cyborg db and drivers, which means the majority of work will happen in Cyborg. | |
| 17:08:42 | Sundar | sean-k-mooney: Even in past specs, os-acc wouldn;t talk to CYborg drivers -- it was talking to Cyborg agent on the same compute node -- and that was all prior to the Stein PTG | |
| 17:08:43 | dansmith | right, which is saying "it can't, because .. access to db" | |
| 17:08:44 | dansmith | right? | |
| 17:09:01 | mriedem | yes i realize it meant, "access to the db and drivers via the cyborg rest api" | |
| 17:09:16 | sean-k-mooney | Sundar: that was going to be my next question | |
| 17:09:27 | dansmith | well, I think it means "it has to ask cyborg via api to do that, because only cyborg has access to the drivers and db" but.. same difference | |
| 17:09:41 | sean-k-mooney | yes at the ptg we said os-acc would not talk to the agent directly either | |
| 17:09:58 | sean-k-mooney | so does os-acc talk to anything other then the cyborge api | |
| 17:10:54 | Sundar | If you look at the os-acc API notes in the Nova spec, I have even identified which Cyborg API whill be called in each scenario | |
| 17:11:13 | Sundar | sean-k-mooney: No | |
| 17:11:55 | sean-k-mooney | ok so the statement i made earilar that os-acc will only talk to the rest-api and is not the lovel device lib was corect | |
| 17:12:13 | mriedem | in that case, why not just use openstacksdk? | |
| 17:12:27 | mriedem | i realize this is bike shedding a bit, | |
| 17:12:40 | mriedem | but os-acc makes me think of os-vif and os-brick which definitely do not call REST APIs in cinder or neutron, | |
| 17:12:46 | sean-k-mooney | mriedem: there is no sdk support yet but that would also be a valide approch | |
| 17:12:54 | Sundar | mriedem: That's a good point. There is still a need for os-acc. | |
| 17:12:57 | mriedem | and if there is no python-cyborgclient, like there is no python-placementclient, we should just use openstacksdk | |
| 17:13:45 | Sundar | For example, os-acc associates device RPs with individual accelerator requests from the device profiles, because Nova/Placement don't do that | |
| 17:14:00 | dansmith | mriedem: well, I think the linkage to os-vif was around defining pluggable data types, so that things other than PCI would be doable | |
| 17:14:13 | mriedem | "For example, os-acc associates device RPs with individual accelerator requests from the device profiles, because Nova/Placement don't do that", | |
| 17:14:33 | mriedem | meaning it's going to be doing things like neutron agent for bandwidth provider inventory/allocations? | |
| 17:15:46 | sean-k-mooney | mriedem: meaing that when nova get the allcoation candiate form placement in the schduerler/condcutor os-acc will parse it try and figure out which RP maps to each device profile and tell cyborg | |
| 17:15:50 | gibi | mriedem: as a side note, I was pushed to the direction to do the mapping in a more generic way, between RequestGroup ovos in the RequestSpec and RPs in the allocation | |
| 17:16:24 | gibi | mriedem: which means the core of that code will be generic enough for cyborg use as well | |
| 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 | |