| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-06 | |||
| 11:30:37 | openstackgerrit | sahid proposed openstack/nova master: compute: reset instance events https://review.openstack.org/420026 | |
| 11:57:32 | openstackgerrit | Sergey Nikitin proposed openstack/nova-specs master: PCI NUMA Policies https://review.openstack.org/361140 | |
| 12:07:57 | mamandle | mriedem: after commit 1b2f3c7bb25667527e7e1d2afd84d5d5533e7751, the evacuated instance cleanup is failing in delete_allocation_for_evacuated_instance complaining that the compute node key is not present in resource_tracker compute_nodes . I looked a bit into it and it | |
| 12:09:33 | mamandle | it looks like we need to ensure that resources have initialized (via _update_available_resource) before this is called? | |
| 12:39:48 | openstackgerrit | Merged openstack/nova master: Hyper-V: Perform proper cleanup after cold migration https://review.openstack.org/486955 | |
| 12:42:42 | openstackgerrit | Merged openstack/nova master: Add release note for requiring shred 8.22 or above. https://review.openstack.org/501022 | |
| 12:43:15 | openstackgerrit | Merged openstack/nova master: Update doc to indicate nova-network deprecated https://review.openstack.org/500654 | |
| 12:43:46 | openstackgerrit | Merged openstack/nova master: Replace http with https for doc links in nova https://review.openstack.org/500693 | |
| 12:46:31 | stephenfin | sdague: Now that Queens is open, could you take another look at this patch? https://review.openstack.org/#/c/466799/ | |
| 12:46:50 | trinath | Hi, While compiling qemu 2.6 from source, "./configure --target-list=aarch64-softmmu --enable-kvm --enable-vhost-net --enable-vnc --enable-curses " , I get the error " ERROR: "cc" cannot build an executable (is your linker broken?)". | |
| 12:46:59 | trinath | please help me resolve this issue. | |
| 12:55:23 | sdague | stephenfin: +2 | |
| 12:55:41 | stephenfin | thank you :) | |
| 12:56:13 | stephenfin | trinath: Totally wrong channel, buddy. You want #qemu or Google | |
| 13:01:45 | alex_xu | nova api meeting is running at #openstack-meeting-4 | |
| 13:10:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: reno: note that custom resources are not supported https://review.openstack.org/501252 | |
| 13:13:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/pike: reno: note that custom resources are not supported https://review.openstack.org/500521 | |
| 13:15:38 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Hyper-V: Perform proper cleanup after cold migration https://review.openstack.org/501254 | |
| 13:25:27 | openstackgerrit | Merged openstack/nova master: Enhance doc for nova services https://review.openstack.org/499536 | |
| 13:26:23 | evrardjp | hello guys, sorry for my glitch in your meeting. | |
| 13:27:07 | alex_xu | jaypipes: mriedem bauzas, a team in the intel is working on upstream CIT https://github.com/opencit/opencit-openstack-extensions/blob/v3.2/nova/scheduler/asset_tag_filter.py, I think it is a upgrade version of trustedfilter. I know we have some problem with the trustedfilter, performance, depend on external service. I'm thinking is it ok using traits API instead of the filter implementation, is a | |
| 13:27:09 | alex_xu | right direction? | |
| 13:27:29 | bauzas | alex_xu: I saw your proposal for the PTG | |
| 13:27:45 | bauzas | alex_xu: MHO is that I think we don't need to see a TrustedFilter | |
| 13:27:45 | evrardjp | I was in the wrong chan. | |
| 13:27:54 | bauzas | I mean, in the tree | |
| 13:27:59 | alex_xu | bauzas: yea, the team reaches to me recently, try to figure out the things | |
| 13:28:25 | alex_xu | bauzas: why | |
| 13:28:27 | bauzas | alex_xu: but in case operators or deployers want to use a custom scheduler filter for that, I'm totally fine | |
| 13:28:40 | openstackgerrit | Merged openstack/nova master: Fix ValueError if invalid max_rows passed to db purge https://review.openstack.org/500771 | |
| 13:28:41 | bauzas | alex_xu: for the exact reason you mentioned | |
| 13:28:50 | bauzas | reasons* even | |
| 13:29:13 | openstackgerrit | Merged openstack/nova master: Mark LXC as missing for swap volume support https://review.openstack.org/482216 | |
| 13:29:15 | alex_xu | bauzas: ok, is it ok for external agent report trusted info as traits to the placement service directly? it sounds like out of nova totatly also | |
| 13:29:29 | gmann__ | mriedem: query schema BP is good without microversion. i updated info in BP - https://blueprints.launchpad.net/nova/+spec/json-schema-validation-for-query-param | |
| 13:29:57 | bauzas | alex_xu: also, the TrustedFilter is deprecated and will be removed by Queens | |
| 13:30:00 | openstackgerrit | Merged openstack/nova master: explain payload inheritance in notification devref https://review.openstack.org/453667 | |
| 13:30:15 | bauzas | alex_xu: we can surely discuss that in the PTG | |
| 13:30:19 | alex_xu | bauzas: yea, i know | |
| 13:30:35 | alex_xu | bauzas: yea, that will be great, try to figure out a way we liked | |
| 13:30:42 | bauzas | alex_xu: if things need to be proposed to Nova for helping operators to have that feature, that's fine by me | |
| 13:31:25 | alex_xu | bauzas: ok, probably I need to talk with that team what is the key thing needs to integrate with nova | |
| 13:31:26 | bauzas | alex_xu: I just want to make sure we don't create an in-tree module that would need a 3rd party system that is not tested in the gate :) | |
| 13:31:56 | jaypipes | alex_xu: who is using this openCIT technology? | |
| 13:32:01 | bauzas | and again, removing TrustedFilter from upstream doesn't mean operators or deployers could not use it | |
| 13:32:04 | alex_xu | bauzas: ok :) | |
| 13:32:28 | alex_xu | jaypipes: I don't know :) | |
| 13:32:37 | bauzas | well, I know that :) | |
| 13:32:44 | bauzas | Intel customers, I'd say | |
| 13:32:57 | alex_xu | bauzas: better answer than me :) | |
| 13:33:14 | bauzas | honestly, the OAT feature is nice | |
| 13:33:34 | bauzas | that's how it's implemented in Nova that is bad to me | |
| 13:33:48 | bauzas | s/bad/wrong | |
| 13:34:01 | jaypipes | bauzas: OAT? | |
| 13:34:14 | alex_xu | bauzas: yea, so I'm thinking we have placement API, we can have something report to the placement API direclty out of Nova | |
| 13:34:37 | bauzas | jaypipes: Open Attestation Service or something like that | |
| 13:35:19 | bauzas | jaypipes: that's basically some agent running on computes that verify whether the compute kernel is not modified | |
| 13:35:37 | bauzas | s/modified/tainted I'd say | |
| 13:35:43 | jaypipes | alex_xu: sure, you can do that. but then aren't we opening up the "trust" attack vector to anyone who can write a trait for a resource provider? ;) | |
| 13:36:08 | bauzas | jaypipes: that necessarly supposes that the Placement service can't be tainted | |
| 13:36:15 | jaypipes | bauzas: zactly ;) | |
| 13:36:27 | bauzas | that's an operator problem honestly :) | |
| 13:36:42 | bauzas | if they want to go that direction, fine by me | |
| 13:37:20 | alex_xu | jaypipes: so you mean the only right way is access the OAT server in each scheduling... | |
| 13:37:20 | bauzas | jaypipes: OpenAttestation | |
| 13:37:22 | bauzas | oop | |
| 13:37:28 | bauzas | jaypipes: https://wiki.openstack.org/wiki/OpenAttestation | |
| 13:39:08 | bauzas | oh interesting | |
| 13:39:17 | bauzas | OAT has been superseded by OpenCIT | |
| 13:39:18 | mriedem | gmann: ok approved | |
| 13:39:20 | mriedem | thanks for following up | |
| 13:40:00 | mriedem | bauzas: jaypipes: i'm +2 on dan's migration allocations spec if one of you wants to take a gander https://review.openstack.org/#/c/498510/ | |
| 13:40:07 | bauzas | AFAICS, instead of querying a manifest, the compute agent sends a report to the attestation server | |
| 13:40:14 | bauzas | mriedem: for sure | |
| 13:40:26 | jaypipes | alex_xu: no, I'm saying that the "trust" part of all of this stuff would be dependent on how much you trust the caller to the placement API that is setting traits. Obviously, the Placement API doesn't verify callers or attest to their content. | |
| 13:40:27 | bauzas | my review bag is pretty empty those days | |
| 13:41:13 | bauzas | jaypipes: well, the placement API accepts credentials, so the real problem is whether they accept Keystone tokens as safe enough or not | |
| 13:41:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rename cellsv2_layout -> cellsv2-layout https://review.openstack.org/498821 | |
| 13:41:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP! doc: Add contents page https://review.openstack.org/498820 | |
| 13:41:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Cleanup of existing index pages https://review.openstack.org/498819 | |
| 13:41:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add configuration index page https://review.openstack.org/498818 | |
| 13:41:27 | jaypipes | bauzas: right... | |
| 13:41:27 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add user index page https://review.openstack.org/498817 | |
| 13:41:31 | bauzas | jaypipes: but again, it's not my problem :) | |
| 13:41:33 | stephenfin | ralonsoh: You about. Question about binding profiles | |
| 13:41:47 | jaypipes | damn you stephenfin :) was just about to +W the bottom of that. | |
| 13:42:50 | mriedem | bauzas: if your review bag is empty, this bug fix and the changes below it are needed for pike https://review.openstack.org/#/c/499878/ | |
| 13:42:56 | mriedem | once that's done and backports are merged i'll cut a release | |
| 13:43:12 | alex_xu | jaypipes: yea, i see that, so we don't have that problem for the existed trusted filter | |
| 13:43:13 | stephenfin | jaypipes: You still can - it was a rebase to move the dodgy contents patch to the end | |
| 13:43:13 | bauzas | mriedem: I'm already on https://review.openstack.org/#/q/topic:bp/request-spec-use-by-compute | |
| 13:43:15 | stephenfin | :) | |
| 13:43:35 | bauzas | jaypipes: mriedem: dansmith: I'm gonna ask a question for https://review.openstack.org/#/c/498510/5/specs/queens/approved/migration-allocations.rst | |
| 13:43:37 | mriedem | bauzas: cool - gerrit somehow auto-changed my topic branch which was annoying there | |
| 13:44:37 | bauzas | jaypipes: mriedem: dansmith: if we consider that allocations need to be set/corrected by the conductor for migrations (and we already do that), could we consider having a single boot request to have the simple allocation claim to be also done in the conductor ? | |
| 13:44:48 | bauzas | I know it has been a long conversation previously | |
| 13:45:00 | bauzas | and I don't want to open wounds | |
| 13:45:20 | bauzas | but I just want to consider how that could help us having a single driver using Placement | |
| 13:45:34 | alex_xu | jaypipes: is it another layer problem, since you can attach traits to the resource provider, basically you already get the admin user in the system... | |
| 13:46:27 | jaypipes | alex_xu: I'm not saying it's a problem, per se. I'm just saying that the OpenCTI team should be aware of the fact that communication with the placement API itself is not attested. | |