[Expired for Keystone because there has been no activity for 60 days.]
** Changed in: keystone
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1091121
You're running in debug mode :)
Set debug = false in keystone.conf and the details of authentication
failures will be suppressed.
** Changed in: keystone
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subsc
While this v2 API is still not implemented AFAIK, we've introduced the
ability to list roles between user-project pairs, group-project pairs,
user-domain pairs, and group-domains pairs... which obviously goes well
beyond the murky functionality of this v2 call.
** Changed in: keystone
Statu
Unassigning as I assume this isn't being pursued anymore.
With the introduction of oslo, this sounds like a great common
middleware that could be deployed on top of any openstack service as
needed.
** Changed in: keystone
Status: In Progress => Won't Fix
** Changed in: keystone
Assig
I'd be happy to see the identity API amended with an acknowledged
("reserved") list of credential types, but there's no way for keystone
to enforce or validate that list, as it would break deployments
attempting to use proprietary types, or from existing deployments to
support future clients, etc.
This appears to be two separate issues, the first of which is by design.
Users do not have roles without requesting authorization on a tenant,
but we're working towards supporting domain-admins, etc, to make the
semantic more meaningful.
On the second issue by "show a warning", are you referri
Dolph - there's still a keystone.middleware.auth_token module in there
for compatibility. I suspect it's broken because keystone.config
registers CLI options
Either needs to be removed or fixed, I guess
** Changed in: keystone
Status: Invalid => Confirmed
--
You received this bug notific
Sounds like this is resolved? auth_token has been moved to
keystoneclient in Grizzly.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.lau
Reassigning to python-quantumclient, since the bug and fix are in that
project.
** Also affects: python-quantumclient
Importance: Undecided
Status: New
** Changed in: python-quantumclient
Importance: Undecided => High
** Changed in: python-quantumclient
Status: New => In Prog
The KeyError here is indicating that your public_url contains something
like %(tenant-id)s which should instead be %(tenant_id)s
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Marking as wont-fix since this is a mysql permissions issue; if this
hasn't been resolved, I'd suggest pinging the mailing list.
** Changed in: keystone
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Reviewed: https://review.openstack.org/23454
Committed:
http://github.com/openstack-dev/devstack/commit/2920b7decc6769707ea45552c94864701c55988e
Submitter: Jenkins
Branch:master
commit 2920b7decc6769707ea45552c94864701c55988e
Author: Devananda van der Veen
Date: Mon Mar 4 11:47:14 2013 -0
I'm not quite sure what the bug is here (what's "invalid"?) but I'm
hoping the following will resolve any confusion:
- Ideally unversioned endpoints should be provided to keystone, which in turn
passes them to clients.
- The service catalog should not have any awareness of versioned endpoints
- C
Reviewed: https://review.openstack.org/23666
Committed:
http://github.com/openstack/tempest/commit/e14e5a47253bbe43fc5d265dc8907993b58b5314
Submitter: Jenkins
Branch:master
commit e14e5a47253bbe43fc5d265dc8907993b58b5314
Author: Attila Fazekas
Date: Wed Mar 6 07:52:51 2013 +0100
Have
The user running keystone should (in *most* cases) not be capable of
creating and properly assigning permissions to the non-existant
directory.
I'd also argue that the currently provided error message is fairly
explicit in indicating that the directory is not writable (No such file
or directory: '
>From the cited link: "Names of built-in functions are permitted as
identifiers but may require care to be used as such." "A reserved word
can be used as an identifier if you quote it."
** Changed in: keystone
Status: New => Won't Fix
--
You received this bug notification because you are
Managers act as common proxies to drivers. See
keystone.catalog.core.Manager for an example of their value.
** Changed in: keystone
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://
Moving this issue to a BP:
https://blueprints.launchpad.net/keystone/+spec/keystone-manage-token-
flush
** Changed in: keystone
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://
Marking this as wont-fix because A) we can't really change that API
anymore, and B) v3 has been implemented with a /v3/credentials API,
which is (in part) intended to replace the EC2 v2 extension along with
pluggable auth (we also haven't implemented an ec2 plugin yet). The
above google doc has mov
Domains, services and endpoints support 'enabled' on v3. Credentials and
groups do not. I'm not sure there's any value in toggling an
enable/disable on those entities? Either way, this should be a BP
explaining the desired impact of disabling those entities.
** Changed in: keystone
Status:
Moved to will not fix, since it is an issue in XenServer not OpenStack
** Changed in: nova
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/
Public bug reported:
The backport for bug #1102504 didn't cover creating a subnet from a
network details page (as opposed to using the "Create network" button on
the Networks page). This makes the experience a bit inconsistent, where
sometimes the user will be prevented from creating a single IP s
Marking this as invalid for keystone as I believe this issue was caused
by keystoneclient and is now fixed. Please re-open if I'm mistaken.
** Changed in: keystone
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which i
Marking this as invalid because I think this is expected behavior for
keystone. If a user does get themselves into this situation, the static
admin_token defined by keystone.conf is intended exactly for this
scenario- bootstrapping an admin user (or in this case, re-bootstrapping
an admin user).
*
This is not really under our control (part of novnc rather than nova),
and not really a info leak (everyone can tell what the listing will be),
so I'm opening this up and closing as Invalid. Feel free to reopen if
you disagree.
** Information type changed from Private Security to Public
** Change
Reviewed: https://review.openstack.org/23637
Committed:
http://github.com/openstack/openstack-manuals/commit/264f05128ef3aef68663b8e49bd5bef1de145d90
Submitter: Jenkins
Branch:master
commit 264f05128ef3aef68663b8e49bd5bef1de145d90
Author: Michael J Fork
Date: Wed Mar 6 00:54:24 2013 +
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => grizzly-3
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/861854
Title:
27 matches
Mail list logo
