| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 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: | |
| 17:08:10 | dansmith | 1. don't fail and they wonder why things suck all the sudden | |
| 17:08:12 | dansmith | 2. fail so they know | |
| 17:08:22 | mriedem | melwitt: i'd probably ask in the -release channel, and ask doug | |
| 17:08:28 | dansmith | 1. generates more support traffic I'd assume | |
| 17:09:17 | mriedem | i didn't worry too much about it because i figured we could do #2 later if we wanted | |
| 17:10:03 | melwitt | mriedem: okay thanks | |
| 17:10:58 | dansmith | mriedem: was that "didn't worry" statement aimed at me? | |
| 17:11:38 | mriedem | dansmith: yeah | |
| 17:12:29 | dansmith | mriedem: replies in there | |
| 17:16:42 | dansmith | mriedem: so, I might be out of my element here, but when I un-stub things, I get a failure to attach on the same network | |
| 17:16:58 | dansmith | because of a unique constraint on address.. i.e we can't have two on the same network (that aren't deleted) | |
| 17:17:08 | dansmith | you didn't hit thatbecause you were trying to break it with another network, | |
| 17:17:10 | dansmith | but.. | |
| 17:17:35 | dansmith | presumably there is more mock stuff to do to get me a different attachment on the second go or something | |
| 17:18:01 | dansmith | maybe I can work that out, hang oin | |
| 17:22:21 | dansmith | artom: | |
| 17:22:23 | dansmith | around? | |
| 17:22:39 | dansmith | did we or did we not skip the scheduler entirely when we rebuild to the same image? | |
| 17:22:59 | dansmith | now I'm confused because his tests all seem to assume we'll still hit the scheduler for a same-image rebuild | |
| 17:24:56 | cfriesen_ | that seems wrong | |
| 17:25:25 | dansmith | yeah | |