| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 12:55:53 | alex_xu | efried: ok, you mean the shared RP case, right? we can file a bug for it | |
| 12:57:10 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: set/check if inventory change in tree https://review.openstack.org/470575 | |
| 12:57:56 | alex_xu | I should read the 'sweep this under the rug', not just panic on the single 'rug'. | |
| 13:00:21 | efried | alex_xu I can't find an equivalent Chinese idiom, but perhaps 掩饰 gets close. | |
| 13:00:23 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Rename add-zvm-driver spec https://review.openstack.org/512606 | |
| 13:02:45 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add memoize function using oslo.cache https://review.openstack.org/472773 | |
| 13:03:16 | alex_xu | efried: hehe, i get that | |
| 13:05:25 | efried | alex_xu Fixed that other docstring; cdent renamed the variable, just for you :) | |
| 13:06:40 | alex_xu | efried: cool, thanks | |
| 13:07:52 | alex_xu | efried: also leaved a question in https://review.openstack.org/#/c/510244/ | |
| 13:10:13 | alex_xu | ralonsoh: fyi first, I don't have +2 for the nova-spec :) | |
| 13:10:42 | ralonsoh | alex_xu: no problem! thanks for your time | |
| 13:12:19 | cdent | efried: the setUp in these compute manager related tests are … wow. Not the stuff you’ve added, but what was already there. | |
| 13:13:00 | efried | cdent I don't disagree. | |
| 13:13:08 | efried | I've got two more UTs to fix, btw. | |
| 13:13:12 | efried | But thanks for looking. | |
| 13:14:38 | cdent | efried: yeah, I know it’s not complete, I just went by because I wanted to understand the point of it all | |
| 13:15:15 | efried | cdent Hopefully the latest commit message makes it clear why we need this; let me know if not. | |
| 13:17:33 | cdent | yeah, it does | |
| 13:25:17 | efried | alex_xu Responded to that comment - let me know if you want to discuss. | |
| 13:25:35 | efried | alex_xu The code for looking stuff up in nested RPs - I'm not sure if that's part of Jay's series yet. | |
| 13:27:30 | alex_xu | efried: yea, I also want to ask the nested RP support for non-numbered request is implemented by which BP | |
| 13:27:52 | alex_xu | efried: I check the Jay's spec about nested RP, looks like that isn't included in the spec | |
| 13:28:17 | efried | alex_xu I remember talking about it - specifically about trait propagation - in some spec or other. | |
| 13:28:23 | efried | alex_xu Oh! It was *your* spec :) | |
| 13:28:39 | alex_xu | efried: for the question in your spec, is there any way we can try to find SRIOV_NET_VF and NET_EGRESS_BYTES_SEC from the same RPs for the non-numbered request? | |
| 13:28:53 | alex_xu | ok... | |
| 13:29:11 | alex_xu | sounds like we are missing one more spec? | |
| 13:29:48 | efried | alex_xu I don't see how that would work. Because then you would be ignoring the relationship between RPs in a tree. | |
| 13:29:51 | bauzas | sahid: there could be some regression in Pike for CPU pinning when you evacuate https://bugs.launchpad.net/nova/+bug/1723005 | |
| 13:29:52 | openstack | Launchpad bug 1723005 in OpenStack Compute (nova) "CPUPinningInvalid exception occurred when evacuate one instance repeatedly." [High,Confirmed] | |
| 13:30:15 | efried | alex_xu In other words, if you made it work that way, there would be all the "normal" cases that wouldn't yield any results. | |
| 13:30:35 | openstackgerrit | edan david proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/505613 | |
| 13:31:19 | alex_xu | efried: why | |
| 13:31:25 | openstackgerrit | Merged openstack/nova-specs master: Rename add-zvm-driver spec https://review.openstack.org/512606 | |
| 13:31:35 | sahid | bauzas: not sure we have supported that at some point | |
| 13:32:31 | efried | alex_xu Okay, can we agree that we would *not* want to get a candidate like { RP1: { SRIOV_NET_VF: 1 }, RP2: { NET_EGRESS_BW: 10000 } } ? | |
| 13:32:57 | bauzas | sahid: you mean evacuating an instance that was pinning a CPU ? | |
| 13:33:07 | bauzas | sahid: or any move ops ? | |
| 13:33:59 | alex_xu | efried: yes | |
| 13:34:34 | efried | alex_xu Then in order for that to work, you have to do your selection to make sure those inventories come from the *same* RP. | |
| 13:35:32 | efried | alex_xu So let's extend the model to include VCPU and MEMORY_MB. Those would be in the root RP. But the VF resources are still in the child RPs. | |
| 13:35:35 | alex_xu | efried: or to say try the best, if the RP doesn't have all resources, then looking for the child or shared | |
| 13:36:09 | sahid | bauzas: pinned instances... there were a patch serie pushed by nikola long time ago but never get merged unfortunatly | |
| 13:36:55 | bauzas | sahid: if you speak of live-migration claims, it's unrelated | |
| 13:36:57 | sahid | i think it never get merged because the work on-going with resource providers and placement :) | |
| 13:37:16 | efried | alex_xu Mm... that *could* work. | |
| 13:37:18 | bauzas | sahid: because we already claim on rebuilds | |
| 13:37:34 | openstackgerrit | Merged openstack/nova-specs master: Deprecate file injection https://review.openstack.org/509013 | |
| 13:38:12 | alex_xu | efried: and how the request with CPU and MEMORY_MB and SRIOV_NET_VF works? it try to the best? get CPU and MEMORY_MB from the root RP, and then try the child? | |
| 13:38:35 | sahid | bauzas: yes but that need to be checked whether we buil a new domain xml based on that new claim or not | |
| 13:38:44 | sahid | if it not so we o not support that | |
| 13:39:01 | alex_xu | that I feel no-one is talking about how the non-numbered request works for the nested RP... | |
| 13:39:09 | efried | alex_xu But if e.g. RP1 is exhausted of VFs and RP2 is exhausted of bandwidth, I think you would wind up giving me a candidate with { COMPUTE_RP: { VCPU, MEMORY_MB }, RP1 { NET_EGRESS_BW }, RP2 { SRIOV_NET_VF } } | |
| 13:39:41 | alex_xu | efried: for that case, we shouldn't return any condidates | |
| 13:40:06 | efried | alex_xu Shouldn't, I agree. But that's going to be tricky to code. | |
| 13:40:18 | alex_xu | so the logic is try the best on the same node or child node or shared node | |
| 13:40:22 | alex_xu | s/node/RP/ | |
| 13:40:34 | bauzas | sahid: so technically, we can't move or rebuild a pinned instance, I see | |
| 13:41:15 | efried | alex_xu If you think that through, though, I don't think you can get it to work in the general case. | |
| 13:41:41 | sahid | yes, but only if the pinning of domain xml is updated which was addressed in one of the patch from nikola | |
| 13:41:42 | openstackgerrit | Ildiko Vancsa proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777 | |
| 13:42:05 | alex_xu | efried: sorry, try the best on the same node, then child, then shared, I should use 'then' | |
| 13:42:06 | ildikov | johnthetubaguy: mriedem: new version of the multi-attach spec ^^ | |
| 13:42:06 | sahid | for cold you might have right, if we do build a new domain from scratch so we are OK | |
| 13:42:47 | efried | alex_xu Let's look at another scenario: the compute RP is empty (or let's say it has just the local DISK_GB resource). Then we have two NUMA nodes which each contain VCPU & MEMORY_MB resources. Then we also have two PF RPs which each contain VF and EGRESS_BW resources. | |
| 13:42:52 | ildikov | johnthetubaguy: mriedem: a question there is about delete_on_termination as there is one case where an exception gets raised when the volume couldn't be deleted | |
| 13:43:35 | ildikov | johnthetubaguy: mriedem: discussion about it is here: https://review.openstack.org/#/c/499777/4/specs/queens/approved/cinder-volume-multi-attach.rst | |
| 13:43:41 | bauzas | sahid: in other words, any move operation that is not regenerating the domain XML is not working if you have pinned instances, I see | |
| 13:43:59 | ildikov | johnthetubaguy: mriedem: please let me know what would be the preference on keeping this as an allowed action or disable it | |
| 13:44:04 | efried | alex_xu We've agreed you can't just look for everything in the same RP. So *either* [you're looking for all the resources in the same "branch"] *or* [you're allowing them to be spread out across all RPs in the tree]. | |
| 13:44:21 | ildikov | johnthetubaguy: mriedem: I would say keep what we agreed on earlier, but open to new suggestions | |
| 13:44:37 | sahid | yes, or you need to have on the destination node the same CPU topology and more of that have the pCPUs free | |
| 13:44:51 | efried | alex_xu In this scenario, I want to make sure my VCPU & MEMORY_MB come from the same RP; and my VF & BW come from the same RP. | |
| 13:45:02 | efried | (I'm assuming the PF doesn't belong to a NUMA node) | |
| 13:45:18 | mriedem | melwitt: jbernard: assuming this works https://review.openstack.org/512622 we'll need that to unblock nova changes in stable < pike | |
| 13:45:53 | dansmith | mriedem: melwitt: Is this known? http://logs.openstack.org/56/512456/1/check/legacy-tempest-dsvm-multinode-live-migration/5c3869e/job-output.txt.gz#_2017-10-17_01_30_14_509196 | |
| 13:46:01 | dansmith | py3 rados packages missing on pike | |
| 13:46:05 | openstackgerrit | Yushiro FURUKAWA proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487 | |
| 13:46:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.openstack.org/512552 | |
| 13:46:11 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1724172 in the functional test env https://review.openstack.org/512553 | |
| 13:46:12 | openstack | bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,New] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 13:46:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 13:46:18 | mriedem | dansmith: see ^ | |
| 13:46:19 | mriedem | :) | |
| 13:46:30 | dansmith | mriedem: you said < pike | |
| 13:46:44 | mriedem | i was told python3 packages were in the pike UCA | |
| 13:46:46 | mriedem | maybe they arent | |
| 13:46:56 | mriedem | dansmith: same problem though | |
| 13:47:02 | dansmith | okay | |
| 13:47:11 | mriedem | https://review.openstack.org/#/c/512622/ should fix it | |
| 13:48:17 | alex_xu | efried: yes, for that case, we defintely need the numbered request. I think the case we only request VCPU & MEMORY_MB and VF, this case whether can work for non-numbered request | |
| 13:51:14 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 13:51:17 | efried | alex_xu But you're right - it sounds like we need to write up some scenarios for the non-numbered group. Not sure where it would be appropriate to do that. Perhaps a delta to your traits-in-allocations spec? | |
| 13:53:12 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add attachment_get to refresh_connection_info https://review.openstack.org/512626 | |
| 13:54:39 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 13:54:51 | alex_xu | efried: yea, i'm not sure it should be in the trait spec, but I feel it should be at somewhere | |
| 13:56:07 | efried | alex_xu I covered some of it in passing in the granular request syntax spec, but dansmith will eviscerate me if I put more words in that one. | |
| 13:56:25 | dansmith | efried: not only that, | |
| 13:56:35 | dansmith | efried: but I'm reserving my +2 until you remove some :) | |