Open Stack

On 2015-05-05 1:25 AM, Monty Taylor wrote:
> On 05/04/2015 08:47 PM, Emilien Macchi wrote:
> 
> 
>> On 05/04/2015 10:37 PM, Rich Megginson wrote:
>>> On 05/04/2015 07:52 PM, Mathieu Gagné wrote:
>>>> On 2015-05-04 9:15 PM, Rich Megginson wrote:
>>>>> On 05/04/2015 06:03 PM, Mathieu Gagné wrote:
>>>>>> On 2015-05-04 7:35 PM, Rich Megginson wrote:
>>>>>>> The way authentication works with the Icehouse branch is
>>>>>>> that puppet-keystone reads the admin_token and
>>>>>>> admin_endpoint from /etc/keystone/keystone.conf and
>>>>>>> passes these to the keystone command via the
>>>>>>> OS_SERVICE_TOKEN env. var. and the --os-endpoint
>>>>>>> argument, respectively.
>>>>>>>
>>>>>>> This will not work on a node where Keystone is not
>>>>>>> installed (unless you copy /etc/keystone/keystone.conf to
>>>>>>> all of your nodes).
>>>>>>>
>>>>>>> I am assuming there are admins/operators that have
>>>>>>> actually deployed OpenStack using puppet on nodes where
>>>>>>> Keystone is not installed?
>>>>>> We are provisioning keystone resources from a privileged
>>>>>> keystone node which accepts the admin_token. All other
>>>>>> keystone servers has the admin_token_auth middleware
>>>>>> removed for obvious security reasons.
>>>>>>
>>>>>>
>>>>>>> If so, how?  How do you specify the authentication
>>>>>>> credentials?  Do you use environment variables?  If so,
>>>>>>> how are they specified?
>>>>>> When provisioning resources other than Keystones ones, we
>>>>>> use custom puppet resources and the credentials are passed
>>>>>> as env variables to the exec command. (they are mainly
>>>>>> based on exec resources)
>>>>> I'm talking about the case where you are installing an
>>>>> OpenStack service other than Keystone using puppet, and that
>>>>> puppet code for that module needs to create some sort of
>>>>> Keystone resource.
>>>>>
>>>>> For example, install Glance on a node other than the Keystone
>>>>> node. puppet-glance is going to call class
>>>>> glance::keystone::auth, which will call
>>>>> keystone::resource::service_identity, which will call
>>>>> keystone_user { $name }.  The openstack provider used by
>>>>> keystone_user is going to need Keystone admin credentials in
>>>>> order to create the user.
>>>> We "fixed" that part by not provisioning Keystone resources
>>>> from Glance nodes but from Keystone nodes instead.
>>>>
>>>> We do not allow our users to create users/groups/projects, only
>>>> a user with the admin role can do it. So why would you want to
>>>> store/use admin credentials on an unprivileged nodes such as
>>>> Glance? IMO, the glance user shouldn't be able to
>>>> create/edit/delete users/projects/endpoints, that's the
>>>> keystone nodes' job.
>>>
>>> Ok.  You don't need the Keystone "superuser" admin credentials on
>>> the Glance node.
>>>
>>> Is the puppet-glance code completely separable so that you can
>>> call only glance::keystone::auth (or other classes that use
>>> Keystone resources) from the Keystone node, and all of the other
>>> puppet-glance code on the Glance node?  Does the same apply to
>>> all of the other puppet modules?
>>>
>>>>
>>>> If you do not wish to explicitly define Keystone resources for
>>>> Glance on Keystone nodes but instead let Glance nodes manage
>>>> their own resources, you could always use exported resources.
>>>>
>>>> You let Glance nodes export their keystone resources and then
>>>> you ask Keystone nodes to realize them where admin credentials
>>>> are available. (I know some people don't really like exported
>>>> resources for various reasons)
>>>
>>> I'm not familiar with exported resources.  Is this a viable
>>> option that has less impact than just requiring Keystone
>>> resources to be realized on the Keystone node?
> 
>> I'm not in favor of having exported resources because it requires 
>> PuppetDB, and a lot of people try to avoid that. For now, we've
>> been able to setup all OpenStack without PuppetDB in TripleO and in
>> some other installers, we might want to keep this benefit.
> 
> +100
> 
> We're looking at using these puppet modules in a bit, but we're also a
> few steps away from getting rid of our puppetmaster and moving to a
> completely puppet apply based workflow. I would be double-plus
> sad-panda if we were not able to use the openstack puppet modules to
> do openstack because they'd been done in such as way as to require a
> puppetmaster or puppetdb.

100% agree.

Even if you had a puppetmaster and puppetdb, you would still end up in
this "eventual consistency" dance of puppet runs.

-- 
Mathieu