| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 15:05:34 | mriedem | ONLY slow | |
| 15:05:39 | gmann | ok. | |
| 15:05:48 | pooja_jadhav | mriedem: If I am doing live migrate, my both nodes(source, destination) referring to nfs shared storage then it should not shh to the destination node. but its going for ssh. | |
| 15:06:06 | gmann | mriedem: make sense. | |
| 15:06:21 | mriedem | gmann: that's what i originally proposed in the ML thread | |
| 15:06:27 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-May/130394.html | |
| 15:07:19 | gmann | mriedem: ok, ll re iterate that job and update patch. but after rocky | |
| 15:10:24 | mriedem | o/ | |
| 15:20:56 | dansmith | gibi: want to hit this? https://review.openstack.org/#/c/434870/ | |
| 15:20:57 | gibi | mriedem: I'm +Wing the bottom... | |
| 15:21:30 | gibi | dansmith, mriedem: +W | |
| 15:21:42 | dansmith | thanks | |
| 15:21:53 | mriedem | thanks | |
| 15:22:05 | dansmith | what else needs attention on that set? | |
| 15:22:14 | dansmith | gerrit seems kinda confused | |
| 15:22:14 | mriedem | i need to update the nits patch | |
| 15:22:16 | mriedem | was just looking at that | |
| 15:22:22 | dansmith | is that it? | |
| 15:22:26 | mriedem | yeah | |
| 15:22:30 | dansmith | alright | |
| 15:22:32 | mriedem | once https://review.openstack.org/#/c/522537/ merges it's bp complete | |
| 15:22:56 | dansmith | okay | |
| 15:23:20 | dansmith | the check queue just dropped by 25% | |
| 15:23:30 | dansmith | I wonder if a bunch of things merged or something else | |
| 15:25:31 | gibi | We are at FF so it needs to be something else at this time of the year ;) | |
| 15:56:38 | dansmith | so, if -merges is still accurate, nova hasn't merged anything since midnight | |
| 15:56:47 | dansmith | and a bunch of stuff just flushed out of the gate queue it seems, | |
| 15:56:59 | dansmith | which I assume means a failure | |
| 15:57:09 | dansmith | maybe things will come back via re-queue | |
| 16:02:35 | Shilpa | mordred: HI | |
| 16:04:45 | mriedem | dansmith: doesn't have to be for FF but we should get this in before RC1 so we can drop the reqspec compat code in stein https://review.openstack.org/#/c/581813/ | |
| 16:05:09 | dansmith | ack | |
| 16:13:16 | dansmith | mriedem: do you not want to batch those instance queries a bit? | |
| 16:13:31 | dansmith | you're going to end up with a sql query to the api database that has every (live) instance uuid in it | |
| 16:13:49 | dansmith | oh, no | |
| 16:13:59 | dansmith | N queries I guess | |
| 16:21:15 | mriedem | oh i see, using IN (instance_uuids) LIMIT 50 | |
| 16:21:28 | mriedem | and then sorting out from the results what is missing | |
| 16:22:07 | mriedem | we also stop once we find at least one per cell | |
| 16:27:01 | dansmith | you do stop once per cell right? | |
| 16:27:23 | dansmith | oh, read that wrong | |
| 16:27:25 | dansmith | yeah, do stop | |
| 16:27:46 | mriedem | right iterate cells, get instances, lookup reqspec per instance | |
| 16:28:03 | mriedem | stop per cell if one is missing | |
| 16:48:00 | tbachman | SRIOV question: does a user have the ability to influence which SRIOV device nova selects when it schedules an instance to a compute host that happens to have multiple SRIOV devices (and in this case, the devices have the same vendor/product IDs)? | |
| 16:49:00 | mriedem | tbachman: you mean in the case that the user doesn't provide a specific port to attach when the server is created? | |
| 16:49:07 | tbachman | I saw the use of flavors to select an SRIOV NIC based on the vendor/product ID, but not something that can uniquely identify a NIC (and yes, this is a pet, not cattle case :-( ) | |
| 16:49:43 | mriedem | if you know which nic you want, provide the port when creating the server | |
| 16:49:44 | tbachman | mriedem: is there a way to specify it in the port object? | |
| 16:49:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Retry allocation writes server side https://review.openstack.org/586048 | |
| 16:49:56 | mriedem | i believe there is some wonky port profile stuff | |
| 16:50:00 | tbachman | heh | |
| 16:50:01 | mriedem | with the vendor info in it | |
| 16:50:06 | tbachman | ah | |
| 16:50:19 | mriedem | https://docs.openstack.org/neutron/latest/admin/config-sriov.html | |
| 16:50:21 | tbachman | so, are you saying the user can populate this, and not Nova? | |
| 16:50:33 | tbachman | the binding:profile bits? | |
| 16:50:43 | tbachman | (and Nova will use it | |
| 16:50:45 | tbachman | ) | |
| 16:51:05 | mriedem | https://docs.openstack.org/neutron/latest/admin/config-sriov.html#launching-instances-with-sr-iov-ports | |
| 16:51:05 | tbachman | yeah, I’d been looking at this | |
| 16:51:42 | tbachman | so, I see it adding “trusted” to the profile | |
| 16:51:45 | mriedem | i'm not totally sure about the auto policy on the port binding profile | |
| 16:51:55 | mriedem | *auth | |
| 16:52:07 | mriedem | sahid is likely the person to ask about this, | |
| 16:52:10 | mriedem | or sean-k-mooney[m] | |
| 16:52:12 | tbachman | If nova will accept (and use) the information in the profile, then I’m set | |
| 16:52:17 | tbachman | mriedem: thx! | |
| 16:53:14 | mriedem | tbachman: yeah the magic starts here in nova https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1825 | |
| 16:53:27 | mriedem | that's called from the api to translate the requested port to a pci request which the compute will process | |
| 16:53:46 | tbachman | cool | |
| 16:54:08 | tbachman | mriedem: thanks for that tip! | |
| 16:54:09 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Use base test in placement functional tests https://review.openstack.org/585778 | |
| 16:55:54 | mriedem | grep VNIC_TYPES_SRIOV in there for other pci thingies with the binding profile | |
| 16:56:14 | mriedem | and if the planets align it might work | |
| 16:56:31 | tbachman | hmmm — I see it add things to the request, but unfortunately I don’t see the PCI device itself | |
| 16:56:38 | tbachman | I’ll follow this path a bit more tho | |
| 17:04:37 | dansmith | mriedem: I left that rebuild test in there because it wasn't failing, but didn't really even look at it | |
| 17:05:14 | dansmith | just needs the unstub treatment yeah? | |
| 17:05:29 | mriedem | dansmith: i'd have to look again, but it didn't do anything | |
| 17:05:35 | mriedem | i mean, i removed some stuff and it didn't fail | |
| 17:05:44 | dansmith | yeah, because of the stub | |
| 17:05:49 | mriedem | i added some things which made it fail | |
| 17:05:52 | dansmith | because it's checking the straight line | |
| 17:05:56 | mriedem | right, so, | |
| 17:06:06 | dansmith | point being, do you want to just remove that like the other one I nuked, or fix it? | |
| 17:06:08 | melwitt | mriedem: need advice from a release perspective, is this considered critical enough to ask for a FFE to fix the install of the NoOp plugin that was the main feature released in 0.11.1? https://review.openstack.org/585530 | |
| 17:06:12 | mriedem | well, also because it's not changing the image during rebuild so it doesn't go through the scheduler | |
| 17:06:27 | mriedem | dansmith: i was thinking we could fix the test and add the negative wrinkle | |
| 17:06:34 | melwitt | *1.11.0 | |
| 17:06:38 | dansmith | mriedem: yup the other test did the image change | |
| 17:06:46 | mriedem | there were 2 rebuild tests? | |
| 17:06:49 | mriedem | i must have missed that | |
| 17:06:57 | dansmith | yup | |
| 17:06:59 | mriedem | dansmith: oh also, this brings up something i was going to talk with you about, | |
| 17:07:12 | dansmith | mriedem: this was supposed to be the "make sure the completely normal case still works | |
| 17:07:14 | dansmith | " | |
| 17:07:24 | mriedem | which is that if the user attaches a port in a network that doesn't fit the host, and rebuilds with a new image, it will fail | |
| 17:07:33 | mriedem | which is kind of a weird place to fail (on the rebuild but not the port attach) | |
| 17:08:03 | dansmith | yeah, but here are two alternatives: | |