Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-05-14
13:53:41 sean-k-mooney there a a few neche thing it does not support but in general i thikn its an impovement
14:05:52 artom stephenfin, hey, comment on https://review.opendev.org/#/c/714698/8
14:06:05 artom stephenfin, I hesitate to -1 because of it, tell me what you think
14:06:15 gmann brinzhang_: gibi replied on pep8 fix patch. let me release new hacking 4.0.0 which will have new checks and then we can fix and bump version in same patch to verify all work fine.
14:06:21 openstackgerrit Takashi Natsume proposed openstack/nova master: Remove six.binary_type/integer_types/string_types https://review.opendev.org/728094
14:07:40 gmann sean-k-mooney: sure, I will check
14:09:42 openstackgerrit Jiri Suchomel proposed openstack/nova master: Bring back allowed_direct_url_schemes in support of RBD image download https://review.opendev.org/728095
14:12:12 stephenfin artom: replied
14:12:44 stephenfin artom: tl;dr: I'd suggest blindly approving that and focusing your efforts on https://review.opendev.org/#/c/714703/ instead :P
14:15:35 artom stephenfin, hehe - yeah, I'm slowly making my way up the stack.
14:16:12 stephenfin gmann: Before you do any work on it, I already have a hacking 3.1.0 proposed https://review.opendev.org/#/c/728016/
14:17:47 stephenfin Using semver for hacking (or flake8 and its ilk) is weird. On one hand, you normally think of minor versions as "not breaking anything" and that entails ensuring changes are purely additive, but for hacking a change can be purely additive and still break stuff
14:21:13 stephenfin gmann: in any case, I've opted for 3.1.0 because the release doesn't remove anything (so it's correct in a literal semver sense) and bumping the major version every time we add something new to hacking (or get it for free via flake8) seems insane
14:32:47 stephenfin lyarwood: Do you think you'd be able to take a look at the bottom of this series at some point? https://review.opendev.org/#/q/topic:bp/use-pcpu-and-vcpu-in-one-instance+status:open
14:34:10 stephenfin The bottom patches are almost all cleanup and shuffling of code. Things only get interesting higher up (currently in merge conflict) and I'm happy to review those ones
14:34:28 lyarwood stephenfin: yup but likely not today
14:34:40 stephenfin oh yeah, just at some point
14:34:58 lyarwood ack added
14:35:32 lyarwood gerrit really doesn't like long series like that
14:35:42 lyarwood it took a few clicks to work out where the bottom of the series actually was
14:38:14 gmann stephenfin: i see, thanks. I was waiting for hacking patch to merge before release. i agree on versioning things, it is difficult to make it consistent with other as per its nature of breaking things. 3.1.0 is ok for me.
14:41:46 gmann stephenfin: thanks you pinged me, i was about to push my local patch to release it :)
14:42:00 stephenfin heh, no problem :)
14:48:16 lyarwood weirdness, I'm getting the following in a functional test despite using microversion = 'latest'
14:48:18 lyarwood nova.tests.functional.api.client.OpenStackApiException: Unexpected status code: {"badRequest": {"code": 400, "message": "'host' is a required property"}}
14:49:16 lyarwood self.admin_api.put_service(test_compute0_service_id, {"forced_down": True}) <- from that, looks like it's using an earlier microversion but I can't see any obvious reason why, has anyone seen this before?
14:51:01 gmann lyarwood: which test. 'despite using microversion = 'latest'' you mean particular test right not overall for all request
14:51:48 lyarwood gmann: all requests, self.admin_api.microversion == 'latest'
14:53:55 gmann lyarwood: that might not work as test are written per microversion cap they would(might) not run for 'latest'.
14:55:17 lyarwood gmann: you're talking about https://github.com/openstack/nova/blob/ef3b5707328f460d0d03759061c01b1a20f28743/nova/api/openstack/compute/services.py#L380-L383 right?
14:55:26 lyarwood gmann: so you have to use 2.53 to use this?
14:55:34 gibi dansmith: hi! one complication of the cache bug is that the cache management is virt driver specific but the placement resource management is up in the compute manager. So for the fix I need to pass new information through the virt driver interface, either by returning disc occupancy from manage_image_cache() or by adding some new get method to the virt interface
14:57:23 gmann lyarwood: yes, but i am saying if you run all the func test with 'latest' then it would not work. or you are running only update service tests ?
14:57:58 dansmith gibi: yeah, I was saying to sean-k-mooney yesterday how it's kinda split between them in an unhelpful way
14:58:02 lyarwood gmann: ah sorry no this is a specific test class that's set to 'latest'
14:58:29 dansmith gibi: doing it during manage_image_cache() means the allocations will lag reality, which isn't going to work well I think
14:58:43 dansmith gibi: IIRC, that runs very slowly, like every 24h or something
14:58:48 dansmith (by default)
14:59:06 dansmith gibi: unfortunately, I think it kinda has to happen synchronously during boot to really be effective
14:59:07 openstackgerrit Takashi Natsume proposed openstack/nova master: Remove six.text_type (1/2) https://review.opendev.org/728109
14:59:53 gibi dansmith: yeah for the boot I need a sync approach. for the periodicy resynchronization I'm thinking of reusing manage_image_cache()
15:00:08 dansmith gibi: sure
15:00:43 gibi dansmith: OK so we agree that a virt interface impact is unavoidable
15:00:45 gmann lyarwood: ohk, then it is taking old 2.1 schema which need host. i think we read 'latest' correctly in code- https://github.com/openstack/nova/blob/ef3b5707328f460d0d03759061c01b1a20f28743/nova/api/openstack/compute/schemas/services.py#L46
15:01:05 dansmith gibi: yeah I dunno how else you would do it.. like I had to add driver.cache_image() for my thing
15:01:39 dansmith gibi: and probably some signaling about the filesystem same-ness
15:03:03 gibi dansmith: OK, I will continue working through this path then
15:04:36 lyarwood gmann: ah got it thanks
15:04:45 lyarwood gmann: I was missing api_major_version = 'v2.1'
15:06:08 gmann lyarwood: ohk, and it was microversion request with 2.0 so ignored
15:08:18 lyarwood gmann: yeah that wasn't at all obvious, thanks again :)
15:26:56 openstackgerrit Takashi Natsume proposed openstack/nova master: Remove six.text_type (2/2) https://review.opendev.org/728117
15:28:24 lyarwood stephenfin / artom: random question, do either of you recall how nova.tests.functional.libvirt.base.ServersTestBase stops the instance directories from being created?
15:29:00 artom lyarwood, I'd have to go digging - there's a presumably a mock/monkeypatch somewhere
15:29:04 stephenfin lyarwood: Not off the top of my head, unfortunately
15:29:10 lyarwood I've stopped applying ImageBackendFixture and the other obvious file_open fixtures etc but it's still not happy
15:29:17 lyarwood ack np
15:30:39 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Add emulated TPM support to Nova https://review.opendev.org/631363
15:30:40 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934
15:37:54 lyarwood doh, it was nova.virt.libvirt.LibvirtDriver._create_image
15:39:33 lucadelmonte90 hello,
15:40:40 lucadelmonte90 i couldn't find anything online, is there a way to disable instance resize from flavor a to flavor b, but keep it enabled for flavor a to flavor c?
15:42:01 stephenfin efried: Can you drop your -2 on https://review.opendev.org/#/c/631363/ ?
15:42:56 efried stephenfin: dangit, I thought I had removed all of my -2s. Done.
15:43:15 stephenfin Thanks
15:45:39 artom lucadelmonte90, no
15:46:22 lucadelmonte90 artom thanks :D
15:47:16 artom lucadelmonte90, if only all questions were that easy :)
15:50:24 gibi nova meeting going to start in 10 minutes on #openstack-meeting-3
15:55:24 artom stephenfin, question on https://review.opendev.org/#/c/468203/14
15:55:29 artom Not confident enough to -1...
15:56:37 bauzas just in time for the meeting
15:56:49 artom For the meating
15:57:39 bauzas and yelp doesn't help for getting doctor's votes :(
15:58:01 bauzas artom: too early for me
15:58:11 bauzas I'm not hungry but we're close to beer time tho
15:58:26 artom Not that kind of meating, muahaha
16:00:04 artom stephenfin, and another question on https://review.opendev.org/#/c/461456/13
16:02:47 artom bauzas, I beet myself up every day
16:02:57 artom (Let's not pollute the meating)
16:04:06 bauzas artom: my doctor told me I should heel
16:31:25 bauzas bear time !
16:31:32 gibi :D
16:33:48 gmann gibi: https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-deprecated-apis
17:07:58 melwitt sean-k-mooney: why do you think we need the bigger list here? https://review.opendev.org/#/c/727898/3/bindep.txt just wondering bc it works without them being explicitly named
17:30:09 openstackgerrit melissaml proposed openstack/os-traits master: Remove translation sections from setup.cfg https://review.opendev.org/728160
17:56:51 NobodyCam Good morning Nova folk's could someone help point me to which database this would come from: `Placement API returning an error response: Conflicting resource provider name: <hostName> already exists. call_func /openstack/venvs/nova-18.1.5.dev5/lib/python2.7/site-packages/nova/api/openstack/placement/wsgi_wrapper.py:31`
18:01:28 melwitt NobodyCam: what version? (has to be older bc placement was removed from nova in train) database would be the placement database, and if the version is old enough, it would be the nova_api database
18:01:58 NobodyCam Morning melwitt :) I'm on rocky
18:02:59 melwitt ok, yeah so if you have a database called 'placement' it will be in there, if not it will be in the database called 'nova_api'
18:04:27 NobodyCam I have nova_api
18:04:27 melwitt there's a unique constraint on resource provider name https://github.com/openstack/nova/blob/stable/rocky/nova/db/sqlalchemy/api_models.py#L292-L306
18:04:56 melwitt resource_providers table
18:07:22 melwitt and if you want to change the name the recommended way is to use the placement cli https://docs.openstack.org/osc-placement/rocky/cli/index.html#resource-provider-set
18:08:22 melwitt although I guess it depends on how you're getting the error. if it's nova trying to do something then you will need to change something in nova. sorry I spoke too soon
18:10:49 NobodyCam we had a hypervisor crash and was brought back with the same name
18:11:38 NobodyCam the error is from a openstack server create with --AZ nova:<Host_fqdn> blah
18:12:20 NobodyCam I only see one entry for the host in resource_providers
18:14:01 melwitt oh, this sounds familiar
18:14:23 NobodyCam hum seem I'm missing something:

Earlier   Later