| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-21 | |||
| 12:39:19 | gibi | mriedem, stephenfin: thanks for the laugh https://review.opendev.org/#/c/489267/2/nova/network/neutronv2/api.py@181 | |
| 12:41:09 | gibi | stephenfin: btw you have now a lot of +2s on your nova-net removal series :) | |
| 12:42:29 | efried | gmann: looking... | |
| 12:49:22 | mriedem | gibi: heh, anytime | |
| 12:51:07 | efried | gmann: that log file isn't loading up for me :( | |
| 12:51:45 | efried | It would be weird for a provider managed by nova to have 'openstack:' in its name. If it was made by some other service, maybe, but I've never heard of it. | |
| 12:53:28 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Include removal of ephemeral backing files in the image cache manager https://review.opendev.org/689422 | |
| 12:58:15 | johnthetubaguy | stephenfin: I just had a look at the network API removal... are we not adding a microversion to signal when we removed the API, I think that would be more consistent with our rules? | |
| 12:58:45 | johnthetubaguy | I am guessing I missed about a year of conversation, so probably missed the reasoning | |
| 13:00:05 | mriedem | fun gate bug i finally wrote up after rechecking several times https://bugs.launchpad.net/tempest/+bug/1853453 | |
| 13:00:05 | openstack | Launchpad bug 1853453 in tempest "test_shelve_volume_backed_instance intermittently fails guest ssh with dhcp lease fail" [Undecided,New] | |
| 13:00:11 | mriedem | looks like this only hits in multinode jobs, | |
| 13:00:21 | mriedem | and looking at a recent failure, we shelve from the primary node and unshelve on the subnode | |
| 13:00:45 | mriedem | i wonder if the snapshot is no good in some cases and unshelving on another node causes some kind of issue | |
| 13:06:33 | mriedem | oh nvm there is no snapshot, it's volume-backed | |
| 13:06:34 | mriedem | derp | |
| 13:12:08 | gibi | efried: do you know if provider_tree in the report client will contain RPs associated to the compute RP via aggregate? this comment states it does https://github.com/openstack/nova/blob/1cd5563f2dd2b218db2422397c8aab394d484626/nova/scheduler/client/report.py#L593 | |
| 13:12:36 | gibi | efried: but I did not find in the impl where we query for those RPs from placement | |
| 13:12:51 | efried | gibi: it should, yes; the code has been written that way for a while, but we've never had a real scenario that uses it. | |
| 13:13:07 | efried | hold on, let me find you the code (It's somewhere under _refresh_associations...) | |
| 13:13:52 | efried | ah, it looks like we specifically target only sharing providers (we specifically filter on MISC_SHARES) | |
| 13:13:55 | efried | which makes sense | |
| 13:14:04 | efried | we wouldn't want to just arbitrarily pick up anything in an aggregate. | |
| 13:14:37 | gibi | efried: cool, MISC_SHARES... is what I'm looking for. Do you have a link? | |
| 13:15:09 | efried | gibi: https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/client/report.py#L787-L806 ish | |
| 13:15:22 | gibi | efried: thanks a lot! | |
| 13:15:42 | gibi | shilpasd: ^^ | |
| 13:15:44 | bauzas | johnthetubaguy: we deprecated the APIs so AFAIK we don't need a microversion | |
| 13:15:49 | efried | gibi: that comment you pointed out should really say *sharing* providers. | |
| 13:16:20 | gibi | I can fix that quickly.. | |
| 13:16:24 | efried | bauzas: I see johnthetubaguy's point, though. If you come into one cloud and try to use nova-net at microversion 2.58 and it works, and then you come into a different cloud and it fails at the same microversion... | |
| 13:16:54 | bauzas | efried: sure, it's an interop issue | |
| 13:16:55 | bauzas | but | |
| 13:17:09 | johnthetubaguy | efried: I am more thinking, the SDK and CLI should be able to know when its missing, like with all our other APIs | |
| 13:17:16 | bauzas | if you use nova-network since 2.58, you are a bit having problems | |
| 13:17:32 | johnthetubaguy | to be clear, I think we should remove it, and it should return 210 | |
| 13:17:32 | efried | Either way, I think that ship has sailed, cause we've already ripped a bunch of stuff out. Pretty sure the point of no return was in train, too. | |
| 13:17:37 | bauzas | also, if you use OSC, you won't see the APIs be deleted | |
| 13:17:54 | johnthetubaguy | I just think we should have a microversion that tells a user, if that is here, you know those APIs are gone | |
| 13:18:12 | johnthetubaguy | we can add it as the last patch in the series, and I think that kinda works, its just a handy hit | |
| 13:18:34 | johnthetubaguy | it makes the docs easier though, if microversion X is available, you know this API will always return HTTP gone | |
| 13:19:05 | zigo | bauzas: Hi there! I'm trying to start an instance with a GPU, and I get this: | |
| 13:19:05 | zigo | $ openstack server create --image bionic-server-cloudimg-amd64_20190726_GPU --nic net-id=bdb-blue-int01 --key-name yubikey-zigo --flavor cpu4-ram12-disk20-gpu-nvidia-p1000 --availability-zone=AZ2 zigo-gpu | |
| 13:19:05 | zigo | PCI alias nvidia-p1000 is not defined (HTTP 400) (Request-ID: req-b0514752-9e50-4e9b-a085-6ef9169b1d59) | |
| 13:19:23 | zigo | bauzas: Though I do have this in nova.conf: | |
| 13:19:24 | zigo | alias={"vendor_id":"10de","product_id":"1cb1","name":"nvidia-p1000","device_type":"type-PCI"} | |
| 13:19:27 | zigo | What am I missing? | |
| 13:19:27 | openstackgerrit | Elod Illes proposed openstack/nova stable/pike: Explicitly fail if trying to attach SR-IOV port https://review.opendev.org/695408 | |
| 13:19:54 | bauzas | johnthetubaguy: well, we could indeed | |
| 13:20:17 | bauzas | once all the APIs are giving HTTP410 | |
| 13:20:22 | johnthetubaguy | bauzas: it is a nice to have, really its the docs that worried me | |
| 13:20:22 | bauzas | stephenfin: ^ | |
| 13:20:44 | johnthetubaguy | zigo: is that in the API and Compute nova.conf? | |
| 13:20:52 | zigo | johnthetubaguy: Yeah... | |
| 13:21:12 | zigo | johnthetubaguy: It's ok to have multiple times: | |
| 13:21:12 | zigo | [pci] | |
| 13:21:12 | zigo | alias=<something> | |
| 13:21:13 | zigo | right? | |
| 13:21:18 | johnthetubaguy | hmm, I think that is how I screwed it once | |
| 13:21:23 | zigo | Cause I have 2 different boards in this cloud ... | |
| 13:21:41 | zigo | johnthetubaguy: You mean it should be only in the compute? | |
| 13:22:06 | johnthetubaguy | no, sorry, I was meaning it needs to be everyone, almost | |
| 13:22:15 | gmann | johnthetubaguy: bauzas efried : and that microversion is just to notify the users that nova-net APIs (including url) are gone and not maintaining those API for older microversion right ? | |
| 13:22:28 | johnthetubaguy | gmann: +1 | |
| 13:22:38 | bauzas | gmann: yup, just a signal | |
| 13:22:44 | gmann | ok. that make sense. | |
| 13:23:08 | gibi | works for me | |
| 13:23:14 | bauzas | zigo: not sure I understand | |
| 13:23:28 | bauzas | zigo: you need to set the alias value *once* | |
| 13:24:01 | zigo | bauzas: Yeah, but I have one Nvidia p1000 and one t4 (on 2 different compute nodes). | |
| 13:24:27 | efried | johnthetubaguy: I think the patch to make those 410s already flew... | |
| 13:24:46 | efried | johnthetubaguy: okay, patches plural. And yes, they merged in train. | |
| 13:24:47 | zigo | Therefore, I have: | |
| 13:24:47 | zigo | [pci] | |
| 13:24:47 | zigo | alias={"vendor_id":"10de","product_id":"1cb1","name":"nvidia-p1000","device_type":"type-PCI"} | |
| 13:24:47 | zigo | alias={"vendor_id":"10de","product_id":"1eb8","name":"nvidia-t4","device_type":"type-PCI"} | |
| 13:24:50 | zigo | Is this correct? | |
| 13:25:06 | efried | johnthetubaguy: so really we could do that microversion any time? | |
| 13:25:15 | efried | and the rest is just cleanup? | |
| 13:25:40 | johnthetubaguy | efried: yes, expect for the docs needing to be updated to reflect how you find out when its gone | |
| 13:26:27 | efried | okay. Pretty sure the docs were the first thing stephenfin hit -- but yeah, they wouldn't mention a microversion cutover if we didn't do that. | |
| 13:26:46 | johnthetubaguy | efried: we can go back an add that for sure | |
| 13:26:47 | efried | So you're looking for a patch that creates a new "signal microversion" and updates the docs accordingly. | |
| 13:26:56 | efried | that makes sense ++ | |
| 13:27:07 | johnthetubaguy | yeah, thanks, that clears it up in my head too | |
| 13:27:08 | johnthetubaguy | phew | |
| 13:27:37 | efried | you can still have the interop snafu I mentioned earlier. But at least in that scenario your "signal" is the 410. | |
| 13:28:32 | sean-k-mooney | zigo: the nviad-t4 apparently supprot sriov so you have to set teh device_type to type-PF | |
| 13:28:40 | johnthetubaguy | efried: yeah, its that you could have known better | |
| 13:28:53 | sean-k-mooney | stephenfin: ^ that is the thin you were writing the docs patch for right | |
| 13:29:07 | sean-k-mooney | https://review.opendev.org/#/c/694522/ | |
| 13:29:09 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Specify what RPs _ensure_resource_provider collects https://review.opendev.org/695429 | |
| 13:29:12 | zigo | sean-k-mooney: The issue is with my p1000, the t4 looks like working ... | |
| 13:29:18 | zigo | But thanks, I'll try. | |
| 13:29:32 | gibi | efried: fixed up the comment in _ensure_resource_provider_collects https://review.opendev.org/695429 | |
| 13:29:46 | sean-k-mooney | zigo: what is the issue you are having specificly | |
| 13:30:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Force config drive in nova-next multinode job https://review.opendev.org/695431 | |
| 13:30:00 | zigo | sean-k-mooney: PCI alias nvidia-p1000 is not defined (HTTP 400) | |
| 13:30:07 | zigo | (when trying to spawn my instance) | |
| 13:30:21 | gmann | efried: but from nova ussuri onwards, any microversion will be no-nova-net-api for all cloud so interop things needs to be taken care by discoverability of new microversion we will introduce instead of code handle that. | |