[OpenStack-Infra] Problems setting up my own OpenStack Infrastructure
Bernd Bausch
berndbausch at gmail.com
Fri Mar 30 02:27:25 UTC 2018
Thanks much, Clark. Please don't worry about fast or slow responses.
Regarding the certificate: I had gone over this obstacle by creating my own
self-signed certificate and setting the trust chain parameter to the empty
string. This seems to work.
Regarding the hiera: That makes sense to me. Certificates count as private
data, I guess. Documenting all parameters in site.pp looks like a large
task (67 node declarations if I counted right). Before I volunteer :), I
will first set up my Etherpad.
After fixing the certificate problem, I am hitting more obstacles. I
decided to document my progress on an Etherpad
https://etherpad.openstack.org/p/Creating_an_OpenStack_CI_at_home, hoping
my problems will be useful for improving the docs. I will probably send the
occasional email summarizing the status or asking for help.
Bernd.
On Fri, Mar 30, 2018 at 1:15 AM, Clark Boylan <cboylan at sapwetik.org> wrote:
> On Tue, Mar 27, 2018, at 5:12 PM, Bernd Bausch wrote:
> > My first test uses this local.pp. It's copied verbatim from [1]:
> > ~~~~
> > # local.pp
> > class { 'openstack_project::etherpad':
> > ssl_cert_file_contents => hiera('etherpad_ssl_cert_file_contents'),
>
> This is the public portion of ssl certificate use to run an https server.
> It includes the BEGIN and END CERTIFICATE lines of the cert file contents
> and everything in between.
>
> > ssl_key_file_contents => hiera('etherpad_ssl_key_file_contents'),
>
> This is the portion portion of ssl certificate use to run an https server.
> It includes the BEGIN and END PRIVATE KEY lines of the cert file contents
> and everything in between.
>
> > ssl_chain_file_contents => hiera('etherpad_ssl_chain_file_contents'),
>
> This is the chain of certificates needed to trust the certificate (if
> required, not all certs will have this).
>
> > mysql_host => hiera('etherpad_db_host', 'localhost'),
> > mysql_user => hiera('etherpad_db_user', 'etherpad'),
> > mysql_password => hiera('etherpad_db_password','etherpad'),
> > }
>
> In the case of using built in snakeoil certs on ubuntu you can just
> provide the ssl_key_file and ssl_cert_file values and rely on the contents
> being already in those files to make this simpler rather than going and
> getting a certificate. However you could also use something like Let's
> Encrypt to get the certificates and set their content above.
>
> Example of using snakeoil certs at https://git.openstack.org/
> cgit/openstack-infra/system-config/tree/modules/openstack_
> project/manifests/etherpad_dev.pp#n12
>
<SNIP>
> > > Unfortunately I don't remember off the top of my head how to set up a
> hiera
> > > so I will have to dig into docs (or maybe someone else can chime in
> with
> > > that info).
> >
> > In principle, I can do that (for Puppet 4 at least), but the question is
> what
> > goes into the OpenStack CI production hiera. I see a directory
> > /opt/system-config/production/hiera [3] - is that it? It doesn't contain
> > anything about Etherpad, though. I also did a codesearch for
> > "etherpad_ssl_cert_file_contents", no result (except for the site.pp).
>
> This is the public hiera which lives in the system-config repo itself. We
> can put content in there that is safe to share publicly but may still need
> to be customized by downstream deployments. Unfortunately because we can't
> share our private hiera content that data remains harder to share and will
> in many cases be manifest dependent. Your private hiera should live
> elsewhere in the hiera lookup path. I believe ours lives in
> /etc/puppet/hieradata/production.
>
> One approach we may want to take is go node by node in site.pp and try to
> provide descriptions for the content of each hiera lookup used (or when
> there are logical groups of hiera lookups descriptions for that group).
> That will hopefully make it more clear what the data is without needing to
> divulge the actual sensitive informtation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180330/6cfdcb9b/attachment.html>
More information about the OpenStack-Infra
mailing list