Re: [Openstack-operators] OpenStack Puppet module Keystone Juno

[Rich Megginson]

On 01/04/2016 03:07 PM, Russell Cecala wrote:

Thank you for the reply Rich,

Here are the versions of my puppet modules:

[root@ost-puppet-centos-001 keystone]# puppet module list

/etc/puppetlabs/puppet/environments/production/modules

├── nanliu-staging (v1.0.3)

├── openstack-keystone (v6.1.0)

├── openstack-openstacklib (v6.1.0)

├── puppetlabs-apache (v1.7.0)

├── puppetlabs-apt (v1.8.0)

├── puppetlabs-concat (v1.2.4)

├── puppetlabs-firewall (v1.7.1)

├── puppetlabs-inifile (v1.4.2)

├── puppetlabs-mysql (v3.6.1)

├── puppetlabs-postgresql (v3.4.2)

├── puppetlabs-rabbitmq (v5.3.1)

└── puppetlabs-stdlib (v4.9.0)

/etc/puppetlabs/puppet/modules

├── cisco-gis-openstack (???)

├── haproxy (???)

├── keepalived (???)

├── mikduart-unnamed (v0.1.0)

├── mikduart-unnamed (v0.1.0)

├── mikduart-unnamed (v0.1.0)

├── puppetlabs-mongodb (v0.10.0)

├── saz-memcached (v2.4.0)

├── setup_mariadb_script (???)

├── sysctl (???)

└── wrapmongodb (???)

/opt/puppet/share/puppet/modules

├── puppetlabs-pe_accounts (v2.0.2-8-g8acc04e)

├── puppetlabs-pe_concat (v1.1.2-4-g2b7bba2)

├── puppetlabs-pe_console_prune (v0.1.1-4-g293f45b)

├── puppetlabs-pe_inifile (v1.1.4-16-gcb39966)

├── puppetlabs-pe_java_ks (v1.2.4-35-g44fbb26)

├── puppetlabs-pe_postgresql (v3.4.4-15-g32e56ed)

├── puppetlabs-pe_razor (v0.2.1-9-g8d78ec2)

├── puppetlabs-pe_repo (v0.7.7-59-g4514315)

├── puppetlabs-pe_staging (v0.3.3-6-gbd9db2b)

└── puppetlabs-puppet_enterprise (v3.7.1-117-g9c48e73)


I am not sure I have the right values in my openrc but I have been using:


# cat openrc.localhost

export OS_AUTH_URL=http://127.0.0.1:5000/v2.0

export OS_PASSWORD=

export OS_TENANT_NAME=admin

export OS_USERNAME=admin



Is this sourced into the environment where puppet is running?  It should 
not be.




I believe this is the openstackclient version I am using:


[root@ost-mgmt-centos-001 ~]# rpm -qa | grep openstackclient

python-*openstackclient*-1.0.3-2.el7.noarch


On Mon, Jan 4, 2016 at 1:19 PM, Rich Megginson <mailto:rmegg...@redhat.com>> wrote:


On 01/04/2016 02:06 PM, Russell Cecala wrote:

Hi Emilien,


I am trying to use https://github.com/openstack/puppet-keystone
to set up a Kilo keystone node.


I'm assuming you're using the kilo branch there?


I was hoping to could help me out so I can get my team to adopt
puppet for setting up OpenStack.

On my keystone node I am running centos7 with selinux disabled ...


What version of openstackclient are you using?

Do you have a $HOME/openrc or /root/openrc, or are you otherwise
defining OS_* environment variables in the environment before
running puppet?



[root@svl-ost-mgmt-centos-001 ~]# sestatus

SELinux status: disabled

... and I have flushed my iptables ...


[root@svl-ost-mgmt-centos-001 ~]# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination


Chain FORWARD (policy ACCEPT)

target prot opt source destination


Chain OUTPUT (policy ACCEPT)

target prot opt source destination


Yet when I run "puppet agent -t"  I get these errors:


[root@ost-mgmt-centos-001 ~]# puppet agent -t

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Loading facts

Error: NetworkManager is not running.

Info: Caching catalog for ost-mgmt-centos-001.example.com
<http://ost-mgmt-centos-001.example.com>

*Warning: The tenant parameter is deprecated and will be removed
in the future. Please use keystone_user_role to assign a user to
a project.*

*Warning: The ignore_default_tenant parameter is deprecated and
will be removed in the future.*

Info: Applying configuration version '1451940682'

*Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]:
Could not evaluate: Execution of '/usr/bin/openstack token issue
--format value' returned 1: ERROR: openstack The resource could
not be found. (HTTP 404) (Request-ID:
req-ca2a6dd1-fdb6-48f4-94fe-8f736fcc01dd)*



*This usually indicates that it is trying to ensure that the user 
"admin" exists but the password is incorrect.  That is, the class { 
'::keystone::roles::admin':password => 
$keystone_admin_password is not correct.


If you are sure it is correct, then it could be a mismatch between the 
identity api version used by the puppet module and the one specified in 
the environment.  Check the keystone access logs to see what URL this is 
trying to access - something with /token or /tokens, or something with 
/auth/token or /auth/tokens


*



Notice:
/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[admin@openstack]:
Dependency Keystone_user[admin] has failures: true

*Warning:
/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[admin@openstack]:
Skipping because of failed dependencies*

N

Re: [Openstack-operators] OpenStack Puppet module Keystone Juno

[Rich Megginson]

On 01/04/2016 02:06 PM, Russell Cecala wrote:

Hi Emilien,


I am trying to use https://github.com/openstack/puppet-keystone to set 
up a Kilo keystone node.


I'm assuming you're using the kilo branch there?

I was hoping to could help me out so I can get my team to adopt puppet 
for setting up OpenStack.


On my keystone node I am running centos7 with selinux disabled ...


What version of openstackclient are you using?

Do you have a $HOME/openrc or /root/openrc, or are you otherwise 
defining OS_* environment variables in the environment before running 
puppet?




[root@svl-ost-mgmt-centos-001 ~]# sestatus

SELinux status: disabled

... and I have flushed my iptables ...


[root@svl-ost-mgmt-centos-001 ~]# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination


Chain FORWARD (policy ACCEPT)

target prot opt source destination


Chain OUTPUT (policy ACCEPT)

target prot opt source destination


Yet when I run "puppet agent -t"  I get these errors:


[root@ost-mgmt-centos-001 ~]# puppet agent -t

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Loading facts

Error: NetworkManager is not running.

Info: Caching catalog for ost-mgmt-centos-001.example.com 



*Warning: The tenant parameter is deprecated and will be removed in 
the future. Please use keystone_user_role to assign a user to a project.*


*Warning: The ignore_default_tenant parameter is deprecated and will 
be removed in the future.*


Info: Applying configuration version '1451940682'

*Error: /Stage[main]/Keystone::Roles::Admin/Keystone_user[admin]: 
Could not evaluate: Execution of '/usr/bin/openstack token issue 
--format value' returned 1: ERROR: openstack The resource could not be 
found. (HTTP 404) (Request-ID: req-ca2a6dd1-fdb6-48f4-94fe-8f736fcc01dd)*


Notice: 
/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[admin@openstack]: 
Dependency Keystone_user[admin] has failures: true


*Warning: 
/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[admin@openstack]: 
Skipping because of failed dependencies*


Notice: Finished catalog run in 12.38 seconds

Here's code I am using on my puppet master ...

classwrapcontroller(

... big list of parameters I am not using until I can get keystone 
going ...


) {


exec{ '/bin/yum -y install 
http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm': 
unless=> '/bin/rpm -q epel-release', }


exec{ '/bin/yum -y install 
http://rdo.fedorapeople.org/openstack-kilo/rdo-release-kilo.rpm': 
unless=> '/bin/rpm -q rdo-release', }



package { 'mariadb': ensure => present, }

exec{ 'keystone_database_init':

command=> '/usr/bin/keystone-manage db_sync',

onlyif => [

"/usr/bin/mysql 
-u$keystone_db_user-p$keystone_db_pass-h$db_host-P$db_port$keystone_db_name-e 
'show tables'",


"/usr/bin/test -z \"`/usr/bin/mysql -u$keystone_db_user 
-p$keystone_db_pass -h$db_host -P$db_port $keystone_db_name -e 'show 
tables'`\""


],

require => Package['mariadb'],

}


class{'::keystone':

admin_token=> $keystone_auth_token,

database_connection=> 
"mysql://${keystone_db_user}:${keystone_db_pass}@${db_host}:${db_port}/${keystone_db_name}",


debug => $debug,

enabled => true,

enable_ssl => false,

service_name => 'httpd',# this is a kilo thing

verbose => $debug,

}


include ::apache

class{ '::keystone::wsgi::apache': ssl=> false, }

class{ '::keystone::roles::admin':

email  => $keystone_admin_email,

password=> $keystone_admin_password,

}

class{ '::keystone::endpoint':

public_url=> "http://127.0.0.1:5000";,

admin_url  => "http://127.0.0.1:35357";,

default_domain=> 'admin',

}

}

Thanks! And Happy New Year to you :)
Red



On Tue, Nov 24, 2015 at 2:38 PM, Emilien Macchi > wrote:




On 11/24/2015 11:21 PM, Russell Cecala wrote:
> I am trying to use the OpenStack community puppet modules. 
Here's the

> keystone module I am using:
https://github.com/openstack/puppet-keystone
> I am using the stable juno branch.  I have in my puppet manifest
for my
> controller nodes this resource definition:
>
> class { '::keystone::roles::admin':
> admin=> $keystone_admin_user,
> email=> $keystone_admin_email,
> password => $keystone_admin_password,
> } ->
>
> And when puppet runs that code I get this error:
>
> Error:
>

/Stage[main]/Keystone::Roles::Admin/Keystone_user_role[keystone_admin_user@openstack]:
> Could not evaluate: Execution of '/usr/bin/openstack domain show
> --format shell' returned 2: usage: openstack domain show [-h] [-f
> {shell,table,value}] [-c COLUMN]
>  [--max-width ]
[--prefix PREFIX]
>  
> openstack domain show: e

Re: [Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Rich Megginson]

On 12/07/2015 07:49 PM, Adam Young wrote:

On 12/07/2015 06:53 PM, Thomas Goirand wrote:

On 12/01/2015 07:57 AM, Steve Martinelli wrote:

Trying to summarize here...

- There isn't much interest in keeping eventlet around.
- Folks are OK with running keystone in a WSGI server, but feel they 
are

constrained by Apache.
- uWSGI could help to support multiple web servers.

My opinion:

- Adding support for uWSGI definitely sounds like it's worth
investigating, but not achievable in this release (unless someone
already has something cooked up).
- I'm tempted to let eventlet stick around another release, since it's
causing pain on some of our operators.
- Other folks have managed to run keystone in a web server (and
hopefully not feel pain when doing so!), so it might be worth getting
technical details on just how it was accomplished. If we get an OK from
the operator community later on in mitaka, I'd still be OK with 
removing

eventlet, but I don't want to break folks.

stevemar

From: John Dewey 
100% agree.

We should look at uwsgi as the reference architecture. Nginx/Apache/etc
should be interchangeable, and up to the operator which they choose to
use. Hell, with tcp load balancing now in opensource Nginx, I could get
rid of Apache and HAProxy by utilizing uwsgi.

John

The main problem I see with running Keystone (or any other service) in a
web server, is that *I* (as a package maintainer) will loose the control
over when the service is started. Let me explain why that is important
for me.

In Debian, many services/daemons are run, then their API is used by the
package. In the case of Keystone, for example, it is possible to ask,
via Debconf, that Keystone registers itself in the service catalog. If
we get Keystone within Apache, it becomes at least harder to do so.

The other issue is that if all services are sharing the same web server,
restarting the web server restarts all services. Or, said otherwise: if
I need to change a configuration value of any of the services served by
Apache, I will need to restart them all, which is very annoying: I very
much prefer to just restart *ONE* service if I need.

Also, something which we learned the hard way at Mirantis: it is *very*
annoying that Apache restarts every Sunday morning by default in
distributions like Ubuntu and Debian (I'm not sure for the other
distros). No, the default config of logrotate and Apache can't be
changed in distros just to satisfy OpenStack users: there's other users
of Apache in these distros.

Then, yes, uWSGI becomes a nice option. I used it for the Barbican
package, and it worked well. Though the uwsgi package in Debian isn't
very well maintained, and multiple times, Barbican could have been
removed from Debian testing because of RC bugs against uWSGI.

So, all together, I'm a bit reluctant to see the Eventlet based servers
going away. If it's done, then yes, I'll work around it. Though I'd
prefer if it didn't.


You can run one instance of Apache for each service, and have the 
listen on different ports.  Its not how the distros set up apache, but 
then again, the distros only set up Eventlet with  the work we;'ve done.


Eventlet has threading issues I'd rather not debug anymore.




It is also my view that it's up to the deployers to decide how they want
to implement things. For many small use cases, Eventlet performs well
enough.


And for these, Apache is still a better approach, all things considered.

Every way has some pain...we are trying to chose the lesser.



Finally, one thing which I never understood: if Eventlet is bad as an
HTTP server, can't we use anything else written in Python? Isn't it
possible to write a decent HTTP server in Python? Why are we forced into
just Eventlet for doing the job? I haven't searched around, but there
must be loads of alternatives, no?


Crypto.  Crypto should not be done in Python.  Also, GIL and multi 
threading make it hard to do in Python.  Hence the userland threading 
approach.  Which has an impact on all blocking IO calls.


Kerberos.  Other forms of authn/authz - gssapi, federation, 
mod_lookup_identity, etc. that would need to be implemented in 
python/eventlet.




There are many ways to get what you want.  Each service in their own 
container is probably the one that maps closest to the type of 
insulation we'd like to see.  Each in their own VM probably makes 
sense for a non-trivial sized cloud.








Cheers,

Thomas Goirand (zigo)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-b

[Openstack-operators] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

[Rich Megginson]

tl;dr You must specify a domain when using domain scoped resources.

If you are using domains with puppet-keystone, there is a proposed patch 
that will break backwards compatibility.


https://review.openstack.org/#/c/226624/ Replace indirection calls

"Indirection calls are replaced with #fetch_project and #fetch_user methods
using python-openstackclient (OSC).

Also removes the assumption that if a resource is unique within a domain 
space

then the domain doesn't have to be specified."

It is the last part which is causing backwards compatibility to be 
broken.  This patch requires that a domain scoped resource _must_ be 
qualified with the domain name if _not_ in the 'Default' domain.  
Previously, you did not have to qualify a resource name with the domain 
if the name was unique in _all_ domains.  The problem was this code 
relied heavily on puppet indirection, and was complex and difficult to 
maintain.  We removed it in favor of a very simple implementation: if 
the name is not qualified with a domain, it must be in the 'Default' domain.


Here is an example from puppet-heat - the 'heat_admin' user has been 
created in the 'heat_stack' domain previously.


ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
})

This means "assign the user 'heat_admin' in the unspecified domain to 
have the domain scoped role 'admin' in the 'heat_stack' domain". It is a 
domain scoped role, not a project scoped role, because in 
"@::heat_stack" there is no project, only a domain. Note that the domain 
for the 'heat_admin' user is unspecified. In order to specify the domain 
you must use 'heat_admin::heat_stack@::heat_stack'. This is the 
recommended fix - to fully qualify the user + domain.


The breakage manifests itself like this, from the logs::

2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack user 
show --format shell heat_admin --domain Default'
2015-10-02 06:07:40.505 | Error: 
/Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]: 
Could not evaluate: No user heat_admin with domain  found


This is from the keystone_user_role code. Since the role user was 
specified as 'heat_admin' with no domain, the keystone_user_role code 
looks for 'heat_admin' in the 'Default' domain and can't find it, and 
raises an error.


Right now, the only way to specify the domain is by adding 
'::domain_name' to the user name, as 
'heat_admin::heat_stack@::heat_stack'.  Sofer is working on a way to add 
the domain name as a parameter of keystone_user_role - 
https://review.openstack.org/226919 - so in the near future you will be 
able to specify the resource like this:



ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
  'roles' => ['admin'],
  'user_domain_name' => 'heat_stack',
})

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Problems with OpenStack and LDAP

[Rich Megginson]

On 08/17/2015 08:02 AM, Marc Pape wrote:

Hello everybody,

i've got some problems with our OpenStack (Juno) and the Integrate
Identity Service over LDAP.
The LDAP connection is read only, so i configured the [identity],
[ldap] and [assignment] parts in keystone conf.
The identity part use "driver =
keystone.identity.backends.ldap.Identity" and assignment "driver =
keystone.assignment.backends.sql.Assignment"
Our goal is a user authentication via LDAP and project assignment in
the internal SQL . It would be great if the service users of OpenStack
are also stored in SQL, but they are also currently in the LDAP
deposited.
After restarting the Keystone Service authentication via LDAP is
possible. The user get the message that no projects assigned to him.
Now there are wto problems. How can you log in as admin to assign
projects and keystone said that it couldn't find the service user like
ceilometer, neutron and so on.
I've followed the instructions on docs.openstack.org 
 for Identity

management, but i didn't find any notices about that problems.



Does this help?  http://richmegginson.livejournal.com/25846.html



Many greetings and thanks for a possible answer

Marc


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [puppet][keystone] To always use or not use domain name?

[Rich Megginson]

This is a continuation of a thread that started on openstack-dev: 
http://lists.openstack.org/pipermail/openstack-dev/2015-August/071433.html


The thread is being continued here to reach more people who would be 
affected by this change.


The initial email from Gilles Dubreuil  is as follows:
##

While working on trust provider for the Keystone (V3) puppet module, a
question about using domain names came up.

Shall we allow or not to use names without specifying the domain name in
the resource call?

I have this trust case involving a trustor user, a trustee user and a
project.

For each user/project the domain can be explicit (mandatory):

trustor_name::domain_name

or implicit (optional):

trustor_name[::domain_name]

If a domain isn't specified the domain name can be assumed (intuited)
from either the default domain or the domain of the corresponding
object, if unique among all domains.

Although allowing to not use the domain might seems easier at first, I
believe it could lead to confusion and errors. The latter being harder
for the user to detect.

Therefore it might be better to always pass the domain information.

I believe using the full domain name approach is better.
But it's difficult to tell because in puppet-keystone and
puppet-openstacklib now rely on python-openstackclient (OSC) to
interface with Keystone. Because we can use OSC defaults
(OS_DEFAULT_DOMAIN or equivalent to set the default domain) doesn't
necessarily makes it the best approach. For example hard coded value [1]
makes it flaky.

[1]
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L40

To help determine the approach to use, any feedback will be appreciated.

Thanks,
Gilles

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators