cf-charmers team mailing list archive

[prismakov@xxxxxxxxx]

Kapil, Guys

To improve mysql broker charm we need to get answers on questions I had asked in my email below.
Could you please provide needed information:
- Do we plan extend uaa charm to spread credentials?
- There is no good python wrapper for CF API. I found Ruby only. So what better to use in hooks instead of CF CLI? To develop new Python wrappers? To fork existing - https://github.com/KristianOellegaard/python-cloudfoundry (very limited)? To use Ruby gem?

- Alex Prismakov | Altoros



On Jun 6, 2014, at 12:51, prismakov@xxxxxxxxx wrote:

> 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 
>