cf-charmers team mailing list archive

[Alexander Lomov <lomov.as@xxxxxxxxx>]

Sorry for the last message. Pressed some Gmail magic buttons by mistake.

I'll continue:

1. *hardcoded username and password*: I agree that this is bad thing, but
now this not only problem for cf-mysql-broker.

Kapil, currently we have hardcoded password and username for admin in
uaa.yml. This is something that should be fixed before fixing this problem
inside the broker. (see this line
http://bazaar.launchpad.net/~cf-charmers/charms/trusty/cf-uaa/trunk/view/head:/templates/uaa.yml#L75
)

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. *using a cc relation on a broker interface to convey registration of
broker. *At this moment this relation will only show logical context. By
the way we can perform service registration on CC side inside relation
hook. What do you think about it?


3. *using CLI in deployed environment. *As for me this is a quick and
working way of doing this interaction. As I see there are python client for
cloudfoundry (https://github.com/KristianOellegaard/python-cloudfoundry),
but it doesn't have all functionality and using CLI was a quicker way to
perform all necessary actions. Anyway you are right, this should be changed
with time.


4. *Etcd*: to make cluster deployments we need to solve problem with
multy-unit connection, I've described it here:
https://lists.launchpad.net/cf-charmers/msg00220.html



Thank you,
Alex L.




On 6 June 2014 15:45, Alexander Lomov <lomov.as@xxxxxxxxx> wrote:

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