Earlier  
Posted Nick Remark
#openstack-cyborg - 2018-04-04
15:07:06 shaohe_feng_ yes, it should. And seems nova agree on the weigher
15:07:18 Sundar Li_Liu: OK, what I meant is, it runs in the controlle ralong with Nova/Cyborg. The operator must update nova.conf to use this weigher
15:07:36 Li_Liu Right :)
15:07:47 zhipeng Okey
15:08:15 shaohe_feng_ yes. just a config option in nova
15:08:45 zhipeng Sundar I think it is definitely fine to update the spec patch based upon the current discussion conclusion
15:09:04 zhipeng and let's schedule another video conf for a detailed discussion with Xilinx team
15:09:08 Sundar The part of this proposal which needs further review from Nova is when one bitstream has multiple functions, say crypto and compression. I think that is for the future and may not be needed in rocky. Does that sound agreeable?
15:09:15 zhipeng to see if there is any further improvements
15:09:37 shaohe_feng_ but weigher may be not very high priority. It is help to speed up the creation of a VM. but no helpful for the VM performance after VM start
15:09:39 Sundar Thanks, Howard!
15:09:40 zhipeng Sundar yes that would be maybe next release :)
15:10:28 edleafe Just an FYI - it's not likely that nested RPs will be complete in Rocky
15:10:39 zhipeng shalhe_feng_ agree, let's implement the custom rc and traits first
15:10:54 zhipeng edleafe it is possible that we try with the nrp first right ?
15:11:32 edleafe zhipeng: sure, but it looks like the earliest nrp will be available will be in Stein
15:11:46 Sundar edleafe: There is a release notes in Queens for nRPs, right? https://github.com/openstack/nova/blob/adc4d4a29d108c87f884c779af5696e4941b9549/releasenotes/notes/placement-rest-api-nested-resource-providers-552a923a96d7adca.yaml
15:12:42 edleafe Sundar: that is the very beginnings of the structural changes needed for nrp
15:13:10 shaohe_feng_ edleafe: so cyborg just can support a fpga resource class in node provider in this release?
15:13:19 edleafe the full model we need is still far away
15:13:44 Sundar edleafe: The backup optoion would be to apply the RCs and traits to the compute node RP. But, when there are multiple devices in the same node, that can result in issues.
15:13:53 edleafe shaohe_feng_: I'm not sure how that would work if you have multiple devices per node
15:14:25 Sundar edleafe: We crossed. :)
15:14:29 edleafe I'm on a call right now - I just wanted to set your expectations
15:14:38 zhipeng edleafe thx :)
15:14:39 shaohe_feng_ edleafe: IMHO, we can support multiple devices later.
15:14:56 zhipeng yes let's be flexible
15:15:27 zhipeng #action Sundar update the spec according to the ml discussion conclusion
15:15:37 Sundar We can support multiple devices with some restrictions, which may satisfy immediate needs and still give freedom to operaors
15:15:52 zhipeng I would especially thanks Sundar for his initiative on the mailing list
15:16:06 shaohe_feng_ Sundar: any code plan for the spec?
15:16:08 zhipeng and also the spec discussion with Nova team
15:16:14 Li_Liu Or can we put a simple version of multiple device support in Cyborg for now?
15:16:21 Sundar shaohe, yes.
15:16:25 zhipeng shaohe-feng_ your PoC code could be used right ?
15:16:27 Sundar Thanks, Howard
15:16:54 shaohe_feng_ zhipeng: yes. I think so.
15:16:59 Sundar The POC code does not publish RCs and traits
15:17:04 Sundar But we can build on that
15:17:17 zhipeng yes that's what i meant
15:17:20 shaohe_feng_ Sundar: it publish
15:17:40 Sundar Also, the notion of using PFs and VFs as resources is something the Nova/PTG folks didn;t want ;)
15:18:04 Sundar Shaohe: sorry, to clarify, it publishes PCI functions as RCs right?
15:18:12 zhipeng let's take the details offline :)
15:18:20 Sundar ok :)
15:18:22 shaohe_feng_ Sundar: the poc is similar to nova teams conclusion.
15:18:27 zhipeng next up, Li Liu's metadata spec
15:18:38 zhipeng #info metadata standardization spec
15:18:50 zhipeng #link https://review.openstack.org/558265
15:19:03 shaohe_feng_ and we know nrp is not ready, so simply it.
15:19:04 zhipeng folks plz review it
15:19:13 zhipeng anything you want to add, Li_Liu ?
15:19:33 chucksong zhipeng, sorry for interrupt, what's the expected freeze date for the Xilinx driver spec? april 19 or Jun.4?
15:19:51 zhipeng chucksong Jun 4
15:19:55 Li_Liu zhipeng, I made some modifications based on shaohe's comments couple days ago. Waiting for more suggestions
15:20:08 zhipeng Li_Liu okey :)
15:20:09 chucksong good, thanks!
15:20:21 zhipeng okey moving on
15:20:27 Li_Liu My next spec for programmability is on the way. within the week I think
15:20:44 zhipeng Li_Liu you are the rock star man
15:20:50 Sundar Li_Liu: I had some high level comments on the spec. We can discuss them in more detail when you want
15:20:58 zhipeng I will cry myself to sleep tonight :P
15:21:17 zhipeng #info cyborg-spec setup
15:21:28 Li_Liu sure sundar, wehcat/skype/phone/email whatever you want man
15:21:32 zhipeng #link https://review.openstack.org/554766
15:21:45 zhipeng Yumeng__ has been great to setup the cyborg-spec repo
15:22:08 zhipeng I think the current patch look good, so if plz any core give a +2, I will land it this week
15:23:00 zhipeng okey folks we still have planned specs missing for rocky
15:23:16 zhipeng #info quota and os-acc spec still missing
15:23:51 zhipeng I will talk to indicidual owners to see how to push forward
15:23:59 zhipeng deadline is less than three weeks away :)
15:24:24 zhipeng #action Howard to track the missing quota and os-acc spec
15:24:39 zhipeng #topic open patches that need attention
15:24:57 zhipeng #info shaohe_feng's devstack fix
15:25:10 zhipeng #link https://review.openstack.org/557742
15:25:25 Yumeng sorry to interrup. Here is the more detailed clock-driver use case description link I sent in the mail list: https://etherpad.openstack.org/p/clock-driver
15:25:30 zhipeng great work from shaohe, I will have zhuli help merge this by the end of the week
15:25:32 shaohe_feng_ zhipeng: this should be land first. :)
15:25:34 zhipeng Yumeng thx !
15:25:35 Yumeng Driver proposal would be provided next.
15:25:58 zhipeng Yumeng I think you could directly put it up as a driver spec :P
15:26:24 shaohe_feng_ shaohe_feng_: It can help to avoid other debugs coming.
15:26:29 Yumeng zhipeng: okey.that would be great.
15:26:39 openstackgerrit Li Liu proposed openstack/cyborg master: Implemented the Objects and APIs for vf/pf https://review.openstack.org/552734
15:26:46 zhipeng shaohe_feng_ I will nag zhuli :P
15:26:58 zhipeng next, which Li_Liu just updated
15:27:17 zhipeng #info object and apis for vf/pf
15:27:28 Li_Liu lol.. I just addressed some comments from Shaohe yesterday
15:27:30 zhipeng #link https://review.openstack.org/552734
15:27:42 zhipeng :)
15:28:18 zhipeng Okey I think that is all the important stuff we need to discuss today
15:28:20 Li_Liu Sundar, I hear you said Nova folks does not like vf/pf representations
15:29:05 shaohe_feng_ good
15:29:28 shaohe_feng_ Li_Liu: it is internal implementation, Why do not like?
15:29:30 Li_Liu but I think vf/pfs are more friendly to vendor drivers. And it can be used interchangeably with Deployables
15:29:45 shaohe_feng_ Li_Liu: yes.
15:30:12 Sundar Li_Liu: yes, this is PTG feedback: e.g. https://etherpad.openstack.org/p/cyborg-ptg-rocky-nova-cyborg-interaction Line 21
15:30:24 shaohe_feng_ Li_Liu: but your vf/pf representations is not expose
15:30:26 Li_Liu shaohe_feng_, I know, just wanna point it out, in case nova folks have questions on them. :)
15:30:44 Sundar Our implementation still uses PFs/VFs of course

Earlier   Later