Open Stack

There is some misunderstanding here. By using keystone I mean running
keystone on fuel master node. After all it's just python program. It's used
by OpenStack as authorization tool but it also can be used as standalone
software or by different tools completely not connected with OpenStack.
In future if  want to use LDAP source, keystone already have plugin for it.

Regards


On Tue, May 27, 2014 at 5:08 PM, David Easter <deaster at mirantis.com> wrote:

> The other challenge of utilizing Keystone is which one to use.  Fuel
> enables the deployment of multiple cloud environments from one UI; so when
> accessing the Fuel Master Node, it would be ambiguous which already
> deployed Keystone to contact for authentication.  If/When Triple-O is
> utilized, one could perhaps see designating the Keystone of the undercloud;
> but that’s more a future requirement.
>
> For now, I’d suggest an internal authentication in the immediate short
> term.  External auth sources can be added in future milestones – most
> likely an LDAP source that’s outside the deployed clouds and designated by
> IT.
>
> Thanks,
>
> - David J. Easter
>   Director of Product Management, Mirantis
>
> From: Jesse Pretorius <jesse.pretorius at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, May 27, 2014 at 7:43 AM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node
>
> On 27 May 2014 13:42, Lukasz Oles <loles at mirantis.com> wrote:
>
>> Hello fuelers,
>>
>> we(I and Kamil) would like start discussion about "Enforce access control
>> for Fuel UI" blueprint
>> https://blueprints.launchpad.net/fuel/+spec/access-control-master-node.
>>
>> First question to David, as he proposed this bp. Do you want to add more
>> requirements?
>>
>> To all. What do you think about using keystone as authorization tool? We
>> described all pros/cons in the specification.
>>
>
> I would suggest both an internal authentication database and the option of
> plugging additional options in, with keystone being one of them and perhaps
> something like oauth being another.
>
> Keystone may not be available at the time of the build, or accessible from
> the network that's used for the initial build.
> _______________________________________________ OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Łukasz Oleś
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/1b66bd7f/attachment.html>