Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-13
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
20:07:58 sdague mriedem: it's possible, but I also feel like this is a reasonable place to actually try to hold the line on the fact that interface is meaningless. Because there was some desire to actually come up with better ways to describe what that was going for.
20:08:49 sdague Honestly, ideally, keystoneauth would default to None, and just use whatever is specified if there was only one.
20:08:55 mriedem i thought the point of the interface on the different endpoints was so you could expose the APIs on different networks?
20:09:18 mriedem i.e. internal vs public
20:10:47 sdague mriedem: ok, but in the case of the placement API, what are those?
20:11:11 mriedem idk, they're all admin as far as i know
20:11:25 sdague so I get that public might be an "internal" ip here, but I actually am not sure I udnerstand the usecase for 2 different bindings of placement API
20:11:31 mriedem the only things talking to it are nova, neutron (routed networks), and the admin scripting stuff for shared storage and other things at some point
20:11:39 mriedem sdague: also https://github.com/openstack/keystone/blob/master/keystone/catalog/schema.py#L94
20:11:44 cdent so far
20:11:54 cdent plans for things like horizon-like dashboards of usage
20:12:02 mriedem sdague: the keystone api schema seems to enforce those 3 values

Earlier   Later