FAQ

On 07/13/2013 06:43 PM, Nan Liu wrote:
There's two options, one to store the username/password on server like
mysql resource (~/my.cnf), or in catalog. I had discussions where some
users prefer the former, but I'm in the later camp.
First approach is OK, if the client program supports dot-conf file with
supplied password. But 'couchbase-cli' doesn't. So I'm stuck with the
former anyway.

This works, just slightly cumbersome.
Actually I've just found that I have trouble getting it to work :(

This code is generating errors:

   Couchbucket {
     admin_user => 'Administrator',
     admin_password => 'secret',
   }

   couchbucket { 'testbucket':
     ensure => present,
   }


Error: Could not set 'present' on ensure: can't convert nil into String
at 75:/etc/puppet/modules/system/manifests/autoload/nodes/server.pp

Error: Could not set 'present' on ensure: can't convert nil into String
at 75:/etc/puppet/modules/system/manifests/autoload/nodes/server.pp
...

And this code works as expected:

   couchbucket { 'testbucket':
     ensure => present,
     admin_user => 'Administrator',
     admin_password => 'secret',
   }


So I'm buffled why is that...

In vmware modules, we use a transport resource to specify connectivity.

https://github.com/vmware/vmware-vcsa/blob/master/manifests/init.pp#L44-L51

Right now, transport is a resource and metaparameter, but I think
there's some value perhaps to turn it back to a regular parameter so we
can specify defaults.

Puppet::Type.newtype(:couchbucket) do
...
newparam(:transport) do
defaultto 'couch'
end
end

This should allow a one time specification of username password for all
resources:

transport { 'couch'
username => ...
password => ...,
}

couchbucket { 'a':
#transport => 'couch' implied
}
This seems nice.

You can find examples in the vmware module how we search the catalog to
find the transport data to initialize and reuse connection.

I've intended to convert transport to a stand alone module and support
the following usage:

1. simple store for username/password (for your exact usage).
2. transport ssh.
3. transport rest.
4. transport soap.

Maybe that would be of interest? I have some other ideas about how to
take advantage of the catalog as data, instead of just resource, but
that's probably going to deviate from this topic.
This would be great! It would certainly avoid collisions... Eg. two
different modules (couchbase and vmware for example) both bringing
'transport' resource with them...

It would be a good idea to merge transport into stdlib.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 10 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 13, '13 at 2:54p
activeNov 20, '13 at 11:31p
posts10
users2
websitepuppetlabs.com

2 users in discussion

Jakov Sosic: 8 posts Nan Liu: 2 posts

People

Translate

site design / logo © 2021 Grokbase