| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-26 | |||
| 15:10:34 | jroll | nice, thanks matt | |
| 15:32:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Clarify wording in listing instance actions for deleted instances https://review.openstack.org/548055 | |
| 15:42:21 | openstackgerrit | Piotr Bielak proposed openstack/nova-specs master: Specs for improved Nova scheduler logger. https://review.openstack.org/548056 | |
| 15:44:33 | openstackgerrit | Piotr Bielak proposed openstack/nova-specs master: Specs for improved Nova scheduler logger. https://review.openstack.org/548056 | |
| 15:45:44 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Update noVNC deployment docs to mention non-US keymap fix in 1.0.0 https://review.openstack.org/548057 | |
| 15:45:59 | openstackgerrit | Claudiu Belu proposed openstack/nova master: conductor: add live_resize task https://review.openstack.org/248579 | |
| 15:45:59 | openstackgerrit | Claudiu Belu proposed openstack/nova master: compute: Adds instance live-resize https://review.openstack.org/248581 | |
| 15:46:00 | openstackgerrit | Claudiu Belu proposed openstack/nova master: API: Adds instance live-resize https://review.openstack.org/184584 | |
| 16:30:12 | mriedem | dansmith: http://162.253.55.2/compute/v2.1 yeah? | |
| 16:30:22 | mriedem | so what are we saying? http://162.253.55.2/compute/v2.1/healthcheck? | |
| 16:30:32 | dansmith | mriedem: no, /compute/healthcheck I think | |
| 16:30:40 | mriedem | so http://162.253.55.2/compute/healthcheck/v2.1 | |
| 16:30:44 | dansmith | I think it _has_ to be before the versioned space | |
| 16:30:51 | dansmith | no /v2.1 I think | |
| 16:30:56 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813 | |
| 16:32:19 | efried | This should be a mordred question. I think he has strong opinions on whether the 'v2.1' should be present in the URI at all, ever (even for discovry). | |
| 17:19:10 | openstackgerrit | Merged openstack/nova-specs master: Update Provider Tree https://review.openstack.org/540111 | |
| 17:35:39 | openstackgerrit | Merged openstack/nova stable/ocata: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/519636 | |
| 17:59:18 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap volume attempts with encrypted volumes https://review.openstack.org/543569 | |
| 21:00:11 | openstackgerrit | Merged openstack/nova master: Clarify wording in listing instance actions for deleted instances https://review.openstack.org/548055 | |
| 21:00:46 | openstackgerrit | Merged openstack/nova master: Clarify update_provider_tree docstring https://review.openstack.org/545495 | |
| 22:18:11 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034 | |
| 23:13:02 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Do not normalize allocation_ratios https://review.openstack.org/532924 | |
| #openstack-nova - 2018-02-27 | |||
| 03:33:58 | vivsoni | mriedem: hi | |
| 03:34:34 | vivsoni | mriedem: related to https://blueprints.launchpad.net/cinder/+spec/implement-force-detach-for-safe-cleanup | |
| 03:34:50 | vivsoni | force_detach | |
| 03:36:34 | itlinux | hello nova team.. I wonder what's the new command to add a floating ip address to a port.. I used to have this with neutron but since things changed I will ask first here.. | |
| 06:28:34 | openstackgerrit | Michael Still proposed openstack/nova master: Move makefs to privsep https://review.openstack.org/527510 | |
| 06:28:34 | openstackgerrit | Michael Still proposed openstack/nova master: Convert users of tune2fs to privsep. https://review.openstack.org/519484 | |
| 06:40:10 | openstackgerrit | sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522 | |
| 07:11:19 | openstackgerrit | sahid proposed openstack/nova-specs master: update: introducing isolate emulthreads on host https://review.openstack.org/511188 | |
| 07:11:43 | openstackgerrit | sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605 | |
| 08:20:57 | openstackgerrit | yuanyue proposed openstack/nova master: Whether to use config drive depends on instance.configdrive https://review.openstack.org/485930 | |
| 09:20:54 | mriedem | we should be ok to recheck ocata and pike patches now | |
| 09:21:42 | alex_xu | bauzas: yesterday, I listen you talk about the late bind with the accelerator with cyborg, but I didn't get the point, what the benefit of that, would you remind me that | |
| 09:31:55 | mriedem | dansmith: i'm guessing you want to get this in pike https://review.openstack.org/#/c/542748/ | |
| 09:32:32 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Use nova.db.api directly https://review.openstack.org/543262 | |
| 09:32:33 | openstackgerrit | Chris Dent proposed openstack/nova master: Move db MAX constants to own file https://review.openstack.org/543469 | |
| 09:34:02 | bauzas | alex_xu: so I had a long chat with the Cyborg folks | |
| 09:34:21 | bauzas | alex_xu: tl;dr: they want to dynamically program FPGAs | |
| 09:34:42 | bauzas | alex_xu: but they also focus on other accelerators discovery | |
| 09:36:06 | bauzas | so, the problem they had was that they wanted to dynamically modify the FPGAs if Placement was saying "no sorry" | |
| 09:36:45 | alex_xu | bauzas: ah, that is wasting, I guess that is the point of late binding | |
| 09:37:04 | bauzas | instead, I proposed that Cyborg would keep track of the accelerated resources, incl. reprogramming if necessary, and Nova should only care about making sure that an instance that asks for that resource will get it | |
| 09:37:52 | bauzas | how the binding would be done is for the moment undefined | |
| 09:39:30 | alex_xu | bauzas: got it | |
| 09:40:37 | alex_xu | bauzas: the cyborg create accelerator, then return uuid, then nova boot instance with that accelerator uuid, and nova will get 'resource class' and 'trait' by that uuid from the cyborg API, then pass to the placement, that is the process? | |
| 09:40:48 | alex_xu | first part of the process | |
| 09:42:24 | bauzas | alex_xu: that's basically the workflow I see, but the last steps are a bit unclear to me | |
| 09:42:26 | efried | alex_xu: The way I understood it, cyborg will actually go as far as creating the allocation in placement. | |
| 09:42:52 | efried | ...unless bauzas your subsequent discussions yielded different revelations. | |
| 09:43:14 | gibi | alex_xu: the flow you described is pretty similar to what I would imagined for neutron ports with bandwidth resources | |
| 09:43:48 | alex_xu | efried: I guess so, bauzas may proposal another one, since I join cyborg session very late, and hear that | |
| 09:44:09 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: experiment with setting placement error codes https://review.openstack.org/546177 | |
| 09:44:10 | gibi | efried: if nova get back allocation candidates from placement including the accelerator then nova can create the allocation easily in placement for the accelerator as well | |
| 09:45:11 | alex_xu | gibi: yea, I think I get that impression from the bindwidth spec. Then I try to think about how cyborg tell nova which resource request to | |
| 09:45:13 | efried | gibi: That would be true, BUT I'm not certain this workflow involves assigning the accelerator at spawn time. I think we were only talking about post-deploy attach. | |
| 09:46:34 | alex_xu | efried: if cyborg create allocation, that will be a lot of race? | |
| 09:46:55 | efried | alex_xu: Not if cyborg is the Source Of Truth for managing the accelerator resource. | |
| 09:47:18 | gibi | alex_xu, efried: I if the scenario is post-deploy attach then I can accept that cyborg creates the allocation as in this case no need for asking for allocation candidates | |
| 09:48:03 | efried | gibi: Maybe. That would be up to cyborg and how they want to manage the RPs. | |
| 09:48:19 | efried | gibi: But Nova wouldn't, that's true. | |
| 09:49:04 | gibi | efried: do you mean a compute host might have more than one accelearator and cyborg want to select from that pool during post-deploy attach? | |
| 09:49:45 | efried | gibi: For sure. | |
| 09:49:46 | gibi | efried: yes, if there is cyborg calls allocation candidate API then cyborg can create the allocation too | |
| 09:50:24 | efried | gibi: Especially if we're talking about "regions" or whatever the VF equivalent is for FPGA. | |
| 09:51:16 | efried | gibi: And maybe cyborg wants to precreate those. Or maybe not. | |
| 09:51:42 | efried | gibi: But surely there could be more than one FPGA on the system in any case. | |
| 09:51:45 | alex_xu | gibi: sorry, what is post-deploy attach? | |
| 09:51:57 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform live_migration.post.dest notifications https://review.openstack.org/469784 | |
| 09:51:58 | efried | gibi: And IIUC, cyborg wants to manage not just FPGAs but other accelerators too. | |
| 09:52:11 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform live_migration.post.dest notifications https://review.openstack.org/469784 | |
| 09:52:31 | efried | alex_xu: Meaning nova does spawn with CPU/Mem/disk, and then after that's finished and the instance is already created, cyborg comes along and attaches the FPGA | |
| 09:53:23 | gibi | alex_xu: I think about it like adding volumes to an existing VMs | |
| 09:53:43 | efried | ^ | |
| 09:53:52 | efried | or attach_interface() | |
| 09:54:03 | alex_xu | efried: gibi, got it | |
| 09:54:05 | efried | 'cept not done by nova :) So gibi's example is much better :) | |
| 09:54:32 | alex_xu | so the cyborg calling the allocation candidates API to get a accelerator from the pool of the host? | |
| 09:54:39 | gibi | efried: thanks, I think I got it. post-deploy sounds like an easy shortcut for not getting tangled into the nova boot process | |
| 09:54:46 | alex_xu | since the instance already boot up on specific host | |
| 09:54:48 | efried | gibi: ++ | |
| 09:55:26 | efried | alex_xu: Yes. TBH, I'm not completely sure how one would call GET /allocation_candidates in such a way that it restricts to a certain host. | |
| 09:55:57 | alex_xu | efried: the we have parameter like in_tree? | |
| 09:55:59 | gibi | efried: it might be part of the 'anchor a request' discussion | |
| 09:56:04 | efried | alex_xu: Just so. | |
| 09:56:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Stop using mox in virt/xenapi/image/test_vdi_through_dev.py https://review.openstack.org/342682 | |
| 09:56:37 | efried | alex_xu: It depends to some extent on how the accelerators are modeled. If they're included in the compute node's provider tree, then yes, ?in_tree=<compute_uuid> on GET /allocation_candidates would be very appropriate. | |
| 09:57:18 | alex_xu | efried: yea | |
| 09:57:33 | efried | alex_xu: And/or if the accelerator is made part of an aggregate (not sure if that makes sense ever, but it extends to the more general model for e.g. bandwidth providers) then member_of | |
| 09:57:47 | efried | The latter is a Rocky bp. The former is not (yet). | |
| 09:58:42 | Kevin_Zheng | Any idea how Nova can consume resource reported by cyborg? | |
| 09:59:20 | alex_xu | efried: I didn't get the accelerator is made part of an aggregate. The aggregate in Nova? | |
| 09:59:51 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049 | |
| 09:59:52 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 09:59:52 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 10:00:05 | alex_xu | Kevin_Zheng: depends on the direction we go I guess, with bauzas way, it can be done by cyborg API to return some resource class and traits. With the post-deploy attach, that is cyborg own thing | |
| 10:00:10 | bauzas | folks, I'm in the Scientifig WG room so I can't follow the convo | |
| 10:00:21 | efried | alex_xu: It probably doesn't make sense for accelerators to be modeled as true sharing providers. | |
| 10:00:23 | alex_xu | bauzas: no worries | |