Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-13
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 mriedem EmilienM: https://bugs.launchpad.net/nova/+bug/1664334
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: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 sdague cdent: it's freeform in keystoneauth code
19:44:53 mriedem apparently it can also be 'auth'
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 https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L245
19:49:45 mriedem ah
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
20:06:27 EmilienM mriedem: maybe keep documentation of what users can configure
20:06:28 cdent the original intent when we established some patterns in placement was that we'd only only ever have one endpoint for service, not use ports in the service catalog and generally do the tidy-service-catalog stuff we've been talking about for a long time. That intent has had some collisions with reality, which is to be expected.
20:07:20 cdent i'd vote for keep config, remove choices restriction
20:07:30 EmilienM and document what users can configure

Earlier   Later