If it is not fixed in Nova it is not fixed in Keystone, as the solution
has to start there.
** Changed in: keystone
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity
The issue seems to be in ovs, specifically this commit
https://github.com/openvswitch/ovs/commit/355fef6f2ccbcf78797b938421cb4cef9b59af13
. I have created a ppa
https://launchpad.net/~gnuoy/+archive/ubuntu/focal-xena/+packages that
has a copy of the openvswitch package from the xena-proposed UCA.
Public bug reported:
Connectivity is fine with OVS 2.15 but after upgrading ovs, connectivity
is lost to remote units over ipv6. The traffic appears to be lost while
being processed by the openflow firewall associated with br-int.
The description below uses connectivity between Octavia units and
THis is an installer specific issue and not with the Keystone upstream
project. The .deb should be creating the /etc/keytstone directory on
install. PLease open the bug with the packager. Note that the page
linked is specific to Ubuntu.
** Changed in: keystone
Status: New => Invalid
The Keystone server was down and the message was reported by the client.
** 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 Identity (keystone).
in: charm-layer-ovn
Status: New => Confirmed
** Changed in: charm-layer-ovn
Importance: Undecided => High
** Changed in: charm-layer-ovn
Assignee: (unassigned) => Liam Young (gnuoy)
--
You received this bug notification because you are a member of Yahoo!
Engineering Te
** Changed in: neutron
Status: Triaged => Fix Committed
** Changed in: nova
Status: In Progress => Fix Committed
** Changed in: puppet-keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
** Also affects: ovn-octavia-provider (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1896603
Title:
ovn-octavia-provider: Cannot
in: nova
Assignee: Liam Young (gnuoy) => (unassigned)
** Changed in: charm-keystone
Assignee: (unassigned) => Liam Young (gnuoy)
** Changed in: charm-nova-cloud-controller
Assignee: (unassigned) => Liam Young (gnuoy)
** Changed in: charm-nova-compute
Status
For these kinds of operations, you use role assignment inheritance. Do
not attempt to enforce policy on parent project ID.
I wrote up an article about this about a year back. CloudForms is just
the consumer, but the rules are the same.
Public bug reported:
Identifiers
Each resource in Keystone has a unique identifier. For the majority of
resources, the identifiers are currently generated as UUIDs. In
addition, the identifiers are assigned by the system, and are not
something an end user can specify when creating the resource.
Public bug reported:
I wrote up the issues with gaming the system that can happen with deep
quotas. This has driven what happened with 2 level quota in unified
limites.
https://adam.younglogic.com/2018/05/tracking-quota/
This should merge in with the documentation to explain why we limit
ResourceProviderRetrievalFailed: Failed to get resource provider
with UUID 4f7c6844-d3b8-4710-be2c-8691a93fb58b
2019-04-25 09:58:12.177 31793 ERROR nova.compute.manager
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Assignee: (unassigned) => Liam Youn
Public bug reported:
Make it possible to know what the ID of a role will be prior to creating
it. This allows synchronization between multiple keystone servers
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
Status: In Progress
--
You received
I don't think this is related to the charm, it looks like a bug in
upstream nova.
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: nova (Ubuntu)
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug
UNtil recently, this should be in bootstrap. This is the minimal amount
of configuration a Keystone server needs: to be able to create a new
domain, or create projects on the domain, etc.
Now it should be one admin user with a service scoped admin role. From
that, all other configuration can
Added Oslo.policy to the bug report, as this is going to be an issue
across all of the projects. Barbican, especially, needs target info,
but the same is true for anything that enforces the scope check.
** Also affects: oslo.policy
Importance: Undecided
Status: New
--
You received
Public bug reported:
THe Federation itegration (not voting) tests for Python35 are failing.
==
2018-09-26 06:26:21.371093 | primary | Failed 1 tests - output below:
2018-09-26 06:26:21.371172 | primary | ==
2018-09-26 06:26:21.371200 |
Public bug reported:
When keeping two Keystone servers in sync, but avoiding Database
replication, it is often necessary to hack the database to update the
Domain ID so that entries match. Domain ID is then used for LDAP mapped
IDs, and if they don't match, the user IDs are different. It should
the user in
LDAP). THus, the LDAP code can be changed at config time, but the
Federated code can't. It also means that Federated IDs cannot be kept
in sync between two keystone servers.
** Affects: keystone
Importance: Low
Assignee: Adam Young (ayoung)
Status: In Progress
Public bug reported:
in keystone/tests/unit/test_v3_auth.py there are two tests that have
been commented out because they are unrunnable:
test_remote_user_with_realm
and
test_remote_user_with_default_domain
These support the External auth mechanism which should be avaialable to
people with
Just to be clear, this has always been the case. THe documentation for
the cloud sample stated it needed to be edited.
Of course, I tripped over this exact problem. A few times. I once
proposed reading policy values from the config file as a work around.
But this is not a bug. As Lance put,
i_database section.
** Affects: nova
Importance: Undecided
Assignee: Liam Young (gnuoy)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) => Liam Young (gnuoy)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
Assignee: Liam Young (gnuoy)
Status: New
** Changed in: nova
Assignee: (unassigned) => Liam Young (gnuoy)
--
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/bugs/1785
Public bug reported:
Looking at a coverage report for the Keystone CLI shows that the
entirety of
class MappingEngineTester(BaseApp):
Is untested. Since this is production and supported code, this is a
risk.
** Affects: keystone
Importance: Undecided
Status: New
--
You
** Changed in: keystone
Status: Invalid => New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1780159
Title:
Some inherited projects missing when listing
** 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 Identity (keystone).
https://bugs.launchpad.net/bugs/1780159
Title:
Some inherited projects missing when listing
I'm closing this Won't fix because running with the LDAP backend is a
bad approach. Use SQL, with LDAP in a domain specific back end.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Public bug reported:
master promotion is being blocked by a failure in periodic-multinode-
1ctlr-featureset017
master: 66b3734b4a57941c2d66dfc7d7961b2925c46b92_e4e594a6
---
http://38.145.34.55/master.log
2018-02-28 20:21:26,221 2381 INFO promoter Skipping promotion of
tripleo-ci-testing
Fixed in Keystone by f71a78db86632dccb391782e62da69a4627c7cad
https://review.openstack.org/#/c/523650/
** Changed in: keystone
Assignee: (unassigned) => Adam Young (ayoung)
** Changed in: keystone
Status: Triaged => Fix Released
** Changed in: keystone
Status: Fix Re
Public bug reported:
Description
===
map_instances seemingly hung for hours on a cloud with ~19 instance
records. I think the following fixes are valid (in order of preference):
1) nova_manage should examine the amount of instances that need mapping and
make an informed choice
Public bug reported:
- [X] This doc is inaccurate in this way: Documentation suggests nova v2 cells
do not make 'upcalls' but they do when talking to the placement api.
- [ ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example:
input and
Public bug reported:
In order to activate a protocol for Federation, you need SOME value for
remote_id_attribute. However , this is set once per protocol in the
config file, not in the federated data. Thus, if two different SAML
implementations both wanted to use different values for
Public bug reported:
When a Federated User logs in for the first time, many organizations
want to be able to provision resources. This is a specific instance of
the general idea that a Keystone token operation should be able to kick
off a playbook. PLaybooks can perform both Openstack specific
Public bug reported:
Keystone is now behind the other projects in reporting the microversions
in the microversion header
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
CLosing as a duplicate.
** 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 Identity (keystone).
https://bugs.launchpad.net/bugs/1648542
Title:
keystone does not
Public bug reported:
Description of problem:
DBDeadlock: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to
get lock; try restarting transaction')
The above error is retry-able error, but no evidence for keystone would
really did a retry before throwing a 500.
2016-11-12
Public bug reported:
ADMIN_PASSWORD=keystone tools/sample_data.sh
... lots of stuff working fine ...
usage: openstack ec2 credentials create [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width ]
Public bug reported:
Web SSO will be broken in places where the ssumption that the AUTH_URL
that Horizon uses is publically accessible.
Conversation with deployer:
"keystone is open in haproxy to the public world, but the problem is
that horizon forming the SSO url based on the region URL,
Public bug reported:
When setting up Federation, if the protocol needs an new auth plugin,
the current mechanism is to add it to the methods list for the [auth]
section. However, this has the effect of linking them all together,
when the real method should be to link the auth plugin with the
Public bug reported:
Active Directory has a very specific mechanism to
handle nested groups. LDAP queries need to look like this:
"(&(objectClass=group)(member=member:1.2.840.113556.1.4.1941:=CN=nwalnut,OU=Users,DC=EXAMPLE,DC=COM))"
If a deployment is using nested groups, three queries need to
Reopening the Keystone one as the fix does not work for default policy,
which is what most people use.
** Changed in: keystone
Status: Fix Released => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Not a bugf, leave the wrapper in for SQL message reporting.
** Changed in: keystone
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
** Project changed: keystone => ceilometer
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1627094
Title:
Keystone overwhelms Ceilometer with Identity Events
st setting notification_driver to either log or noop in
/etc/keystone/keystone.conf
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
** Also affects: tripleo
Importance: Undecided
Status: New
** Changed in: tripleo
Status: New => Confirmed
** Changed in: keystone
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Public bug reported:
A recent change to encrypt credetials broke RDO/Tripleo deployments:
2016-09-02 17:16:55.074 17619 ERROR keystone.common.fernet_utils
[req-31d60075-7e0e-401e-a93f-58297cd5439b f2caffbaf10d4e3da294c6366fe19a36
fd71b607cfa84539bf0440915ea2d94b - default default] Either
Reported in a downstream distribution that should have synced from this
code as still a bug. please reconfirm.
** Changed in: keystone
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Closing the Keystone server component again, as I just confirmed the
user-list error does not happen in this code base, and thus it is a new
bug and a regression. Will open a separate ticket for that.
** Changed in: keystone
Status: Confirmed => Fix Released
--
You received this bug
Reopening the issue against the Keystone server. The fix was not
sufficient, as it was just a workaround, and one that we can't apply via
the CLI.
The real fix requires avoiding the exception from the identity backend
when performing any assignment-backend calls.
** Changed in: keystone
So...this is a continuing Saga. The fix that went in for Keystone only
allows the V3 AP call to continue. However, there is currently no way
to call that API except for CURL.
Something like:
curl -X DELETE -H"X-Auth-Token:$TOKEN" -H "Content-type:
application/json"
I think this is a Horizon bug, not Keystone. The stack trace is all
Horizon code.
I suspect it is a conflict between domain and project scoped token code
in Horizon
** Also affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a
Public bug reported:
"When defining the URL for connecting to the LDAP server in the Keystone
configuration, looking for a way to specify multiple LDAP servers for
redundancy. For example if an AD domain controller were not available,
Keystone would try an alternate domain controller."
This is
Public bug reported:
We've seen an effect where setting the dfefault token handler to Fenet,
and depending on Revocation events breaks several tests. These tests
are supposed to track that a tokne comes back as invalid. However, what
actually happens is the admin users token is invalid,
Nope. Not going to expose this just for testing. Use direct database
access if you want.
** 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 Identity (keystone).
Public bug reported:
After creating a new project and allocating some amount of resources, we
should be able to create a hierarchy of users like Project Manager (PM)
having complete view of the project usage, then PM should be able to
allocate resources to different sub-teams (like Dev, QA, Prod,
According to conversation in #openstack-keystone, reporter was running
this by hand using ipython. The migrations are not designed to run
multiple tiumes, and this error was not somthing we would see using the
proper migrate mechanism.
** Changed in: keystone
Status: New => Invalid
--
Public bug reported:
To minimize downtime, the conversion from persisted to ephemeral tokens
should happen in two steps. The first migrates tokens over to the
Fernet format, but will fall back to persisted store if the requested
token is not in Fernet format. The second removes persistence.
**
Public bug reported:
Description of problem:
Testing multi domain support in RHOS. The deletion of this domain when write
enabled cleared the LDAP database entirely. Thankfully this was done in a lab,
because LDAP was a total loss.
Version-Release number of selected component (if applicable):
Public bug reported:
Create two roles. Make one imply the other (need curl for now)
$ openstack role delete identity_policy_manager
ERROR: openstack An unexpected error prevented the server from fulfilling your
request. (HTTP 500) (Request-ID: req-a2b89f42-ad24-4985-a599-33cc182d8f80)
Its a feature. A trust is assumed to be the smallest chunk of delegated
roles possible to perform an action. If a user does not have all those
roles, the trustor should be informed immediately that the trust is no
longer viable.
** Changed in: keystone
Status: In Progress => Invalid
--
Adding Nova to the bug report because it absolutely should not require a
specific version of the Keystone API to make things work. I suspect
that there is a workaround here, but the Keystone API and auth plugins
are designed to be versionless. This is a step backwards, and should be
treated as a
= self.v3_create_token(auth_data)
token = r.result['token']
# This fails
self.assertThat(token['roles'], matchers.HasLength(3))
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
Status: New
** Changed in: keystone
Assignee
Public bug reported:
Today it is possible to define an implied role structure that is not a
DAG. This will crash the Keystone server if a token iis requested that
will pull in any of those roles.
While it might be impractical to prevent cycles in the creation, it is
very possible to prevent
Public bug reported:
When redelegating a trust, the API specifies that the trustor_id is the
original trustor_id. However, the policy check for create_trust
enforces that user_id = trust.trustor_user_id. Effectily limiting the
redelgation ofr trusts to trusts which provide impersonation.
**
Works as designed and specified. The Wiki is wrong. Would not modify
away from the existing behavior, either.
** 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
Needs 3 things:
1. Feature in Keystone to track the WebSSO logout URL comparable to the login
URL
2. A way to communicate this to Horizon
3. A tie in to Horizon to call the URL in order to logout.
Since Keystone manages websso login, it should do the logout directly as
well.
** Changed in:
Moving to Fernet tokens. Revocations will be handled by revocation
events, not revocation list. Memcache as a storage mechanism for PKI
tokens was deeply flawed, as dropping tokens from Memcache effectively
unrevoked them.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You
Due to a security issue with PKI tokens, we are going to stop supporting
PKI and we will move people on to Fernet as a replacement. Thus, no new
features will be implemented for PKI tokens
** Changed in: keystone
Importance: High => Wishlist
** Changed in: keystone
Status: Triaged =>
This is not a problem with current policy/approach. The approach to fix
968696 will also ensure this continues to work.
** Changed in: keystone
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Was fixed in commit
98732367e384b89c9ff9dd632be870e774083b94
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
Public bug reported:
User Ids cannot be something sepcified entirely by the Federation
providers. If they are, there are a handful of potential problems:
1. The userId specified will be too big for the colum (varchar 64)
2. Two different Identity Providers can provide the same value for
The fix went into 2015.1.0 and 2015.1.1 is now in the cloud archive.
** Changed in: nova (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Public bug reported:
V3 is not specifically rtied to either public or Admin in the specs, but
practically speaking, it is tied to admin;
When attempting to use the V3 api and the admin port is not exposed, the
followng happens:
$ echo $OS_AUTH_URL
https://hostname/v3
$ openstack server list
Since we are dropping support for Eventlet based deployments, continuing
to document them is counterproductive. Please switch over to using
Apache HTTPD.
** Changed in: keystone
Status: Confirmed = Won't Fix
--
You received this bug notification because you are a member of Yahoo!
It might make sense to have Horizon limit login to users with the Member
or Admin roles only.
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Assignee: (unassigned) = Adam Young (ayoung)
--
You received this bug notification because you are a member
** Also affects: python-oslo.messaging (Ubuntu)
Importance: Undecided
Status: New
** Changed in: oslo.messaging
Status: Confirmed = Invalid
** Changed in: nova
Status: New = Invalid
** Changed in: python-oslo.messaging (Ubuntu)
Status: New = Confirmed
--
You
The code is not moving to client after all. The code in the Server will
stand.
** Changed in: keystone
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
** Also affects: glance
Importance: Undecided
Status: New
** Also affects: cinder
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Default domain is a forward compat feature necessary to let V2
continue to work in a V3 aware keystone.
The default domain is a very important domain, and should be part of the
core configuration. Changing that on the fly will change the meaning of
the V2 tokens, and is not something to be done
Public bug reported:
While many people are still stuck on V2 tokens, we need a safe way to
map them to V3. If they default domain changes, the tokens will not be
properly converted. THe best that can be done now is to guess that the
domain_id is default and the name is Default
both these
of forcing admin somewhere is admin everywhere
** Affects: keystone
Importance: High
Assignee: Adam Young (ayoung)
Status: New
** Changed in: keystone
Importance: Undecided = High
** Changed in: keystone
Assignee: (unassigned) = Adam Young (ayoung)
--
You received this bug
Public bug reported:
If a user attempts to run keystone-manage but the instance is
configured to run in httpd, it will attempt to start the eventlet
server. If the httpd instance is running, the error is confusing, since
a port is already in use.
** Affects: keystone
Importance: Undecided
Public bug reported:
Setup Federation with SSSD. Worked OK with
[federation]
remote_id_attribute=foo
but not with
[kerberos]
remote_id_attribute=foo
** Affects: keystone
Importance: Undecided
Assignee: Lin Hua Cheng (lin-hua-cheng)
Status: Confirmed
--
You received this
The issue is with configuring Nova. When I edited Nova's conf file so
that authe vesrion was unset, like this:
auth_version=
And restarted all the Nova services, it worked.
** Changed in: keystone
Importance: Critical = Medium
** Also affects: nova
Importance: Undecided
Status:
** No longer affects: keystone
** Summary changed:
- cannot use v3 token with v2 services
+ Nova cannot validate v3 token by default
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Public bug reported:
Spec states:
http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3
/identity-api-v3.rst#n1779
A user may explicitly request an unscoped token by setting
the scope value of the token request to the string unscoped.
However the code actaully tests:
** Also affects: keystone/icehouse
Importance: Undecided
Status: New
** Also affects: keystone/kilo
Importance: High
Assignee: Steve Martinelli (stevemar)
Status: In Progress
** Also affects: keystone/juno
Importance: Undecided
Status: New
--
You received
Public bug reported:
In
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_policy/controllers.py#n133
.create_policy_association should be check_policy_association
@controller.protected()
def check_policy_association_for_region_and_service(
self,
Public bug reported:
keystone-manage db_sync --extension endpoint_filter 2
fails with
2014-12-05 13:54:39.295 11241 TRACE keystone OperationalError:
(OperationalError) (1005, Can't create table 'keystone.project_endpoint_group'
(errno: 150)) '\nCREATE TABLE project_endpoint_group
Looks like I had an old .pyc file causing this
** Changed in: keystone
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1399768
Title:
migration ofr
, operation, payload):
-self.endpoint_policy_api.delete_association_by_polcy(
+self.endpoint_policy_api.delete_association_by_policy(
payload['resource_info'])
** Affects: keystone
Importance: Undecided
Assignee: Adam Young (ayoung)
Status: In Progress
** Changed in: keystone
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1101287
Title:
Keystone LDAP does not support v3 Role Grants
Status in
Public bug reported:
there is a disconnect between how Identity gets users for
Authentication and how it creates users.
When creating a user, deleting a user, etc, the identity code calls:
conn.add_s(self._id_to_dn(values['id']), attrs)
Which attempts to convert an id to a dn
Public bug reported:
I received the following error from the check-tempest-dsvm-neutron-full
test suite after submitting a nova patch:
2014-08-21 14:11:25.059 | Captured traceback:
2014-08-21 14:11:25.059 | ~~~
2014-08-21 14:11:25.059 | Traceback (most recent call last):
** Also affects: python-keystoneclient
Importance: Undecided
Status: New
** No longer affects: keystone
** Changed in: python-keystoneclient
Assignee: (unassigned) = Adam Young (ayoung)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team
Public bug reported:
The behaviour of this API is different if
CONF.identity.domain_specific_drivers_enabled is set or not. If it is
not set, then listing user shows for all domains. If it is set, even
for SQL, only a single domain is listed.
The correct behavior would be to only list users
** Also affects: keystonemiddleware
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1278843
Title:
Neutron doesn't report using a stale CA
Public bug reported:
Use CURL to get an admin token and use it to perform list domains will
result in a failure.
Get an unscoped token:
$ cat token-request-admin.json
{
auth: {
identity: {
methods: [
password
],
password: {
Public bug reported:
When deploying OpenStack Icehouse on Ubuntu trusty in a cells configuration
the callback from neutron to nova that notifies nova
when a port for an instance is ready to be used seems to be lost. This causes
the spawning instance to go into an ERROR state and
the following
1 - 100 of 140 matches
Mail list logo
