| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-14 | |||
| 13:38:25 | mdbooth | And neither will Nova. | |
| 13:40:06 | mdbooth | '$ openstack --insecure volume list' *does* work, but afaik there's no similar option to disable nova's certificate validation when using cinderclient. | |
| 13:41:33 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Ignore VolumeAttachmentNotFound exception in compute.manager https://review.openstack.org/636954 | |
| 13:41:56 | mdbooth | But... is there some alternate ca-bundle somewhere? | |
| 13:42:07 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Provide a useful error message when trying to update non-compute services https://review.openstack.org/636955 | |
| 13:45:55 | bauzas | gibi: I'm not super happy with https://review.openstack.org/#/c/631559/5..6/nova/tests/functional/libvirt/test_reshape.py | |
| 13:48:53 | stephenfin | kaisers: Still got comments, unfortunately https://review.openstack.org/#/c/522245 | |
| 13:49:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change sqlalchemy warnings filter to an error https://review.openstack.org/636957 | |
| 13:55:17 | openstackgerrit | Mark Goddard proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero https://review.openstack.org/608611 | |
| 14:04:29 | mdbooth | Hmm, this is a difference in behaviour between urllib.requests (urllib2) and requests, which appears to use urllib3 | |
| 14:05:13 | mdbooth | The former appears to use the system ca bundle, the latter does not | |
| 14:06:37 | gibi | efried: I answered your questions / comments in https://review.openstack.org/#/c/616239/24 | |
| 14:07:16 | mdbooth | certifi, j'accuse | |
| 14:07:23 | gibi | bauzas: how can I make you happier about that reshape functional test? | |
| 14:08:25 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/queens: Handle unicode characters in migration params https://review.openstack.org/636678 | |
| 14:10:34 | bauzas | gibi: self.compute is generated by nova.test.py which returns a ServiceFixture | |
| 14:11:23 | bauzas | gibi: if we really want to mock a real compute stop, we need to update the fixture | |
| 14:12:06 | bauzas | gibi: https://github.com/openstack/nova/blob/master/nova/test.py#L399 | |
| 14:13:06 | bauzas | gibi: somehow, you say in your comment that https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L83 doesn't work correctly | |
| 14:13:13 | bauzas | because we still have a cache | |
| 14:13:27 | bauzas | so we need to invalidate the cache there ^ | |
| 14:14:02 | gibi | bauzas: yeah, it would be nice to improve the fixture to support a real service restart | |
| 14:14:08 | gibi | bauzas: let me dig a bit about that | |
| 14:14:42 | gibi | bauzas: I remember I had issues with the restart in the past | |
| 14:14:53 | bauzas | for placement I guess ? | |
| 14:15:04 | bauzas | because I don't see any problems with the existing fixture | |
| 14:15:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: Add descriptions for vol-backed snapshots https://review.openstack.org/615084 | |
| 14:15:51 | bauzas | gibi: AFAICS, we kill the service | |
| 14:16:15 | bauzas | so I guess the problem is more about the python module | |
| 14:16:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits from I9e30a24a4c0640f282f507d0a96640d3cdefe43c https://review.openstack.org/636967 | |
| 14:17:19 | bauzas | gibi: actually, I think I voiced about this when I was reviewing the scheduler reportclient cut | |
| 14:17:28 | bauzas | we shouldn't cache it | |
| 14:18:50 | gibi | bauzas: the fixture.stop() does not kill the rela service all the module level things are in place. fixture.kill and a starting a new compute service through the fixture would be better | |
| 14:23:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Drop the integrated-gate (py27) template https://review.openstack.org/634949 | |
| 14:26:12 | matoef1 | Hi guys. After enable SSL on DevStack I got the following message from nova.. ..devstack@n-api.service[30584]: DEBUG nova.api.openstack.wsgi [None req-00203afa-89e4-4c28-bed8-cbbc985ee67c demo demo] Returning 400 to user: Invalid input for field/attribute user_data. Value: Q29udGVud... | |
| 14:26:57 | matoef1 | But my user_data value does not have more then 64k. | |
| 14:28:07 | matoef1 | But the error message is : Invalid input for field/attribute user_data .. is too long | |
| 14:28:37 | matoef1 | Is there any way how to investigate this error ? | |
| 14:28:41 | matoef1 | Many thanks | |
| 14:34:59 | mdbooth | lyarwood: So... after *finally* getting a python3 devstack up and running with nova talking to cinder over ssl on F29... I don't get the recursion error. | |
| 14:35:15 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/queens: Handle unicode characters in migration params https://review.openstack.org/636678 | |
| 14:35:34 | mdbooth | lyarwood: I downgraded eventlet to 0.21.0 | |
| 14:35:43 | mdbooth | Nada. | |
| 14:47:25 | gibi | bauzas: simply killing the compute service and starting a new compute service leads to a HostMapping issue which reminds me of https://review.openstack.org/#/c/512552/ | |
| 14:51:09 | openstackgerrit | Jack Ding proposed openstack/nova master: Flavor extra spec and image properties validation https://review.openstack.org/620706 | |
| 14:53:00 | gibi | bauzas: I will refresh https://review.openstack.org/#/c/512552/ and try to combine that with the reshape test to see if that helps | |
| 14:57:23 | gibi | bauzas: I don't actually have to complicate that much | |
| 14:57:35 | gibi | bauzas: there is already a restart_compute_service() call that does the trick we need | |
| 14:58:59 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add functional test for libvirt vgpu reshape https://review.openstack.org/631559 | |
| 14:59:03 | gibi | bauzas: what about this ^^ | |
| 15:00:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove deprecated 'os-flavor-manage' policy https://review.openstack.org/633656 | |
| 15:01:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix a missing policy in test policy data https://review.openstack.org/633686 | |
| 15:06:58 | openstackgerrit | Elod Illes proposed openstack/nova master: DNM: test pip 19 - pip freeze with git editable https://review.openstack.org/636980 | |
| 15:09:40 | bauzas | gibi: looking | |
| 15:09:44 | bauzas | gibi: sorry was afk | |
| 15:10:20 | bauzas | gibi: FWIW, I checked and we still need to have https://review.openstack.org/#/c/636591/1 | |
| 15:10:29 | bauzas | gibi: that said, looks like it's not a problem | |
| 15:10:57 | bauzas | gibi: I'll use a specific type on my node, and see whether we have problems | |
| 15:11:04 | gibi | bauzas: OK | |
| 15:11:45 | bauzas | gibi: http://paste.openstack.org/show/745109/ | |
| 15:12:24 | bauzas | gibi: the fdfd8f9b-e645-4a6f-aa60-477b00ba32b7 instance is having the mdev_27840b52_31e3_4fb7_a391_ec529e73be93 | |
| 15:12:54 | bauzas | gibi: placement said it should be in virtlab606.virt.lab.eng.bos.redhat.com_pci_0000_84_00_0 which is RP #3 | |
| 15:13:16 | bauzas | gibi: but when looking at libvirt, the mdev parent is pci_0000_87_00_0 | |
| 15:13:24 | bauzas | ie. not the same pGPU | |
| 15:13:45 | bauzas | given all pGPUs have the same type, I don't think it's a problem, but I'll test it | |
| 15:14:22 | openstackgerrit | Merged openstack/nova-specs master: Add more detail and fix code block formatting https://review.openstack.org/628702 | |
| 15:14:35 | gibi | bauzas: so you have more than one pGPU and nova allocates VGPU from one RP in placement then use mdev from another PGPU on the host | |
| 15:14:45 | bauzas | correct | |
| 15:15:29 | gibi | do you have more than one pgpu RP in placement? or you only report all the mdevs from the host on a single RP in placement? | |
| 15:16:45 | bauzas | gibi: we have a RP per pPGU, yes | |
| 15:17:02 | bauzas | gibi: see http://paste.openstack.org/show/745093/ | |
| 15:17:14 | bauzas | we have 4 inventories for VGPU RC | |
| 15:17:38 | bauzas | while previously we only had 1 | |
| 15:17:52 | gibi | bauzas: then there will be problem when you remove a pgpu from the host that has no mdev allocated from, but in placement the allocation is against that RP | |
| 15:18:12 | bauzas | you can't remove a PGPU | |
| 15:18:19 | bauzas | it's a PCI device | |
| 15:18:26 | gibi | stop the host, remove the pci device, start the host | |
| 15:18:32 | bauzas | ah that, then yes | |
| 15:18:40 | bauzas | but honestly, how many people would do this ? | |
| 15:18:48 | bauzas | I can add a documentation of course | |
| 15:18:56 | gibi | bauzas: yeah | |
| 15:18:58 | bauzas | actually, I need to do it | |
| 15:19:13 | bauzas | and remove it by https://review.openstack.org/#/c/636591/ | |
| 15:19:34 | gibi | bauzas: it could be problem in future when we start supporting different device types per pgpu, but our RP inventory does not match the physical usage of the pgpu | |
| 15:19:42 | gibi | bauzas: I feel this inconsistency is dangerous | |
| 15:19:51 | bauzas | but lemme use one type that gives 1 VGPU per pGPU | |
| 15:20:13 | bauzas | gibi: right, I said it, we don't have a problem for the moment | |
| 15:20:22 | bauzas | gibi: until we have multiple types | |
| 15:20:32 | bauzas | where two pGPUs could have different types | |
| 15:20:45 | bauzas | I documented it tho | |
| 15:20:49 | gibi | bauzas: but if we release this code, then there will be deployments where the allocation in placement will not reflect that usage on the host, and fixing those deployments will be painful | |
| 15:21:49 | gibi | bauzas: the fix will be like moving allocations between RPs based on parent child relationship | |
| 15:21:58 | gibi | of the mdev and the pgpu | |
| 15:22:25 | gibi | I agree that it is not a problem today, but it will cause pain in the future if we are not handling it now | |
| 15:22:41 | bauzas | gibi: actually that's a good point, we should need to reshape allocations :( | |
| 15:25:11 | gibi | bauzas: it will be even more complicated if a server requests two VGPUs in a numbered groups, and therefore it needs to be filled from one pgpu which is represented as on RP in placement. But the RP in placement won't have an exact inventory for a single pgpu | |
| 15:25:38 | bauzas | gibi: we don't accept requests for > 1 vGPU atm | |
| 15:26:16 | bauzas | for many reasons, one being at least that nvidia driver doesn't support more than one mdev attached to a guest per pGPU | |
| 15:26:33 | gibi | bauzas: I see | |
| 15:26:39 | gibi | bauzas: that hepls | |