← Back to team overview

cf-charmers team mailing list archive

Re: cf-mysql-charm code quality

 

Hi, all.

Let me share my vision of this problems:
1. hardcoded username and password: I agree that this is bad thing.
Kapil, currently we

Alex P., there is no possibility to set charm config options inside of
hooks. We already faced problem with autogenerated password and username
inside of NATS charm, this was main motivation to create
StaticContext/StoredContext (you can see it here
http://bazaar.launchpad.net/~cf-charmers/charms/trusty/cf-nats/trunk/view/head:/hooks/config.py#L18
)


2.







On 6 June 2014 14:50, <prismakov@xxxxxxxxx> wrote:

>
>
> Begin forwarded message:
>
> *From: *prismakov@xxxxxxxxx
> *Subject: **Re: cf-mysql-charm code quality*
> *Date: *June 6, 2014 at 12:51:48 GMT+3
> *To: *Kapil Thangavelu <kapil.thangavelu@xxxxxxxxxxxxx>
> *Cc: *Manuel Garcia <manuel.garcia@xxxxxxxxxxx>, "kirkland@xxxxxxxxxxxxx"
> <kirkland@xxxxxxxxxxxxx>, Benjamin Saller <benjamin.saller@xxxxxxxxxxxxx>,
> Antonio Rosales <antonio.rosales@xxxxxxxxxxxxx>
>
> Hi Kapil,
>
> Thank you for the review.
> Just want to clear some details:
>
> On Jun 6, 2014, at 1:04, Kapil Thangavelu <kapil.thangavelu@xxxxxxxxxxxxx>
> wrote:
>
> MySQL Broker
> Several issues that will need rewriting.
> upstart jobs. templates/cf-mysql-broker.conf
>
>    - hardcoded username and password.. this should never happen.
>
> Agree. It was like a temporary solution.
> But as you remember we already use hardcoded passwords in UAA charm -
> uaa.yml (admin/admin etc.).
> Is your idea to generate random passwords in uaa charm and then to extend
> uaa charm to providing credentials? (provides: credentials)?
> Then to use credentials provided by UAA in relations like uaa
> <->service_broker. Correct me if I wrong, please.
> How to provide the passwords to a user of CF charms? Store on file sistem
> and provde instructions in README (like "juju ssh uaa…”)?
>
>
>    - should be using a cc relation on a broker interface  to convey
>    registration of broker.
>
> Good idea.
>
>
>    -
>    - using CLI in deployed environment when there is an API and client
>    libs for these things
>    - If credentialed access is an issue (and it is) propose a fix or
>       request the feature
>
> Cold you please explain it. Is your idea to fork mysql service broker and
> extend it to handle all our needs?
>
>
>    -
>
> Copy and paste issues. please don’t do that.
>         see tests/02-simple hard-coded paths for a different charm.
>
>
> Use symlinks preferentially instead of copy paste on hooks (ie.
> start/stop/relation-hooks have identical content), else updates have to
> update many identical copies instead of a single central place.
>
> Etcd
> Not usable. Etcd is a replicated distributed database for which this
> charm's add-unit is broken (independent dbs instead of replicated) which
> defeats the entire purpose of etcd.  Also lots of extraneous copy and paste
> issues, many unused useless files lying around (scaffolding). Also needless
> extension of metadata.yaml
>
> Already had to rewrite from scratch.
>
> In time of working on etcd charm we haven’t support in our helpers of
> multi unit. Do we already have it? Or it is better to write it without
> using helpers at all to provide cluster feature which not needed right now?
>
> Any way thank you for letting me know it. Your comments are very important
> for me.
>
>
> - Alex Prismakov | Altoros
>
>
>

Follow ups