| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 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 | sahid | for cold you might have right, if we do build a new domain from scratch so we are OK | |
| 13:42:06 | ildikov | johnthetubaguy: mriedem: new version of the multi-attach spec ^^ | |
| 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 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 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: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 :) | |
| 13:56:49 | efried | vay, really? Sigh, okay. | |
| 13:57:14 | efried | I read "just a tip" as "do better next time" | |
| 13:57:46 | dansmith | efried: the two use cases you call out and then say are out of scope really need to go, IMHO | |
| 13:58:00 | dansmith | the just a tip bit was a suggestion, and I think you should | |
| 13:58:04 | alex_xu | learned a new word 'eviscerate', that is terrible | |
| 13:58:17 | dansmith | lol | |
| 13:58:24 | dansmith | alex_xu: his word not mine :) | |
| 13:58:38 | alex_xu | okay.. | |
| 13:59:04 | mriedem | dansmith: if you're looking at stuff for pike, we need to get this fix in and backported to pike https://review.openstack.org/#/c/510938/ | |
| 13:59:12 | openstackgerrit | Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879 | |
| 13:59:12 | mriedem | otherwise restart after evacuate blows up | |
| 13:59:29 | dansmith | mriedem: I was just looking at your backport of my context fix when I saw that | |
| 13:59:30 | efried | dansmith This ^ oughtta be passing now, I believe. | |
| 13:59:47 | dansmith | efried: I was just getting ready to respond to cdent on that | |
| 14:00:38 | mriedem | bauzas: you want to look at this then? https://review.openstack.org/#/c/510938/ | |
| 14:00:53 | mriedem | need to wrangle our pike fixes for a release | |
| 14:01:03 | mriedem | since we have several high severity ones that are unreleased | |
| 14:01:15 | efried | dansmith I'll wait to respond until I see what you have to say, then. | |
| 14:02:38 | bauzas | mriedem: sure, will look | |
| 14:03:01 | gibi | mriedem: there is another bug 1724172 with fix top of https://review.openstack.org/#/c/510938/ | |
| 14:03:02 | 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,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 14:03:38 | bauzas | edmondsw: sdague: does that https://bugs.launchpad.net/nova/+bug/1716344 ring a bell to you ? (tl;dr: the fact that we only lookup the public endpoint when querying the SC) | |
| 14:03:39 | openstack | Launchpad bug 1716344 in OpenStack Compute (nova) "Nova-API uses Keystone's public endpoint for project id verification" [Undecided,New] | |
| 14:04:39 | johnthetubaguy | edmondsw: very late but I found that patch you were asking me about that the PTG, at least I think you asked me: https://review.openstack.org/#/c/434870 | |
| 14:07:26 | mriedem | ildikov: reading | |
| 14:07:44 | sdague | bauzas: so, we might be missing an option there | |
| 14:07:56 | sdague | that being said, this is definitely never called in vm crate | |
| 14:07:58 | sdague | create | |