| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 16:58:25 | dansmith | sean-k-mooney: I don't know why you're so intent on declaring that os-acc is only one thing or another | |
| 16:58:40 | dansmith | jaypipes: that's not a separate action | |
| 16:58:48 | jaypipes | dansmith: what do you mean? | |
| 16:58:57 | dansmith | jaypipes: plugging involves writing pci attachment into the virt xml for boot, right? | |
| 16:59:19 | dansmith | jaypipes: if there's any massaging of the device needed, like writing to sys to discover a new pci endpoint or something, then that seems like it could/should be in os-acc | |
| 16:59:23 | sean-k-mooney | jaypipes: would you be happy saying os-acc could start as beeing a program the device for the vm lib | |
| 16:59:46 | mriedem | in other news, we broke postgresql http://logs.openstack.org/periodic/git.openstack.org/openstack/neutron/master/neutron-tempest-postgres-full/a52bcf9/logs/screen-n-api.txt.gz?level=ERROR | |
| 17:00:28 | jaypipes | dansmith: yes, I agree with you. I just don't believe os-acc should be a REST API client to cyborg. | |
| 17:00:48 | dansmith | jaypipes: so we need a cyborgclient? | |
| 17:00:59 | dansmith | jaypipes: I'm not sure what os-acc would be doing if it's not talking to cyborg | |
| 17:02:08 | sean-k-mooney | dansmith: i would like to clearly scope what os-acc is so that i can understand what componets prefrom what actions | |
| 17:03:40 | sean-k-mooney | Sundar: the reason i care about if os-acc is just interacting with the rest api is because if it not. e.g it use the RPC bus or cyborge db directly then it has deployment impact | |
| 17:03:54 | sean-k-mooney | e.g. the credetials an connection info | |
| 17:04:09 | dansmith | sean-k-mooney: nobody is arguing for that are they? | |
| 17:04:12 | sean-k-mooney | if it interacts with the devices directly it has packaging impacts | |
| 17:04:17 | Sundar | sean-k-mooney: I agree. os-acc will indeed talk to Cyborg API, not the agents or drivers directly. | |
| 17:04:20 | slaweq | mriedem: bug reported: https://bugs.launchpad.net/nova/+bug/1804271 | |
| 17:04:20 | openstack | Launchpad bug 1804271 in OpenStack Compute (nova) "nova-api is broken in postgresql jobs" [Undecided,New] | |
| 17:04:26 | mriedem | slaweq: thanks again | |
| 17:04:30 | dansmith | sean-k-mooney: crossing over to the db/mq between projects would be a major issue I think | |
| 17:04:39 | jaypipes | (sorry, folks, I'm in another meeting...) | |
| 17:05:04 | slaweq | yw :) | |
| 17:05:08 | sean-k-mooney | dansmith: in past version of the spec it was allowed to | |
| 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 | |