Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-06
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
16:50:34 mriedem bauzas: that's this https://review.openstack.org/#/c/270116/10/nova/virt/vmwareapi/driver.py@304
16:50:42 mriedem it's the same object
16:51:12 mriedem conductor calls check_can_live_migrate_destination to get migrate_data, passes it to live_migration, which passes it to pre_live_migration, which passes it bakc
16:51:13 mriedem *back
16:51:17 mriedem it's like the live migration hot potato
16:52:47 bauzas yeah, it's just yet another way of doing the same check
16:53:38 dansmith mriedem: melwitt: tssurya: assume we're having a cells meeting?
16:53:42 bauzas if we were using the result of check_can_live_migrate_dest() on the compute by calling the source compute too before we run the migration, that would save us one roundtrip
16:56:18 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Use generic metadata term instead of config drive https://review.openstack.org/572837
16:58:18 tssurya dansmith: I guess so ?
16:58:54 dansmith let's do it just to say we did
17:15:41 openstackgerrit Merged openstack/nova-specs master: Use generic metadata term instead of config drive https://review.openstack.org/572837

Earlier   Later