<div dir="ltr">After some discussion on IRC we updated blueprint. Now it's available as review here <a href="https://review.openstack.org/#/c/96429/2">https://review.openstack.org/#/c/96429/2</a><div>Nice looking version is here <a href="http://docs-draft.openstack.org/29/96429/3/check/gate-fuel-specs-docs/d5b32d5/doc/build/html/specs/5.1/access-control-master-node.html">http://docs-draft.openstack.org/29/96429/3/check/gate-fuel-specs-docs/d5b32d5/doc/build/html/specs/5.1/access-control-master-node.html</a></div>
<div><br></div><div>Blueprint was split into 4 stages so now we can implement it in smaller steps. </div><div><br></div><div>Please comment.</div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, May 27, 2014 at 8:41 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AFIK, if we implement ironic as a replacement for cobbler, we will<br>
have Keystone on the fuel-master anyway. Supporting OAuth as an<br>
additional authentication entry would awesome too, but I'm not sure if<br>
there would be much demand over Keystone.<br>
<div><div class="h5"><br>
On Tue, May 27, 2014 at 8:31 AM, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
> There is some misunderstanding here. By using keystone I mean running<br>
> keystone on fuel master node. After all it's just python program. It's used<br>
> by OpenStack as authorization tool but it also can be used as standalone<br>
> software or by different tools completely not connected with OpenStack.<br>
> In future if  want to use LDAP source, keystone already have plugin for it.<br>
><br>
> Regards<br>
><br>
><br>
> On Tue, May 27, 2014 at 5:08 PM, David Easter <<a href="mailto:deaster@mirantis.com">deaster@mirantis.com</a>> wrote:<br>
>><br>
>> The other challenge of utilizing Keystone is which one to use.  Fuel<br>
>> enables the deployment of multiple cloud environments from one UI; so when<br>
>> accessing the Fuel Master Node, it would be ambiguous which already deployed<br>
>> Keystone to contact for authentication.  If/When Triple-O is utilized, one<br>
>> could perhaps see designating the Keystone of the undercloud; but that’s<br>
>> more a future requirement.<br>
>><br>
>> For now, I’d suggest an internal authentication in the immediate short<br>
>> term.  External auth sources can be added in future milestones – most likely<br>
>> an LDAP source that’s outside the deployed clouds and designated by IT.<br>
>><br>
>> Thanks,<br>
>><br>
>> - David J. Easter<br>
>>   Director of Product Management, Mirantis<br>
>><br>
>> From: Jesse Pretorius <<a href="mailto:jesse.pretorius@gmail.com">jesse.pretorius@gmail.com</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Date: Tuesday, May 27, 2014 at 7:43 AM<br>
>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node<br>
>><br>
>> On 27 May 2014 13:42, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
>>><br>
>>> Hello fuelers,<br>
>>><br>
>>> we(I and Kamil) would like start discussion about "Enforce access control<br>
>>> for Fuel UI" blueprint<br>
>>> <a href="https://blueprints.launchpad.net/fuel/+spec/access-control-master-node" target="_blank">https://blueprints.launchpad.net/fuel/+spec/access-control-master-node</a>.<br>
>>><br>
>>> First question to David, as he proposed this bp. Do you want to add more<br>
>>> requirements?<br>
>>><br>
>>> To all. What do you think about using keystone as authorization tool? We<br>
>>> described all pros/cons in the specification.<br>
>><br>
>><br>
>> I would suggest both an internal authentication database and the option of<br>
>> plugging additional options in, with keystone being one of them and perhaps<br>
>> something like oauth being another.<br>
>><br>
>> Keystone may not be available at the time of the build, or accessible from<br>
>> the network that's used for the initial build.<br>
>> _______________________________________________ OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> --<br>
>> Mailing list: <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
>> Post to     : <a href="mailto:fuel-dev@lists.launchpad.net">fuel-dev@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
>> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Łukasz Oleś<br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
> Post to     : <a href="mailto:fuel-dev@lists.launchpad.net">fuel-dev@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Andrew<br>
Mirantis<br>
Ceph community<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Łukasz Oleś</div>
</div>