| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 14:53:58 | bauzas | mriedem: the problem I have with this change is that's a big one and I'm not really a big expert on it | |
| 14:54:01 | dansmith | yeah, something in virtapi | |
| 14:54:17 | dansmith | should be fairly trivial to implement | |
| 14:54:18 | bauzas | mriedem: so, +Wing it means a lot of time for me to make sure | |
| 14:54:20 | mriedem | i will add a todo in the follow up to explore options to extract this into it's own thing | |
| 14:54:31 | mriedem | bauzas: let gibi +W i then :) | |
| 14:54:33 | mriedem | *it | |
| 14:54:35 | dansmith | mriedem: you can TODO(dansmith) it if you want | |
| 14:54:46 | bauzas | if gibi is fine with it... | |
| 14:54:58 | bauzas | I just want to be honest | |
| 14:55:05 | bauzas | (and FWIW, 38°C here) | |
| 14:55:11 | bauzas | (and I can't swim !) | |
| 14:56:57 | mriedem | gibi: ok to +W and then i'll fix the test(s) in the follow up patch? https://review.openstack.org/#/c/434870/ | |
| 14:57:30 | mriedem | god stephen's bottom change hasn't even made it through the gate yet | |
| 14:57:41 | dansmith | I know | |
| 14:58:42 | mriedem | gmann: so i don't know why we don't just have a tempest-slow job | |
| 14:59:00 | mriedem | looking at https://review.openstack.org/#/c/567697/1/playbooks/legacy/nova-slow/run.yaml@26 | |
| 14:59:16 | mriedem | what i had originally proposed as a compute-specific job that would run only compute api and scenario tests marked slow | |
| 14:59:20 | mriedem | *was a | |
| 14:59:55 | gmann | mriedem: just commented on patch. i thought of giving try to run all sceanrio tests in parallel which tempest-full does not do | |
| 15:00:24 | gmann | but yes, running scenario tests twice is not good way. | |
| 15:01:06 | gmann | i can make tempest-scenario-all job to slow job only and bring back the scenario tests running as parallel in tempest-full as end goal. | |
| 15:01:49 | mriedem | why do we need to tinker with tempest-full at all? | |
| 15:01:55 | mriedem | leave that alone, | |
| 15:02:01 | mriedem | add a tempest-slow job that just runs slow tests | |
| 15:02:03 | mriedem | the end | |
| 15:02:42 | mriedem | tempest-slow could run slow scenario tests concurrently, that doesn't matter to me | |
| 15:02:47 | gmann | but we should run scenario tests in parallel somewhere. making tempest-full to run scenario tests as serial was temporary work around | |
| 15:02:56 | mriedem | but i thought the reason for running scenario tests in serial was more about random failures than it was overall time | |
| 15:03:14 | mriedem | work around for what? | |
| 15:03:17 | gmann | yeah ssh timeout mainly | |
| 15:03:24 | mriedem | ok, | |
| 15:03:28 | mriedem | as far as i know, that's not fixed | |
| 15:03:38 | mriedem | so the workaround would need to be in place | |
| 15:04:02 | mriedem | but imo it shouldn't block adding a purely tempest-slow job that is the same as tempest-full except it runs slow tests | |
| 15:04:10 | pooja_jadhav | mriedem: Hello, need some help | |
| 15:04:29 | gmann | yeah, i am not saying changing that now but if we move scenatio-slow to run only slow then at some point we need scenario parallel testing | |
| 15:05:24 | gmann | "tempest-slow job that is the same as tempest-full except it runs slow tests" - you mean tempest-slow will run all tests including slow? | |
| 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 | mriedem | i need to update the nits patch | |
| 15:22:14 | dansmith | gerrit seems kinda confused | |
| 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 | 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 | |