Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-17
17:40:27 mriedem yeah i remember we talked about it too, glad it's in the spec
17:41:10 dansmith um, is it?
17:41:16 dansmith the --deleted thing is mentioned there
17:41:21 dansmith --all-tenants is a little different
17:41:47 mriedem "Filters: If the user is listing servers using filters the results from the down cell will be skipped and no minimalistic construct will be provided since there is no way of validating the filtered results from the down cell if the value of the filter key itself is missing. "
17:41:57 mriedem so like if i'm filtering on status or something
17:42:09 mriedem we said in the spec we'd just ignore what's in down cells since we can't know
17:42:22 dansmith right
17:42:23 dansmith for filters
17:42:24 dansmith but your point was --all-tenants right?
17:42:31 mriedem that's one of them
17:42:37 mriedem and not called out specifically
17:42:44 mriedem for --all-tenants,
17:42:51 mriedem i'd think we could just list all instance mappings in down cells,
17:42:54 mriedem not filtered on project_id
17:43:03 mriedem up to whatever limit
17:49:31 mriedem so apparently filtering on project_id only works if you're also using all_tenants
17:49:37 mriedem otherwise we just filter on the context.project_id
17:50:42 dansmith um, what?
17:51:15 dansmith meaning --all_tenants is required in order to say --but-only-this-one ?
17:51:26 mriedem https://github.com/openstack/nova/blob/9c5d4eb2008df02837985779d87fedb17b4f70bf/nova/api/openstack/compute/servers.py#L206L248
17:51:29 mriedem yes...
17:52:32 dansmith hmm
18:24:58 openstackgerrit Jack Ding proposed openstack/nova master: Add I/O Semaphore to limit concurrent disk ops https://review.openstack.org/609180
18:32:31 awaugama mriedem: when you have a chance, it looks like the value is set on the compute node. after a reboot I saw this in the nova-compute log
18:32:34 awaugama 2018-10-17 17:44:00.277 1 DEBUG oslo_service.service [req-c9c4f04c-cfc6-4fe3-868d-206f9329419d - - - - -] cpu_allocation_ratio = 1.0 log_opt_values /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3023
18:33:15 mriedem jroll: where in the ironic API reference would one find anything about conductor_groups? https://developer.openstack.org/api-ref/baremetal/
18:33:33 mriedem i mean i see https://docs.openstack.org/ironic/latest/contributor/webapi-version-history.html#rocky-11-1-0
18:33:37 mriedem but nothing in the API reference
18:34:21 jroll mriedem: apparently I forgot to update that when I added it :(
18:34:26 mriedem awaugama: ok so it's 1.0 in config, it's 1.0 in the compute_nodes.cpu_allocation_ratio column in the db, but it's 16.0 in the associated resource provider VCPU inventory in placement
18:34:36 awaugama yeah
18:34:46 mriedem well wtf
18:34:49 jroll mriedem: it would be in node CRUD as its own field, I'll get that done real quick
18:34:56 mriedem jroll: a uuid or what?
18:35:33 mriedem jroll: and you can update a node's conductor_group?
18:35:34 jroll mriedem: a string, up to 255 characters IIRC: https://github.com/openstack/ironic/blob/b8ffcc0f0298fca5b4b36ad016e2c3b2f0e81710/ironic/common/utils.py#L530
18:35:45 mriedem ok so it's just some tag
18:35:50 awaugama I'll sit down with sylvain tomorrow and we can do some debugging, will let you know if we find anything
18:35:51 mriedem special tag
18:35:52 jroll yeah
18:36:10 jroll alphanumeric, plus - _ .
18:42:25 artom - _ . is what I look like after a few drinks
18:42:52 jroll hah
18:53:13 jroll mriedem: api-ref for you https://review.openstack.org/611415
18:53:49 openstackgerrit Artom Lifshitz proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587
18:58:05 mriedem jroll: i've brought the wrath
18:58:47 dansmith hrm, pretty sure this functional timeout on the down cell series is a real deadlock on our cell cache
18:59:11 jroll mriedem: thanks, valid points
18:59:46 jroll for context I haven't touched our API ref in a long time :P
19:00:26 mriedem ugh
19:00:39 mriedem so GET /v1/nodes/detail is deprecated for GET /v1/nodes?detail=True,
19:01:00 mriedem but the request filter and response parameters for the latter don't mention anything possible in the former
19:08:37 jroll I'm not sure it's even properly deprecated
19:08:58 jroll added a note to the detail=True parameter
19:29:28 mriedem so we're deprecating the force flag from the evacuate and live migration apis,
19:29:40 mriedem wouldn't it behoove us to deprecate that as an option from nova commands as well?
19:29:49 mriedem or at least doc it up real good that you shouldn't use it?
19:32:50 artom mriedem, wait, deprecate or remove?
19:33:01 melwitt dansmith: would appreciate your review on mah backport https://review.openstack.org/610673
19:33:05 artom Because for removal the usual novaclient microversion stuff applies, no?
19:34:08 mriedem artom: if we don't want people using the force flag to live migrate or evacuate an instance,
19:34:17 mriedem so much so that we're deprecating the api parameter,
19:34:26 mriedem you could argue that we should not have it in the CLI either
19:34:31 mriedem like, at all
19:34:34 mriedem even for older microversions
19:34:43 artom mriedem, but it still exists for old microversions
19:34:45 artom In the API
19:34:47 mriedem yes i know
19:34:52 artom So, we have to keep client support
19:35:02 mriedem not really
19:35:03 artom So if they specifically --os-compute-version <old>, they have it
19:35:06 artom Otherwise, it's gone
19:35:36 mriedem once all allocations are nested, you won't be able to force at all
19:35:43 mriedem regardless of microversion
19:35:52 mriedem anyway, it was just a thought
19:36:05 mriedem should probably start by putting the big fat warnings in the API reference into the CLI option descriptions
19:36:52 artom mriedem, ah I see. Well we still have to keep the old API intact, no? Just now we'll return a 400 or something.
19:37:04 artom If they send a force flag
19:37:59 mriedem it'll be some kind of error
19:38:04 mriedem don't know if it's a 400 or 409
19:38:07 mriedem it's in gibi's spec
19:40:11 mriedem aspiers: just a few hundred comments in your spec https://review.openstack.org/#/c/609779/
19:43:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix typo in libvirt.hw_machine_type help https://review.openstack.org/611422
19:48:58 openstackgerrit Jack Ding proposed openstack/nova-specs master: High Precision Event Timer (HPET) on x86 guests https://review.openstack.org/607989
19:51:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Document each libvirt.sysinfo_serial choice https://review.openstack.org/611426
19:55:36 artom mriedem, you led me astray, I demand a refund: https://review.openstack.org/#/c/587439/4/nova/tests/unit/compute/test_compute_mgr.py@7439
19:59:55 openstackgerrit Artom Lifshitz proposed openstack/nova master: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/587439
20:00:22 mriedem umm
20:00:27 mriedem what's the point of even asserting those then
20:01:08 artom I guess Matt was trying to make sure we call all of the things? But... in a for loop, because he didn't feel like writing out each individual method name?
20:01:49 mriedem ^O^
20:01:56 mriedem that's me shrugging, not a bat
20:02:24 artom Or a yelling Asian person?
20:02:30 artom (Can I say that? Is that racist?)
20:02:54 mriedem it's very racist
20:03:16 artom Dammit. Hilter 2.0 right here, friends.
20:05:47 openstackgerrit Merged openstack/nova master: Merge used_limits extension response into limit view builder https://review.openstack.org/606031
20:15:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix block_device_mapping_v2 mention in server create API reference https://review.openstack.org/611433
20:34:34 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Recommend against using --force for evacuate/live migration https://review.openstack.org/611436

Earlier   Later