| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-27 | |||
| 14:12:04 | mriedem | dansmith: ok i think i remember now | |
| 14:12:09 | mriedem | it's the PUT /os-services APIs | |
| 14:12:23 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=add-host-detail,enable-scheduling-for-a-compute-service-detail#enable-scheduling-for-a-compute-service | |
| 14:12:28 | mriedem | they don't take an id | |
| 14:12:31 | mriedem | the body contains a host | |
| 14:12:35 | mriedem | *hostname | |
| 14:12:54 | mriedem | that's when i started asking about if we could have collisions there and john said we could | |
| 14:13:06 | mriedem | don't ask me how | |
| 14:13:22 | dansmith | mriedem: okay I totally don't understand how, but I'll put this up and hopefully he'll show up | |
| 14:13:37 | mriedem | anywho, as part of the spec we're collapsing those garbage PUT APIs into a single PUT with a service uuid in the path | |
| 14:13:57 | mriedem | so | |
| 14:13:58 | mriedem | PUT /os-services/disable { "host": "host1", "binary": "nova-compute" } | |
| 14:14:00 | mriedem | becomes | |
| 14:14:04 | mriedem | PUT /os-services/{service_id} { "status": "disabled" } | |
| 14:14:12 | mriedem | where service_id is a uuid | |
| 14:14:28 | mriedem | having said all that, i think we're fine with what you're proposing :) | |
| 14:14:39 | mriedem | we == me and the turd in my pocket | |
| 14:15:02 | dansmith | ack, yep | |
| 14:42:16 | openstackgerrit | Dan Smith proposed openstack/nova master: re-Allow adding computes with no ComputeNodes to aggregates https://review.openstack.org/460616 | |
| 14:54:22 | mriedem | hmm, isn't it possible to override a mock? | |
| 14:54:35 | mriedem | like if the test class does a global mock of something but a test case wants to override it | |
| 14:54:49 | mriedem | i thought just decorating the test case would override the mock from the test class... | |
| 14:54:52 | mriedem | but apparently not | |
| 14:58:35 | artom | mriedem, maybe explicit assignment will work? | |
| 14:58:58 | artom | nova.stuff.moar = mock.Mock() | |
| 14:59:21 | zioproto | mriedem: in the table block_device_mapping what is the column no_device for ? for one attachment I have value 0 and for the other NULL | |
| 15:03:20 | openstackgerrit | Béla Vancsics proposed openstack/nova master: [WIP] Transform aggregate.update_metadata notification https://review.openstack.org/460625 | |
| 15:03:37 | mriedem | zioproto: good question | |
| 15:03:47 | mriedem | zioproto: let me consult my tome of bdm fields | |
| 15:08:12 | mriedem | not doc'ed in the api | |
| 15:08:24 | mriedem | schema says it could be a dict in the api? | |
| 15:08:38 | mriedem | but it's treated like a boolean, | |
| 15:08:43 | mriedem | it's definitely some legacy bdmv1 thing | |
| 15:09:15 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/block_device_mapping_v1.py#L34 | |
| 15:10:10 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2969 | |
| 15:14:15 | mriedem | boolean in the object model https://github.com/openstack/nova/blob/master/nova/objects/block_device.py#L85 | |
| 15:14:47 | mriedem | boolean in the data model https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L622 | |
| 15:16:31 | mriedem | zioproto: i'm not really sure what the hell it means, | |
| 15:16:40 | mriedem | but it looks like maybe your customer did a swap volume operation on that instance? | |
| 15:16:48 | mriedem | because that sets 'no_device': None | |
| 15:16:49 | mriedem | in the bdm | |
| 15:18:06 | zioproto | possible | |
| 15:18:06 | zioproto | also | |
| 15:18:09 | zioproto | I dont understand | |
| 15:18:15 | zioproto | why when I attach this volume | |
| 15:18:20 | zioproto | the device is /dev/hda | |
| 15:18:26 | zioproto | this is the attachment | |
| 15:18:34 | zioproto | where this /dev/hda is generated from ? | |
| 15:19:05 | mriedem | zioproto: should be from nova/virt/libvirt/blockinfo.py i think | |
| 15:19:59 | mriedem | see find_disk_dev_for_disk_bus | |
| 15:23:33 | mriedem | mdbooth: god i'd love to remove all of this bdm v1 code | |
| 15:23:56 | mdbooth | mriedem: Hehe | |
| 15:24:03 | zioproto | I try with command line to force /dev/sdb | |
| 15:24:08 | zioproto | but it ignores me | |
| 15:24:16 | mriedem | zioproto: the libvirt driver ignores the device name you pass in | |
| 15:24:22 | mriedem | when attaching a volume, or booting from volume | |
| 15:24:30 | mdbooth | mriedem: How would we deprecate it? | |
| 15:24:42 | lyarwood | with fire? | |
| 15:24:47 | zioproto | but there must be a bug that assigned this /dev/hda name | |
| 15:24:52 | mriedem | mdbooth: i think we'd start by deprecating the legacy bdm v1 fields in the api | |
| 15:24:55 | zioproto | cant be both /dev/sda and /dev/hda | |
| 15:25:17 | mdbooth | lyarwood: Well the mechanism would be to take off and nuke it from orbit, of course. I meant the prior communication. | |
| 15:25:42 | mriedem | mdbooth: but that's like microversion 2.50 at this point, and unless we raise minimum microversions in the api that never goes away, | |
| 15:25:50 | mriedem | and even if we did, it would probably take a long time before we could remove it | |
| 15:26:11 | mriedem | zioproto: so the guest xml says it's /dev/sda? | |
| 15:26:19 | mriedem | but the bdm attachment table shows it as hda? | |
| 15:26:26 | sfinucan | sdague: If I want to capture logging, which fixture do I need to use? | |
| 15:26:47 | mriedem | zioproto: can you tell if they performed a swap volume on the instance? there should be an instance action recorded for it | |
| 15:26:58 | sfinucan | I saw a comment on one of mriedem's patches to not mock oslo.log, but I can't find said patch | |
| 15:27:31 | mdbooth | sfinucan: Interesting. I was about to say I've just mocked the log object before. | |
| 15:27:46 | mriedem | zioproto: actually it looks like we don't record an instance action event for swap volume | |
| 15:27:47 | mriedem | damn | |
| 15:28:04 | zioproto | I know that this volume was imported, not created with openstack | |
| 15:28:12 | mriedem | sfinucan: mdbooth: OutputStreamCapture i htink | |
| 15:28:14 | mriedem | *think | |
| 15:28:20 | mriedem | zioproto: imported? | |
| 15:28:22 | mriedem | via cinder? | |
| 15:28:23 | zioproto | it is some machine converted from vmware or something | |
| 15:28:30 | sfinucan | mriedem: ta | |
| 15:29:02 | mdbooth | mriedem: volume-only image? | |
| 15:29:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377 | |
| 15:30:09 | sdague | sfinucan: actually, I think we buried the hook for that | |
| 15:31:00 | mriedem | sfinucan: i was actually curious too which fixture sdague was talking about | |
| 15:31:04 | mriedem | since we have a few that seem related | |
| 15:31:06 | sdague | nova_fixtures.StandardLogging() would give us a fixture with self.logger that we can pull on | |
| 15:31:16 | sdague | but we didn't assign a reference to get back to it | |
| 15:31:48 | mriedem | so the base test case needs to store self.logger = self.useFixture(nova_fixtures.StandardLogging()).logger? | |
| 15:31:50 | mriedem | right? | |
| 15:32:04 | mriedem | and then i can do self.assertIn('foo', self.logger.info)? | |
| 15:32:23 | johnthetubaguy | mriedem: dansmith: was the ping I missed about the duplicate hostnames thing in os-services? I think I was really asking about FQDN vs hostname. There wouldn't be duplicate FQDNs. | |
| 15:32:33 | mriedem | oh self.logger.output | |
| 15:32:50 | dansmith | johnthetubaguy: okay, when do we use hostnames that aren't fqdns? | |
| 15:32:50 | openstackgerrit | Sean Dague proposed openstack/nova master: Expose StandardLogging fixture for use https://review.openstack.org/460642 | |
| 15:32:57 | dansmith | johnthetubaguy: not for service registration, AFAIK | |
| 15:33:04 | sdague | mriedem: or that ^^^ | |
| 15:33:30 | johnthetubaguy | dansmith: oh, I thought we default to hostname rather than fqdn, that might just be me getting all mixed up | |
| 15:33:41 | dansmith | johnthetubaguy: not that I've ver seen | |
| 15:33:41 | sdague | mriedem: I thought it had gotten exposed | |
| 15:34:01 | sdague | but apparently not, but there is a whole mechanism for it being captured, so we should us that instead of mocks | |
| 15:34:03 | zioproto | mriedem: so it was two disks from vmware. We converted this disks to glance images, and then to cinder volumes. | |