| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 18:49:47 | johnthetubaguy | oomichi: so for host.host, we needed it for all of them | |
| 18:50:02 | oomichi | johnthetubaguy: like multiple paramters in a single object? | |
| 18:50:17 | johnthetubaguy | oomichi: like "host" appears twice | |
| 18:50:18 | oomichi | johnthetubaguy: ah, nice sample :) | |
| 18:50:36 | mriedem | we have that all over, like networks.port | |
| 18:50:42 | mriedem | block_device_mapping_v2.boot_index | |
| 18:51:03 | sterdnotshaken | Anyone happen to know the answer to my question regarding regions? | |
| 18:51:16 | mriedem | sterdnotshaken: see the channel topic please, | |
| 18:51:29 | mriedem | that's a question better asked in ask.openstack.org, or #openstack, or in the general mailing list | |
| 18:52:21 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add policy-project-checks spec https://review.openstack.org/433037 | |
| 18:53:51 | oomichi | mriedem: yeah, that aslo is a nice sample. "create a server" is super complex API, then it is nice to clarify which object the parameters belong to | |
| 19:03:20 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: WIP: spec about having observer role by default https://review.openstack.org/427872 | |
| 19:04:23 | EmilienM | mriedem: hey! in https://review.openstack.org/#/c/432954/ - do you mean the patch is currently noop? | |
| 19:04:49 | mriedem | EmilienM: no | |
| 19:05:16 | openstack | Launchpad bug 1664334 in OpenStack Compute (nova) "CONF.placement.os_interface is not used in nova-status upgrade check" [Medium,Confirmed] - Assigned to Matt Riedemann (mriedem) | |
| 19:05:16 | mriedem | EmilienM: https://bugs.launchpad.net/nova/+bug/1664334 | |
| 19:06:19 | EmilienM | mriedem: ok, so it's lower priority than nova-compute trying to reach placement, right? | |
| 19:07:06 | mriedem | it's not low priority if you use the nova-status upgrade check command to verify the upgrade and talking to 'public' doesn't work | |
| 19:08:58 | EmilienM | mriedem: I see. Thanks | |
| 19:21:30 | sdague | oomichi: yeh, that was the convention we came up with x.y | |
| 19:21:47 | sdague | we never really explained it a ton, I'm sure the cover docs could be better | |
| 19:23:54 | sneti | mriedem, additional-notification-fields-for-searchlight is reapproved for Pike. can you remove -2 on https://review.openstack.org/#/c/407228/ | |
| 19:23:55 | cfriesen | question for resourcetracker types....is it possible for a sched filter to determine whether a host is running with KVM support vs software qemu? | |
| 19:24:34 | mriedem | cfriesen: if a tree falls in the woods but no one is around to hear it, does it make a sound? | |
| 19:25:35 | mriedem | sneti: done | |
| 19:25:57 | sneti | mriedem, thanks! | |
| 19:29:02 | oomichi | sdague: yeah, that could be better. Now most parameters are not described with x.y. So we will face huge amount of works/patches if we will apply it to all other parts | |
| 19:30:05 | sdague | oomichi: yeh, well, it was never going to be easy to dig out of all the debt here | |
| 19:34:03 | oomichi | sdague: OK, I guess it might be good to have some conversation with doc-team also for consistent api-ref docs of all projects before doing that on all our part | |
| 19:39:08 | sdague | cdent: is there more motivation around this - https://review.openstack.org/#/c/426163/6 ? I don't actually understand why there would be multiple registrations of the endpoint | |
| 19:41:29 | cdent | sdague: when that was proposed there was some discussion in IRC about that, about why have the interface notion at all, etc. And the gist of why it ended up in was "this is how we do things in our cloud, we do use, across the board the concept of different interfaces for the same server" and | |
| 19:42:09 | cdent | because resource tracker and scheduler's use of placement went out with no way to declare the interface, it defaulted to doing "public" | |
| 19:42:13 | cdent | evidently | |
| 19:42:21 | mriedem | https://docs.openstack.org/developer/keystoneauth/using-sessions.html | |
| 19:42:26 | mriedem | interface: the network exposure the interface has. This will be one of: public: An endpoint that is available to the wider internet or network. internal: An endpoint that is only accessible within the private network. admin: An endpoint to be used for administrative tasks. | |
| 19:42:49 | mriedem | the docs make it sound as though it's not free-form | |
| 19:42:52 | cdent | so fixing it meant expose the interface concept | |
| 19:42:56 | mriedem | maybe it's not meant to be | |
| 19:42:58 | cdent | and yeah, what mriedem jus said | |
| 19:44:14 | sdague | it's definitely 100% free form | |
| 19:44:43 | cdent | free form in keystone, but apparently not in the keystoneauth docs? | |
| 19:44:46 | sdague | public, internal, admin is basically as rax taxonomy that made it's way to devstack | |
| 19:44:53 | mriedem | apparently it can also be 'auth' | |
| 19:44:53 | sdague | cdent: it's freeform in keystoneauth code | |
| 19:45:17 | mriedem | https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/base.py#L173 | |
| 19:45:48 | cdent | the fact that there is a default is the pain issue, right? | |
| 19:46:01 | sdague | cdent: no, that it's a limitted list | |
| 19:46:24 | mriedem | well the original problem was it's not configurable in nova | |
| 19:46:25 | sdague | mriedem: I do get that doc is there, that doc is wrong | |
| 19:46:26 | cdent | sdague: I'm not talking about in the fix to add the config, I mean in the bug | |
| 19:47:15 | sdague | mriedem: I guess, it seems very weird to say that for a service that doesn't need a data fast path to have any values other than public | |
| 19:47:55 | sdague | and it just perpetuates some really fuzzy ideas of what is going on there | |
| 19:48:14 | cdent | andymccr: you around? | |
| 19:48:30 | mriedem | https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L178 | |
| 19:48:47 | mriedem | https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L297 | |
| 19:49:02 | mriedem | i'm not sure where the public is mapped to publicURL with the service catalog in ksa | |
| 19:49:19 | sdague | it's on the v2 normalize_endpoints | |
| 19:49:39 | sdague | because in v2 the convention used in devstack (inherited from rax) was publicURL, adminURL, internalURL | |
| 19:49:45 | mriedem | ah | |
| 19:49:45 | mriedem | https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L245 | |
| 19:54:05 | sdague | mriedem: so, yeh, the docs are wrong | |
| 19:54:23 | cdent | wat now? | |
| 19:54:45 | mriedem | so we either revert the change altogether and always assume/require public, | |
| 19:54:49 | mriedem | or just ease that choices limitation | |
| 19:55:19 | mriedem | as noted earlier in here with john, we have a way to configure this for all other services that nova talks to | |
| 19:55:26 | mriedem | one way or another | |
| 19:57:12 | cdent | This is why I wish andymccr was here. He was pretty keen on wanting different interfaces available. | |
| 19:57:36 | mriedem | EmilienM might be able to enlighten us | |
| 19:57:37 | cdent | So I would guess easing the choices limitation, otherwise his deployment won't work. | |
| 19:57:41 | mriedem | since this seems to be a tripleo requirement | |
| 19:59:16 | EmilienM | andymccr is working on OpenStack Ansible project | |
| 19:59:37 | cfriesen | for embedding the flavor data within the server details, if the policy forbids the user from listing extra_specs, should we just not print anything at all or should we print an error message in the extra_specs field? | |
| 19:59:52 | mriedem | cfriesen: isn't not an error, | |
| 19:59:55 | mriedem | you just omit the extra specs | |
| 20:00:18 | mriedem | that's how it works with returning host/node in server GET today | |
| 20:00:22 | cfriesen | it's an error if they try to list a flavor | |
| 20:00:23 | mriedem | if you're not an admin | |
| 20:00:43 | cfriesen | ERROR (Forbidden): Policy doesn't allow os_compute_api:os-flavor-extra-specs:index to be performed. (HTTP 403) (Request-ID: req-fefc3996-8307-428e-9142-aceaa0aa4c88) | |
| 20:00:44 | EmilienM | mriedem: how can I help? (lot of scrollback) | |
| 20:00:58 | mriedem | https://review.openstack.org/#/c/432954/ | |
| 20:01:03 | cfriesen | mriedem: that's if you try to list the flavor | |
| 20:01:07 | cfriesen | show the flavor | |
| 20:01:35 | mriedem | cfriesen: i think that's fine when someone not authorized to that flavor specifically tries to show it | |
| 20:01:51 | mriedem | if i own the server by not the flavor, then show me what i can see about the flavor in general | |
| 20:01:59 | mriedem | extra specs are an admin thing by default | |
| 20:02:05 | cfriesen | mriedem: okay, but silently omit the extra_specs? | |
| 20:02:15 | mriedem | but i can certainly do nova flavor-show 1 as non-admin | |
| 20:02:17 | mriedem | yes | |
| 20:03:02 | EmilienM | sdague, mriedem: are you going to revert something in master? (context: https://review.openstack.org/#/c/432954/1/nova/conf/placement.py= | |
| 20:03:11 | cfriesen | mriedem: if you do " nova flavor-show 1" as non-admin, and there are extra-specs in the flavor, you get that error | |
| 20:03:17 | mriedem | EmilienM: trying to determine how much someone needs to control that interface | |
| 20:03:21 | mriedem | i thought it was a tripleo requirement | |
| 20:03:31 | EmilienM | it's not a "tripleo" requirements | |
| 20:03:44 | EmilienM | real deployments don't want nova-compute to reach public endpoint | |
| 20:04:10 | EmilienM | andymccr is from rackspace/ansible and has the same requirement as we have in tripleo. It just comes from real world | |
| 20:04:32 | mriedem | yeah i know we allow this when nova connects to other services, configuring which endpoint or url i mean | |
| 20:04:57 | sdague | EmilienM: I think it's a little bit of a misunderstanding of the meaning that field has | |
| 20:05:15 | EmilienM | I'm just interested to know if you'll keep this parameter in place or if we have to workaround by creating publicURL with an internal ip | |
| 20:06:08 | mriedem | sdague: i think we keep the config option in place but remove the choices restriction, yes? | |
| 20:06:26 | mriedem | i'm already working on a change to use this in nova-status since that was missed, along with tests | |