On 05/30/2013 05:58 PM, Dave Neary wrote:
> Hi Adam,
> Can you have a look at this post on rdo-list and see if you can figure
> out what's going wrong, please?
> -------- Original Message --------
> Subject: [Rdo-list] RDO with Red Hat IDM
> Date: Thu, 30 May 2013 17:13:59 -0400
> From: Michael Solberg <msolberg(a)redhat.com>
> To: rdo-list(a)redhat.com
> Hi list.
> I've spent a day or two now trying to use Red Hat IDM as a backing store
> for Keystone in RDO and I'm about to pull my hair out.
> I started with Adam Young's blog post here:
> Then I watched his Summit video here:
> Then I tried to follow this document:
> I definitely ran into the domain_id problem described here:
> I also ran into the issue around the RFC 4519 schema not allowing a
> "enabled" attribute. I think I've mitigated this by setting the
> "attribute_ignore" settings in keystone.conf.
> I've tried tackling the architecture from a few different directions and
> I've gotten to the point where I can create roles, create tenants, and
> list users in my IDM domain, but not assign roles to users. I think
> this is because I'm trying to separate out the tenants and roles from
> the users in the directory tree. I don't mind keystone creating objects
> in it's own tree, but I don't want it updating user accounts from IDM.
So, you have put projects into their own subtree? Can the LDAP user
from Keystone modify that tree?
I would think you would want to make user that has ACLs set up
permitting them to make modifications to that tree, but not to add
users. Configure Keystone to use that user to talk to LDAP.
Assuming you call that user KeystoneManager, you would then set the
[LDAP] config value for user = KeystoneManager in Keystone Config.
The ACL stuff in IPA is kind of cool. I did some write ups here:
That should give you an indication of how you want to proceed.
> Has anyone gotten this configuration working? I'm willing to wade
> through details, but I'm curious if someone else has this working and I
> could just replicate their setup.
-----BEGIN PGP SIGNED MESSAGE-----
On 06/18/2013 05:03 PM, Forrest Taylor wrote:
> I was playing with the 2013-06-18.1 puddle and I noticed when I
> run packstack, OpenStack Networking is used by default. However,
> there are no routers, networks or subnets configured. Are there
> plans to enable a router, network and/or subnet in packstack?
That's a good question and one that we've been discussing a bit...
Packstack installs the services, and gets things set up so that an
admin can then start creating tenants.
But, since Packstack doesn't know how many tenants you want to set up,
or anything, it can't really know what networks and subnets you want
Typically the task of creating a tenant network/subnet/router would be
done by a cloud administrator at the point at which they create a new
tenant. Right now, that would involve a sequence of manual steps.
It could be that an OpenStack management solution of some sort could
help to automate those tasks (since they do span multiple components),
or a simple script could help.
There has been talk about giving Packstack an option to create a
single tenant, network, subnet by default. This would be useful for
both testing environments as well as allinone or demo installs. I
believe Maru (cc'd) has been working on changes to puppet modules to
support this, and Terry/Ryan (cc'd) are working on integrating this
But this doesn't solve the more general issue of "after Packstack
deployment, I create 10 new tenants... who/how does the network/subnet
Right now, it's just documentation, but perhaps in the future there is
a better solution. Brent (cc'd) is helping to chase this down.
I've cc'd some folks that might be able to weigh in on this
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----