| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-06 | |||
| 15:27:41 | dansmith | with this weigher, you'd get two empty hosts, plus one that has stuff on it in the subset | |
| 15:27:44 | bauzas | right, I'm saying your weigher improves the changes | |
| 15:27:47 | bauzas | chances* | |
| 15:28:06 | bauzas | that's why I don't see the need for shuffle_best_same_weighed_hosts | |
| 15:28:25 | bauzas | I'm asking to deprecate shuffle_best_same_weighed_hosts | |
| 15:28:49 | bauzas | because this option just does a random shuffle | |
| 15:28:52 | dansmith | but, in the absence of failing hosts, shuffle still helps to balance concurrent boot traffic right? | |
| 15:29:04 | dansmith | I don't see shuffle as being used for avoiding faults at all | |
| 15:32:07 | bauzas | maybe my concern is just that I dislike this shuffle option :) | |
| 15:32:46 | bauzas | if you want to spread on a specific metric, just ask for a weigher using that metric | |
| 15:32:57 | bauzas | instead of just hoping you'll get spread for free | |
| 15:32:59 | bauzas | anyway | |
| 15:34:45 | dansmith | shuffle is purely to avoid super strict packing right? | |
| 15:34:49 | dansmith | if you have big computes and small instances, | |
| 15:35:04 | dansmith | you might build 100 instances in the same exact compute before it's completely full and you move onto the next bucket in the line | |
| 15:35:21 | dansmith | shuffle seems good for just saying "we generally want packing, but not suuuuuper strict" | |
| 15:38:37 | bauzas | dansmith: "life, uh, always finds a way". Replace "life" by "weigher" and you'll get my mind here :) | |
| 15:39:00 | bauzas | anyway, back to review | |
| 15:43:10 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Update multiple fixed-IPs support with services field https://review.openstack.org/572814 | |
| 15:46:52 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081 | |
| 15:55:28 | mriedem | dansmith: for the follow up https://review.openstack.org/#/c/572814/ | |
| 15:56:40 | dansmith | mriedem: don't we have to wait two years first? | |
| 15:56:47 | dansmith | like fine aged cheddar | |
| 15:57:04 | mriedem | artom linked a bz i don't have access to | |
| 16:00:00 | dansmith | mriedem: I looked and I don't think it has any useful context in it | |
| 16:00:54 | mriedem | ok | |
| 16:01:07 | mriedem | i'll proceed with todo cleanupification | |
| 16:02:20 | openstackgerrit | Merged openstack/nova master: Fix doc nit https://review.openstack.org/572682 | |
| 16:02:44 | openstackgerrit | Curt Moore proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805 | |
| 16:03:47 | mriedem | johnthetubaguy: jaypipes: bauzas: the vmware live migration spec needs another +2 https://review.openstack.org/#/c/299207/ | |
| 16:04:03 | bauzas | mriedem: looking | |
| 16:05:41 | openstackgerrit | Curt Moore proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805 | |
| 16:07:09 | openstackgerrit | Merged openstack/nova-specs master: Update multiple fixed-IPs support with services field https://review.openstack.org/572814 | |
| 16:08:04 | bauzas | mriedem: in pre_live_migration() on the dest compute, we don't manage exceptions raised by the virt driver, right? | |
| 16:08:21 | bauzas | mriedem: I think we only do this kind of pre-flight check in the conductor layer | |
| 16:10:13 | efried | stephenfin: You around? I need some undumbification about tunnel providers. | |
| 16:10:20 | stephenfin | efried: shoot | |
| 16:10:30 | efried | stephenfin: https://review.openstack.org/#/c/564440/3/nova/conf/neutron.py | |
| 16:10:38 | mriedem | bauzas: pre_live_migration is an rpc call from the source compute | |
| 16:10:48 | mriedem | so yes if that fails, the source sets the migration as an error and stops | |
| 16:11:17 | mriedem | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6077 | |
| 16:11:32 | efried | stephenfin: What I thought I saw there is that you can only have your tunnel provider (singular) associated with one NUMA node. Is that right? | |
| 16:11:50 | stephenfin | efried: Nope | |
| 16:12:03 | stephenfin | I'm using the term tunnel provider but what I really mean is tunnel endpoint | |
| 16:12:17 | bauzas | mriedem: ok, so that will work, because I wasn't seeing any exception coming from the virt layer handled by the dest host | |
| 16:12:26 | stephenfin | namely, the logical NIC where all tunneled traffic ingresses and egresses from the compute node | |
| 16:12:42 | bauzas | mriedem: the spec is a bit missing of details, but okay | |
| 16:12:44 | stephenfin | logical because it can actually be two or more physical NICs bonded together | |
| 16:13:02 | efried | stephenfin: Ah. And those multiple NICs may live on multiple NUMA nodes. | |
| 16:13:07 | openstackgerrit | Murali Annamneni proposed openstack/nova master: Enables MySQL Cluster Support for Nova https://review.openstack.org/446643 | |
| 16:13:13 | stephenfin | you're only allowed one tunnel endpoint in neutron. Every tunneled network must use that endpoint | |
| 16:13:18 | stephenfin | efried: Correct | |
| 16:13:34 | stephenfin | Ditto for physnet-type networks (e.g. layer 2) | |
| 16:14:08 | stephenfin | You could have bonded NICs spread across the various host NUMA nodes | |
| 16:14:25 | efried | k, I get that. | |
| 16:14:48 | efried | Thanks stephenfin. | |
| 16:15:10 | stephenfin | no problemo | |
| 16:21:57 | jaypipes | mriedem: +W | |
| 16:22:35 | bauzas | jaypipes: snap, I litterally +Wd 10 secs after | |
| 16:22:39 | bauzas | but I have comments on it | |
| 16:26:11 | mriedem | bauzas: i replied to your comments about pre live migratoin | |
| 16:26:16 | mriedem | i don't really understand the concern | |
| 16:27:19 | bauzas | mriedem: it's a pure implementation thing | |
| 16:27:41 | bauzas | mriedem: it's just the fact we pass straight to the compute the migrate_data object that we build by the conductor | |
| 16:27:43 | bauzas | or the api | |
| 16:27:47 | stephenfin | efried: You're not on openstack-oslo but https://review.openstack.org/#/c/564822/ | |
| 16:27:52 | mriedem | "you somehow need to hook into this and call the virt driver so that you can raise the exception." | |
| 16:27:56 | mriedem | bauzas: ^ is all over rpc call | |
| 16:28:05 | mriedem | so if the virt driver raises an exception, it goes back to the source and fails | |
| 16:28:10 | bauzas | mriedem: but the source host never touches it *before* the dest compute amends it | |
| 16:28:26 | stephenfin | efried: I spotted the same issue on oslo.logging (I think) earlier this week | |
| 16:28:30 | mriedem | bauzas: it doesn't need to | |
| 16:28:34 | bauzas | mriedem: sure, but the spec was saying "we pass the source params to the dest so it can fail there" | |
| 16:28:37 | mriedem | the dest host populates that information and sends it back to the source | |
| 16:29:01 | mriedem | bauzas: where does it say that? | |
| 16:29:10 | mriedem | it just says, implement pre_live_migratoin for the vmware driver | |
| 16:29:16 | mriedem | like any virt driver that supports live migratoin | |
| 16:33:22 | bauzas | mriedem: it just says "implement pre migration checks" | |
| 16:33:38 | bauzas | oh shit | |
| 16:33:41 | bauzas | s/of/to | |
| 16:34:13 | openstackgerrit | Merged openstack/nova-specs master: VMware: add support for live migration https://review.openstack.org/299207 | |
| 16:34:16 | bauzas | "which will carry foo, bar, baz *of* the target" | |
| 16:34:24 | bauzas | and not "to the target" | |
| 16:35:21 | bauzas | mriedem: I think I misunderstood the point | |
| 16:35:27 | bauzas | because of s/of/to | |
| 16:38:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Add NUMANetworkInfo object https://review.openstack.org/564439 | |
| 16:38:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440 | |
| 16:38:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441 | |
| 16:39:24 | bauzas | mriedem: tbc, the exception that would be raised by the virt driver because of incompatible vcluster datasets would be here https://github.com/openstack/nova/blob/47423dfb7fb22924b6b06b99bb571c49bbc54af8/nova/compute/manager.py#L6097-L6101 | |
| 16:39:34 | bauzas | but I'm overengineering | |
| 16:41:31 | mriedem | bauzas: maybe you mean this? https://review.openstack.org/#/c/270116/10/nova/virt/vmwareapi/vmops.py@1623 | |
| 16:42:18 | bauzas | mriedem: *facepalms* | |
| 16:42:28 | bauzas | I searched for the implementation | |
| 16:42:42 | bauzas | but since they used a fucking wrong gerrit name, I was fcked | |
| 16:42:55 | mriedem | i think on the dest, the driver just stores what the cluster and data store is, so the source has to find a compatible esxi host in the same cluster and datastore | |
| 16:43:10 | mriedem | if it can't, then it's a failure | |
| 16:43:33 | bauzas | note for myself : read the fscking launchpad whiteboard and don't assume people use gerrit correctly | |
| 16:44:13 | mriedem | johnthetubaguy: you can drop the procedural -2 on this now https://review.openstack.org/#/c/270116/ | |
| 16:45:16 | bauzas | mriedem: yup, I just feel https://review.openstack.org/#/c/270116/10/nova/virt/vmwareapi/driver.py@277 needs to return the object they said | |
| 16:45:46 | bauzas | but anyway, let's voice on the change | |