| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 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 | mriedem | i believe there is some wonky port profile stuff | |
| 16:49:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Retry allocation writes server side https://review.openstack.org/586048 | |
| 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 | tbachman | yeah, I’d been looking at this | |
| 16:51:05 | mriedem | https://docs.openstack.org/neutron/latest/admin/config-sriov.html#launching-instances-with-sr-iov-ports | |
| 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 | |
| 17:25:28 | dansmith | I think it is wrong | |
| 17:27:20 | cfriesen_ | I think the relevent code is rebuild_instance in the conductor | |
| 17:27:30 | cfriesen_ | only calls the scheduler if "host" is not set | |
| 17:30:15 | dansmith | ooh, I think I might've found a bug in the code with this | |
| 17:31:04 | dansmith | we get a 500 on NoValidHost in rebuild | |
| 17:31:45 | artom | dansmith, I thought we did | |
| 17:32:19 | dansmith | although we cast so we won't get that in the real world | |
| 17:32:24 | artom | I'd have to check the code I guess, but a thing that happened was if you rebuilt with the same new image after the first rebuild request with that image was refused, we'd let it pass | |
| 17:32:26 | dansmith | only because of CastAsCall | |
| 17:32:30 | artom | Until we added rolling back of the image_ref | |
| 17:32:51 | dansmith | mriedem: how do you handle that? Just check for 500 in the test or do more monkey work? | |
| 17:39:59 | dansmith | feels wrong to handle NoValidHost in the api when it will only happen in tests | |
| 17:43:37 | mriedem | assert the 500 in the test | |
| 17:43:45 | dansmith | okay | |
| 17:43:51 | mriedem | self.assertRaises(client.OpenStackAPIException, ...) or whatever | |
| 17:43:55 | mriedem | ex.response.status_code | |
| 17:43:59 | dansmith | yup | |
| 17:44:02 | mriedem | the server likely also has a fault on it | |
| 17:44:45 | dansmith | I don't see any other uses of asserting the 500.. did I miss them? | |