| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-09 | |||
| 19:29:10 | mriedem | cfriesen: not via the REST API i don't think so | |
| 19:29:16 | mriedem | we had a spec proposed in mitaka for this... | |
| 19:29:18 | mriedem | i'll dig it up | |
| 19:29:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Remove main_db flavor compatibility https://review.openstack.org/431722 | |
| 19:29:51 | mriedem | cfriesen: https://review.openstack.org/#/c/265282/ | |
| 19:30:05 | mriedem | basically i think the idea was, add GET /servers/<server_id>/flavor | |
| 19:30:37 | mriedem | cfriesen: mayhap you want to dust that off for pike | |
| 19:31:56 | cfriesen | mriedem: sweet, thanks. | |
| 19:32:46 | mriedem | let me know if you want me to restore that | |
| 19:33:43 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Remove unused validation code from block_device https://review.openstack.org/410006 | |
| 19:34:13 | cfriesen | mriedem: I'll have to talk to some folks here. looks useful though. | |
| 19:34:33 | mriedem | cfriesen: it might be easier than whatever fork you're cooking up :) | |
| 19:35:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run api sample tests against 2.latest https://review.openstack.org/430352 | |
| 19:35:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Use unique volume id in fake_volume https://review.openstack.org/431723 | |
| 19:36:12 | cfriesen | mriedem: we've got a longstanding private patch to prevent deleting or modifying flavors that are in-use, was just wondering if it was worth porting it. I like that spec better long-term. | |
| 19:36:39 | mriedem | cfriesen: why would deleting or modifying them if they are in use matter since nova stores the original? | |
| 19:37:00 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Update hacking version https://review.openstack.org/389338 | |
| 19:37:20 | cfriesen | mriedem: the patch was originally introduced before nova stored the original, so stuff actually broke. currently it's mostly there to allow end users to see what the instance actually booted with since something like that spec doesn't exist yet. | |
| 19:37:35 | mriedem | ok | |
| 19:37:45 | mriedem | cfriesen: did you guys just get to newton? | |
| 19:37:54 | dansmith | cfriesen: nova never allowed you to update flavors | |
| 19:37:56 | mriedem | because you know we dropped api extensions in newton right? | |
| 19:38:02 | cfriesen | mriedem: yep, and yep | |
| 19:38:03 | mriedem | dansmith: i think he means extra specs | |
| 19:38:04 | dansmith | cfriesen: you could only soft-delete and re-create | |
| 19:38:07 | dansmith | ah | |
| 19:38:11 | mriedem | cfriesen: so you guys reverted the extension disabled patch? | |
| 19:38:38 | mriedem | you don't have to answer, but i'm interested | |
| 19:38:44 | mriedem | because i figured people would do that | |
| 19:38:49 | dansmith | hah | |
| 19:38:50 | dansmith | I can rephrase if you want | |
| 19:39:03 | dansmith | cfriesen: so you guys are officially committing original openstack sin now right? | |
| 19:39:15 | cfriesen | mriedem: It's actually been other guys doing the port, I'm just starting to look at it. Not actually sure what they did. | |
| 19:39:26 | mriedem | it's always the other guys | |
| 19:39:27 | mriedem | psh | |
| 19:39:29 | mriedem | :P | |
| 19:39:31 | cfriesen | dansmith: private patches? | |
| 19:39:38 | dansmith | cfriesen: against the api? yeah :) | |
| 19:39:52 | mriedem | changing the api is interop sin | |
| 19:40:00 | mriedem | if you don't care about interop, then sin away | |
| 19:40:13 | mriedem | we all know canada is rife with sinners | |
| 19:40:19 | dansmith | and if you don't care about killing the rest of the world's interop bunnies | |
| 19:40:26 | dansmith | mriedem: true story | |
| 19:40:38 | mriedem | sinners that just can't get enough denim! | |
| 19:41:03 | cfriesen | dansmith: mriedem: yeah, I know. currently interop isn't a bit deal, the people that want the extra features are already locking themselves in. Personally I want to add an orthogonal vendor API microversion so that we would give vanilla behavior to vanilla clients. Havent' got resources for it though. | |
| 19:42:29 | cfriesen | mriedem: do you know if sdague ever had code for that Mitaka spec? | |
| 19:43:15 | sdague | cfriesen: I did not, we kept kind of going around in circles about the data stored in it | |
| 19:43:28 | melwitt | I had been thinking extra_specs showed on a 'nova show'. guess not | |
| 19:43:32 | mriedem | oomichi: on https://review.openstack.org/#/c/410006/ i don't see an existing test that handles the bdm boot_index schema | |
| 19:43:58 | sdague | because, after looking into it more in depth, it was actually going to be less API calls, less wire data, and less confusing to just include those attributes inline in the server response | |
| 19:44:36 | cfriesen | melwitt: sdague: yes, was wondering about that...just adding the extra-specs to the "nova show" output | |
| 19:44:38 | sdague | although, I guess if we had extra specs merged in it might get messy | |
| 19:44:55 | sdague | I don't know full, it needs someone to ponder the implications | |
| 19:44:59 | mriedem | plus aren't extra specs hidden from non-admin? | |
| 19:45:08 | mriedem | maybe that doesn't matter here | |
| 19:45:23 | sdague | mriedem: it's fine if there are multiple visibility layers here I think | |
| 19:45:23 | mriedem | we're going to show them or not show them regardless of where we dump the flavor | |
| 19:45:30 | sdague | right | |
| 19:45:34 | melwitt | could still make it admin on a nova show, if that's the case | |
| 19:45:38 | mriedem | yeah | |
| 19:45:51 | mriedem | i like to say things before i think | |
| 19:46:28 | melwitt | I can't remember if we ever updated 'nova show' to show the flavor stored on the instance instead of looking it up | |
| 19:46:41 | mriedem | melwitt: we don't look it up | |
| 19:46:47 | melwitt | *instead of looking it up in the flavors table I mean | |
| 19:46:56 | mriedem | we pull it from the instance | |
| 19:47:13 | melwitt | okay cool. so no more disappearing flavor on nova show after deleting a flavor | |
| 19:47:17 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L248 | |
| 19:47:29 | melwitt | nice | |
| 19:47:29 | cfriesen | mriedem: are you suggesting that "nova flavor-list --extra-specs" doesn't work if you're not admin? | |
| 19:47:45 | melwitt | okay, so yeah it seems like extra_specs could be added there, guarded by policy | |
| 19:48:09 | melwitt | (assuming it's already currently guarded by policy) | |
| 19:48:24 | mriedem | cfriesen: i guess i haven't tried | |
| 19:48:43 | cfriesen | mriedem: looks like maybe it's governed by policy: "compute_extension:flavorextraspecs:index": "rule:admin_or_owner" | |
| 19:49:03 | mriedem | and since only admins can create flavors by default, it'd be admin-only by default | |
| 19:49:38 | cfriesen | mriedem: I was wondering whether it might be readonly for regular users, to let them determine which flavors have the right extra-specs | |
| 19:50:12 | cfriesen | in our environment at least extraspecs create/update/delete is admin-only | |
| 19:51:05 | artom | Oh hey that's smart - if you only change the unit tests Jenkins doesn't all of CI, just the unit tests | |
| 19:51:18 | mriedem | artom: same for docs | |
| 19:51:47 | artom | mriedem, I knew about docs because dansmith mentioned it previously | |
| 19:54:38 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Reno for additional-notification-fields-for-searchlight https://review.openstack.org/428835 | |
| 19:56:18 | Guest72572 | Hi, I have a question about pci_whitelist_entry which are put in the nova.conf on the compute node. | |
| 19:57:00 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Remove unused validation code from block_device https://review.openstack.org/410006 | |
| 19:57:10 | oomichi | mriedem: nice point, thanks. done on ^^^ | |
| 19:57:15 | Guest72572 | is there a way / log which prints the compute node is correctly advertising its capabilities to the nova-scheduler that it has the desired number of VF's so that SRIOV ports can be created on this node ? | |
| 19:58:15 | Guest72572 | Cause, you get a generic error saying, "No Valid host found". So does any one know here if there are any logs which can help to debug this problem ? | |
| 19:59:46 | cfriesen | Guest72572: have you enabled debug logs in nova-scheduler? | |
| 20:07:22 | Guest72572 | cfriesen: Yes | |
| 20:07:55 | Guest72572 | The conductor itself will report that no valid host is found. Though I have setup sufficient VF's on the compute node. | |
| 20:13:06 | cdent | Guest72572: I seem to remember a bug that sounds a bit like this. What version are you? | |
| 20:13:15 | Guest72572 | @cfriesen: Is there any specific log that I should look for ? | |
| 20:14:19 | Guest72572 | Actually I'm using contrail distro. But the things is, I can see this for just one compute node. I works on other compute node. | |
| 20:14:54 | Guest72572 | *it works on other compute nodes. | |
| 20:15:34 | Guest72572 | So I'm trying to figure out, how to debug this , as in to find out if the compute node is correctly advertising these things or not. | |
| 20:16:57 | cdent | Guest72572: have you dug around in the n-cpu log for the failing compute node? | |
| 20:17:36 | cdent | it's responsible for auditing it's own resources | |
| 20:18:14 | Guest72572 | @cdent: Where can I find this log file ? | |
| 20:18:26 | Guest72572 | n-cpu log | |
| 20:18:27 | cdent | on the compute node itself | |
| 20:18:44 | cdent | what it is called and where it is depends a lot on how things were installed | |
| 20:18:54 | cdent | but if you've got a /var/log/nova, it's probably in there | |