Posted	Nick	Remark
#openstack-nova - 2018-11-28
12:02:08	openstackgerrit	Ghanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620579
12:02:30	openstackgerrit	Ghanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620578
12:32:35	openstackgerrit	Ghanshyam Mann proposed openstack/nova stable/pike: DNM: For testing only https://review.openstack.org/620592
12:49:15	jroll	flwang: at oath we eventually changed the catalog, it was fine
14:34:12	mriedem	couple of easy patches here that need another core https://review.openstack.org/#/c/620165/ https://review.openstack.org/#/c/620170/
14:42:18	gmann	mriedem: melwitt nova-next job does not run in queens but seems like it supposed to run there - https://github.com/openstack/nova/blob/master/.zuul.yaml#L140
14:42:43	gmann	reason is- job migration patch got merged in rocky - https://review.openstack.org/#/c/541474/
14:43:14	gmann	and it was mistakenly added in stable/queens check and gate pipeline list here - https://review.openstack.org/#/c/604134/
14:43:51	gmann	nova-next job definition is not present in stable/queens but listed in check and gate pipeline.
14:47:41	gmann	to run it on queens, we need to backport these 2 in queens - https://review.openstack.org/#/c/541474/ https://review.openstack.org/#/c/513160/
14:50:04	Sundar	efried: Please ping me when you have the time.
14:50:13	efried	Sundar: I'm here. What's up?
14:52:14	Sundar	efried: Are you aligned with the decision to drop os-acc? I am trying to make sure we have a quorum of Nova developers.
14:53:49	gmann	stephenfin: what is use of bug-tag in openstackdocstheme? - https://review.openstack.org/#/c/619434/2
14:54:01	gmann	i did not find where it was linked on doc/buglink
14:54:07	artom	gmann, he's on PTO
14:54:39	gmann	artom: ohk. thanks. added him in review.
14:55:55	Sundar	jaypipes: Please let me know when you have some time to follow up from last week.
14:57:38	jaypipes	Sundar: I am here.
14:58:54	Sundar	jaypipes: I am trying to reconcile your views with what everybody else is saying. You wanted to see os-acc as a small library that works by itself. Whereas others don;t see a need for os-acc at all :) #link http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-11-20.log.html#t2018-11-20T17:47:21
15:00:09	jaypipes	Sundar: correct.
15:00:40	Sundar	jaypipes: Could I understand your motivation? Nova virt drivers will do the actual attachment for accelerators, as with networking. All device-specific actions should be in Cyborg.
15:00:45	Sundar	DO you agree?
15:00:49	efried	Sundar: It seems reasonable, if nova only needs to talk to the cyborg API, to nix os-acc.
15:01:10	jaypipes	Sundar: I was under the impression os-acc would function similarly to os-vif, where os-vif provides the data models that are used to understand what and how network interfaces are brought up on the host.
15:01:34	efried	Sundar: My impression of os-acc was that it would be the clearinghouse for platform- and virt-specific plugins to do discovery and attachment.
15:01:39	efried	yeah, what jaypipes said.
15:02:17	Sundar	jaypipes: Yes, that's how we started. As the discussion progressed, and the spec was reviewed, it became clear that most of the work would be done by Cyborg APIs.
15:02:36	jaypipes	Sundar: which I completely disagree with.
15:02:54	jaypipes	Sundar: I have continued to maintain I see very little use in a Cyborg REST API at the moment.
15:03:30	mriedem	gmann: yes https://review.openstack.org/#/c/604134/1/.zuul.yaml is a bad backport
15:03:54	jaypipes	Sundar: let me tell you why.
15:04:06	mriedem	gmann: the commit message in https://review.openstack.org/#/c/541474/ sounds like we don't need it in queens
15:04:18	mriedem	the queens comment in https://github.com/openstack/nova/blob/master/.zuul.yaml#L140 might be wrong
15:04:35	jaypipes	Sundar: focusing on the REST API in Cyborg right now means you are constrained by versioning in a way that just focusing on iterating a workable object/data model would not constrain you.
15:04:37	Sundar	jaypipes: Without Cyborg APIs, how would one initiate device configuration, whether it is for a GPU, FPGA, ...?
15:04:40	mriedem	gmann: https://review.openstack.org/#/c/396186/ isn't in queens
15:04:47	jaypipes	Sundar: IMHO, a REST API is just a giant distraction right now for Cyborg.
15:05:09	efried	jaypipes: The way I see it, we need a way to follow the thread of an ARQ from [set of resources and traits] to [actual accelerator instance plugged into a VM].
15:05:11	jaypipes	Sundar: what does Cyborg do "under the covers" in its drivers?
15:05:20	jaypipes	Sundar: *that* is what I think os-acc should be doing.
15:06:06	dansmith	bauzas: gonna circle back on https://review.openstack.org/#/c/599587 right?
15:06:17	efried	jaypipes: Nova is going to be driving that workflow, but cyborg needs to be the one to make some of those transitions (like, "I landed on a host; pick me a specific device and configure it") and needs to be made aware of the ones Nova makes (like, "I plugged accelerator X into VM Y").
15:06:27	gmann	mriedem: ok. then we can remove the nova-next from queen pipeline list also + that job comment fix. i observed it while backporting the nova v2 job.
15:06:31	Sundar	jaypipes: Are you saying that os-acc should have its own device-specific drivers and run the show by itself? Or that it should call into Cyborg drivers, without involving any REST API?
15:06:34	bauzas	dansmith: yup, I'm just reviewing it
15:06:35	efried	jaypipes: *some* kind of API seems like the appropriate way to do that.
15:06:40	dansmith	bauzas: awesome, thanks
15:06:57	jaypipes	Sundar: that is correct.
15:07:07	mriedem	gmann: yeah it's either that or backport the devstack and nova change
15:07:41	jaypipes	Sundar: I've said a number of times that I wish Cyborg would just accept that Nova is its sole consumer right now, stop working on some "stand-alone Cyborg" thing and just function like a Nova virt driver for right now. That way, you can iterate more quickly, actually get something that works (as opposed to just abstract, non-working things) and go from ther
15:08:08	gmann	mriedem: i can give backport try also if you think it is worth to run on queens.
15:09:07	mriedem	gmann: i backported the devstack change, you can backport https://review.openstack.org/#/c/513160/ if you want
15:09:10	mriedem	it has merge conflicts
15:09:21	mriedem	i'm guessing the nova-next/devstack testing just missed the queens GA
15:09:29	mriedem	but the feature itself is in nova in queens
15:09:33	mriedem	so it would probably be good to test it...
15:09:50	Sundar	jaypipes: There are are several use cases for accelerators without direct Nova involvement. For example, we may want to set up OVS offload in an accelerator in a host, but that doesn't involve assigning to a VM.
15:10:05	jaypipes	Sundar: there might be, yes. I'
15:10:28	jaypipes	m saying I don't care about those use cases and I feel they are a giant distraction from getting anything working in Nova/Cyborg at the moment.
15:11:23	gmann	mriedem: +1. will do tomorrow.
15:11:30	mriedem	gmann: thanks
15:11:31	sean-k-mooney	Sundar: "use cases for accelerators without direct Nova involvement" are by definition out side the scope of the nova/cyborge interaction sepc
15:11:42	efried	jaypipes: Are you suggesting maintaining ARQ data in nova databases and manipulating them via OVOs within the nova code?
15:12:07	jaypipes	Sundar: let me put this in the most direct way possible... I do not think it's appropriate to call a REST API to set up a local device on a host.
15:12:58	mriedem	sounds like you want a thing that's like PlacementDirect
15:13:07	mriedem	API interface is the same, but it doesn't go over http
15:13:31	Sundar	jaypipes: As efried said above, manipulating devices from a virt driver means the device data is in Nova db. Is that what you are advocating?
15:14:13	Sundar	sean-k-mooney: We were talking about stand-alone Cyborg
15:15:51	jaypipes	Sundar: I would rather just get the small amount of code that is Cyborg's accelerators/drivers/ module (https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/fpga/intel/driver.py), pull it into some library called "os-acc" and call it directly.
15:16:49	jaypipes	Sundar: especially since it's basically just shelling out to some unknown /usr/bin/fpgaconf program which I assume is some Intel-specific binary
15:17:48	jaypipes	Sundar: which is essentially what os-vif is, BTW... it just shells out to Linux binaries like "ip" or "ovsctl" etc.
15:18:00	jaypipes	Sundar: which is why I say I'd like an os-vif for accelerators...
15:21:03	Sundar	jaypipes: That means all the PCI details (#PFs, #VFs, etc.) and other data for programming devices etc. are all in Nova db.
15:21:29	jaypipes	Sundar: which is exactly where they already are.
15:21:44	jaypipes	Sundar: because Nova is the thing that owns compute node resources.
15:22:39	efried	jaypipes: Please tell me you're not suggesting using/augmenting the existing database schemata
15:23:05	Sundar	jaypipes: I thought there was a desire to pull all that complexity into a separate project. What do you see as the role for Cyborg in your model?
15:23:07	sean-k-mooney	efried: that is a diffent topic
15:23:14	sean-k-mooney	you could be we can do better
15:23:46	efried	sean-k-mooney: It is exactly the topic.
15:23:50	jaypipes	Sundar: on a sidenote, could you tell me where I can find the source code for fpgaconf? I can't seem to locate it..
15:24:14	jaypipes	efried: no, I'm not. I'm just saying that's where we *already* store this information.
15:24:41	efried	sean-k-mooney: We know we want the existing pci subsystem to diaf. Trying to retrofit it for cyborg purposes will just make it live on, like something from Walking Dead.
15:24:41	sean-k-mooney	efried: you can passthough gpugs and fpgas with nova pci pathough today
15:24:53	sean-k-mooney	efried: we just cant program fpgas
15:25:26	efried	Also, we know we want to separate eventually, so the tighter the integration with nova databases, the more painful that will be.
15:25:29	artom	sean-k-mooney, yo, check downstream IRC, I'd like to skip our meeting since very few are around
15:25:39	efried	As with placement, we should at the very least make it a separate database.
15:25:49	jaypipes	Sundar: there is definitely a desire to standardize and clean up the mess that is the PCI device management code (and CPU pinning, NUMA topology, etc) code in Nova. I have never had a desire to create a new REST service to manage this data, however.
15:26:05	efried	but cyborg is already a separate project, and already has existing use cases for operation and tracking/programming of devices independent of nova
15:26:11	Sundar	jaypipes: While OPAE SDK has been released i github, I am not sure that all tools like fpgaconf got open sourced. I'll check and get back.
15:26:14	efried	so why wouldn't we just put the new database there to begin with?
15:26:22	jaypipes	Sundar: thx
15:28:00	jaypipes	efried: perhaps there is. I'm trying to say that I think it's premature to do RESTful stuff versus cleaning up the device management and plugging/assignment code in nova.
15:29:24	jaypipes	efried: I'm straining to think of a use case where I'd want programmatic listing and showing of device details across all my compute infrastructure. Other than just knowing what devices are there and what resources they provide (which is already taken care of by the placement service), I'm wondering what the use is of a REST API over this data.
15:31:59	Sundar	jaypipes: if you were to apply that to networking, would you not want to see the details of the NICs, and manage their diversity in a structured way?
15:32:57	jaypipes	Sundar: if you're talking about capabilities of NICs or bandwidth of physnets on NICs, we already have that in the placement DB.
15:33:39	jangutter	Sundar: commenting as an engineer working for a NIC vendor, customers broadly fall into two categories: "Make everything look the same" and "handle this node specially".
15:34:35	jangutter	Sundar: it would be nice to be able to say "provide me with a networking resource capable of _x_", but broadly, most requests to us have been to make things more uniform, not less.

Earlier   Later