| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-30 | |||
| 09:38:31 | sean-k-mooney | cool thanks for taking a look :) | |
| 09:39:48 | johnthetubaguy | no worries | |
| 09:59:22 | openstackgerrit | Hamdy Khader proposed openstack/os-vif master: OVS DPDK port representors support https://review.opendev.org/658786 | |
| 10:08:49 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-lvm: Disable [validation]/run_validation in tempest.conf https://review.opendev.org/662176 | |
| 10:13:20 | openstackgerrit | Merged openstack/nova stable/queens: Delete allocations even if _confirm_resize raises https://review.opendev.org/652153 | |
| 10:18:21 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: docs: Don't version links to reno docs https://review.opendev.org/662178 | |
| 10:41:25 | openstackgerrit | Adam Spiers proposed openstack/nova master: WIP: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680 | |
| 10:46:04 | openstackgerrit | Adam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class https://review.opendev.org/662105 | |
| 10:49:24 | openstackgerrit | Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334 | |
| 11:02:19 | alex_xu | sean-k-mooney: good morning, hope you can take a look at this https://review.opendev.org/#/c/601596/ if you are interesting. we update according the PTG discussion | |
| 11:08:53 | sean-k-mooney | sure ill take a look | |
| 11:09:00 | johnthetubaguy | alex_xu: I keep meaning to re-review that too | |
| 11:09:21 | sean-k-mooney | ill be submiting a spec for stactic CAT today or tommorow if your interested too | |
| 11:10:38 | sean-k-mooney | alex_xu: well assumeing we have capasity to work on it this cycle which is still TBD but im hoping to answer that question today | |
| 11:11:20 | alex_xu | johnthetubaguy: sean-k-mooney thanks! | |
| 11:20:36 | gibi | efried: could you check https://review.opendev.org/#/c/652608/ mriedem already happy with it | |
| 11:23:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/stein: cleanup evacuated instances not on hypervisor https://review.opendev.org/662189 | |
| 11:34:43 | alex_xu | sean-k-mooney: yea, i'm interesting in review the cat spec, I will ask someone from my team review it also | |
| 11:37:26 | sean-k-mooney | alex_xu: the draft is here https://etherpad.openstack.org/p/libvirt-static-cache-and-memory-allocation but its best to keep most of the review for gerrit | |
| 11:38:12 | sean-k-mooney | i still have some todos and self notes to clean up but its mostly complete | |
| 11:38:13 | alex_xu | sean-k-mooney: nice, yea, will waiting for the gerrit | |
| 11:58:51 | openstackgerrit | Hamdy Khader proposed openstack/os-vif master: OVS DPDK port representors support https://review.opendev.org/658786 | |
| 12:17:34 | openstackgerrit | Lee Yarwood proposed openstack/nova master: block_device: Optionally recreate attachments when refreshing connection_info https://review.opendev.org/579004 | |
| 12:55:36 | efried | gibi: reading... | |
| 12:58:09 | efried | gibi: This second use case... | |
| 12:59:07 | efried | So if I had a pre-Stein instance with bandwidth request, it didn't have any bandwidth allocated in placement. Once this is implemented, I can fix up that instance, giving it appropriate allocations, by migrating it. | |
| 12:59:09 | efried | do I have that right? | |
| 13:06:13 | sean-k-mooney | presumable a rebuild could fix it too? | |
| 13:06:41 | sean-k-mooney | but a migration or resize would be the more general case | |
| 13:07:28 | efried | sean-k-mooney: This spec gel for you? | |
| 13:07:34 | efried | https://review.opendev.org/#/c/652608/ | |
| 13:07:46 | efried | you had some earlier reviews, but no votes | |
| 13:08:12 | sean-k-mooney | i kind of lost track of it. but ill review it now | |
| 13:08:21 | sean-k-mooney | at this point its proably fine | |
| 13:09:28 | efried | thanks | |
| 13:09:33 | gibi | efried: yes, migration will heal the allocation on the target host | |
| 13:09:41 | efried | thanks | |
| 13:10:01 | gibi | efried: sometimes there is no way to heal the allocation locally | |
| 13:10:32 | efried | The spec looks fine to me, though I only superficially understand some of the mechanics involved, so I'll wait for sean-k-mooney's nod, then I'll approve. | |
| 13:10:36 | gibi | efried: e.g. resource is overallocated as there was no nova support to keep it in sync | |
| 13:10:48 | efried | right, that makes sense. So the CLI will fail? | |
| 13:11:11 | gibi | efried: yes the heal_allocation CLI could fail due to overallocation | |
| 13:11:31 | gibi | as placement would reject the new allocation being created | |
| 13:11:43 | efried | yup, I get it. | |
| 13:12:15 | efried | And the overallocation was possible because nobody anywhere was tracking bw quantities | |
| 13:12:21 | shilpasd | efried: Hi, need discussion regarding 'forbidden aggregate specs' | |
| 13:12:26 | openstackgerrit | Merged openstack/nova stable/rocky: Fix retry of instance_update_and_get_original https://review.opendev.org/659318 | |
| 13:12:31 | efried | shilpasd: Sure, what's up? | |
| 13:12:35 | shilpasd | here at https://review.opendev.org/#/c/609960/8/specs/train/approved/placement-req-filter-forbidden-aggregates.rst@203 | |
| 13:12:37 | efried | shilpasd: Are you implementing it? | |
| 13:12:49 | shilpasd | yes | |
| 13:12:50 | gibi | efried: yes, there was no resource tracking | |
| 13:13:33 | shilpasd | efried: We have added code to sync traits set on aggregates for command "nova-manage placement sync_aggregates". | |
| 13:14:24 | efried | okay | |
| 13:15:06 | shilpasd | efried: further observed that 'syncing of traits set on aggregate is required for the other scenarios' like aggregate-create/delete/aggregate-remove-host/aggregate-set-metadata | |
| 13:15:18 | efried | yes, that makes sense to me. | |
| 13:15:52 | efried | though I'm not sure what we should do on delete or remove-host ... | |
| 13:16:52 | efried | perhaps we need a --flush-traits option of some sort, so the admin can choose. | |
| 13:17:09 | shilpasd | efried: for delete, will remove entry from placement.placement_aggregates and for remove-host will remove host association from aggragte | |
| 13:17:43 | efried | right, but the question is whether you should remove the aggregate's listed traits from the compute node resource providers in that aggregate | |
| 13:18:11 | efried | answer is probably: "it depends" :\ | |
| 13:18:45 | sean-k-mooney | efried: gibi three minor nits but yep that looks good to me | |
| 13:19:33 | efried | shilpasd: This would probably be a good topic for the ML. | |
| 13:19:54 | efried | gibi: I +2ed. The spelling nits probably aren't worth fixing, want me to merge? | |
| 13:21:17 | sean-k-mooney | i would eihter fix them and fast approve or just merge it as the content is correct modulo a few typos | |
| 13:22:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add heal_instance_mappings command https://review.opendev.org/655908 | |
| 13:22:50 | gibi | efried: merge it please | |
| 13:22:58 | gibi | thanks | |
| 13:23:06 | efried | gibi: done | |
| 13:23:14 | gibi | awesome | |
| 13:23:26 | efried | shilpasd: I suppose another option is to namespace the traits to be used for this feature. | |
| 13:24:46 | efried | shilpasd: e.g. if trait name contains '_AGGREGATE_ISOLATION_', automatically remove it when the agg is deleted or the host is removed. (Unless of course the host belongs to *another* aggregate which still has that trait...) | |
| 13:26:13 | efried | gibi: assume this is for train, yah? | |
| 13:26:23 | efried | (gibi: I'm doing the bp paperwork) | |
| 13:26:24 | gibi | efried: yes, it is for train | |
| 13:26:34 | efried | k | |
| 13:26:56 | gibi | I have couple of patches up already but more work is needed there which i will do in the coming days weeks | |
| 13:29:07 | efried | gibi: are the patches tracked against this bp? The "Implementation" is not showing as started. | |
| 13:29:25 | gibi | efried: I guess the bp rename did not helped | |
| 13:29:25 | shilpasd | efried: aggregate can have any trait and that we need to be sync with placement, irrespective of namespace, right? | |
| 13:29:30 | gibi | efried: let me fix it | |
| 13:29:39 | efried | (I could go look, but I'm being lazy, aka doing a bunch of other things at the same time) | |
| 13:30:08 | efried | shilpasd: When you create an aggregate or add a host, I would say yes, you should add all the traits. | |
| 13:30:20 | efried | shilpasd: I'm just trying to come up with a way to handle *deletion*. | |
| 13:30:33 | shilpasd | efried: understood, okay | |
| 13:30:53 | efried | shilpasd: For example, if you're creating an aggregate to isolate your hosts that have HW_CPU_X86_AVX, it makes zero sense to remove that trait if you destroy that aggregate. | |
| 13:30:53 | gibi | efried: I guess the implementation status will be updated if I push a new patch up targeting the renamed bp | |
| 13:31:10 | efried | gibi: yeah, it's totally no big deal, I really don't care, just happened to notice. | |
| 13:31:14 | gibi | efried: but the patches are here https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports+(status:open+OR+status:merged) | |
| 13:31:19 | gibi | efried: ack | |
| 13:31:34 | efried | shilpasd: And in fact that trait would be reasserted on the host the next time the periodics run | |
| 13:32:14 | efried | shilpasd: ...but that is definitely not a behavior we should rely on to "heal" such traits. | |
| 13:33:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change InstanceFaultRollback handling in _error_out_instance_on_exception https://review.opendev.org/633212 | |
| 13:33:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Raise InstanceFaultRollback for UnableToMigrateToSelf from _prep_resize https://review.opendev.org/633227 | |
| 13:35:17 | shilpasd | efried: ML is good suggestion to brain storm this, will generate the same, thanks | |
| 13:35:42 | openstackgerrit | Merged openstack/nova-specs master: Server move operations with ports having resource request https://review.opendev.org/652608 | |
| 13:36:10 | efried | shilpasd: Cool. To summarize the alternatives we've come up with so far, on delete/remove type operations, we could: | |
| 13:36:10 | efried | - Leave all traits alone. If they need to be removed, it would have to be manually via a separate step. | |
| 13:36:10 | efried | - Support a new option so the caller can dictate whether the operation should remove the traits. (This is all-or-none.) | |
| 13:36:10 | efried | - Define a "namespace" - a trait substring - and remove only traits in that namespace. | |