cf-charmers team mailing list archive

[Dustin Kirkland <kirkland@xxxxxxxxxxxxx>]

I certainly hope so, considering the summit starts Monday...

Ben, have you tried it yet with our bundle?  Is it usable?  Can we deploy
some basic apps?
On Jun 6, 2014 10:08 AM, "Manuel Garcia" <manuel.garcia@xxxxxxxxxxx> wrote:

> Hi guys,
>
> It seems this code may not be ready to be released to the community but I
> have a question: is MySQL Service Broker charm good enough (probably with
> little fixes) to be used for demos in the summit? Is there anything else,
> besides working on your feedback, we can do to achieve this goal?
>
> By ‘demo' I mean:
> - Deploy CF with MySQL Service Broker
> - Deploy, scale up and down, delete, etc an app which requires a MySQL
> service to bind to (e.g.: Wordpress or some other app based on an ‘out of
> the box’ build pack - java, ruby, go or node.js)
>
>
> Thanks,
> - Manuel Garcia
>
>
>
>
> On Jun 6, 2014, at 10:05 AM, Alexander Lomov <lomov.as@xxxxxxxxx> wrote:
>
> 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
>>>
>>>
>>>
>>
>
>