Thanks for the review, looking at test failures now. Inline for the rest
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
File charmhelpers/contrib/openstack/context.py (right):
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:148: 'database_host':
rdata.get('db_host'),
On 2014年02月24日 14:27:56, jamespage wrote:
> I should probably know this but does .get on a dict return None if not found?
It does return None on not found.
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:161: 'database_ssl_cert': ''})
On 2014年02月24日 14:27:56, jamespage wrote:
> I'd be wary of setting these defaults - context_complete scans for None values
> to ensure that everything has been found.
context_complete all checks empty strings.. all the ssl stuff happens post
context_complete, cause its optional. i was doing empty value initialization
cause i wasn't sure about jinja2's behavior.. they have a separate 'defined'
command in template. i'll check and remove if that works okay.
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:168: log("Charm not setup for ssl
support but ssl ca found")
On 2014年02月24日 14:27:56, jamespage wrote:
> I'm not sure I understand this - does the charm consuming mysql services have
to
> be setup for SSL as well?
The context helper needs to be instantiated with the ssl_dir at min, this was to
warn against usage without ssl_dir, but then getting passed ssl relation data
and not being able to handle it. ie the charm needs an update.
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:175: time.sleep(60)
On 2014年02月24日 14:27:56, jamespage wrote:
> What else would be trying to create this?
So this comes up when mysql is operating as its own ca in ssl: only mode, where
it will create client certs to hand to clients. MySQL is pretty picky about its
certs signing, i was only able to get it to play nice with the x509 subcommand,
but that command doesn't let you specify a startDate (the option is display only
there) which leads to the scenario that a user gets a cert, and they can't use
it till the minute on the startDate of the cert rolls over, hence the sleep
here which happens only the first time we get a client cert (ie doesn't already
exist on disk). If mysql is being handed external certs, it won't do the client
cert thing.
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:181:
fh.write(b64decode(rdata['ssl_key']))
On 2014年02月24日 14:27:56, jamespage wrote:
> I'm assuming the ssl_key is a client key for access? In which case the
> permissions on this file should be limited as appropriate - probably to a
> relevant group but this could be a little fiddly as the openstack user who
needs
> access will vary by charm.
Yeah.. its a client cert and cert private key, it probably should be protected,
which means growing additional params for user at min for writing to disk given
the variance on charm users.
https://codereview.appspot.com/68080043/diff/1/charmhelpers/contrib/openstack...
charmhelpers/contrib/openstack/context.py:280: ctxt.setdefault('rabbit_ssl_ca',
'')
On 2014年02月24日 14:27:56, jamespage wrote:
> Ditto comment about using empty strings for values - leaving these unset is OK
> IMHO - the jinja2 templates deal with this ok
yeah.. i'll double check the jinja template behavior and yank if extraneous.