| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-20 | |||
| 16:57:02 | sean-k-mooney | os-acc would only be a rest client | |
| 16:57:04 | mriedem | i got jinxed by a couple of 7 year old girls the other night, couldn't talk for 10 minutes, it was....not hard | |
| 16:57:31 | sean-k-mooney | the low level programing is handeled by the cyboge drivers and the tools they invoke | |
| 16:58:17 | Sundar | sean-k-mooney: True. But I think what is being said is that Nova views os-acc as performing the low-level tasks, i.e, it calls os-acc and leaves the details to it | |
| 16:58:23 | jaypipes | I really don't see why os-acc can't start off being a plug-the-device-into-the-VM library. | |
| 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 | openstack | Launchpad bug 1804271 in OpenStack Compute (nova) "nova-api is broken in postgresql jobs" [Undecided,New] | |
| 17:04:20 | slaweq | mriedem: bug reported: https://bugs.launchpad.net/nova/+bug/1804271 | |
| 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 | dansmith | no different than cinderclient or neutronclient right? | |
| 17:18:20 | Sundar | I am just pointing out that it exists and is different from os-acc | |
| 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 | |