| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-28 | |||
| 08:36:37 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Change the default values of XXX_allocation_ratio https://review.openstack.org/602803 | |
| 08:36:37 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804 | |
| 09:22:20 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 09:23:40 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 10:09:08 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804 | |
| 10:33:33 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Add ratio online data migration when load compute node https://review.openstack.org/613499 | |
| 10:33:34 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995 | |
| 10:36:57 | noonedeadpunk | Hi everyone. | |
| 10:39:08 | noonedeadpunk | I've faced with a problem (not sure if it's a bug or not), when nova in Q generates config, which is not compatible with libvirt 4 (which is a default for ubuntu). So VM creation results in error "'serial' is deprecated, please use the corresponding option of '-device' instead" | |
| 10:41:40 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 10:42:49 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 11:33:04 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.openstack.org/580336 | |
| 11:39:44 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620571 | |
| 11:47:43 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620578 | |
| 11:53:26 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620579 | |
| 12:01:48 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/620571 | |
| 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. | |