cf-charmers team mailing list archive

[Cory Johns <cory.johns@xxxxxxxxxxxxx>]

It seems my comment regarding avoiding connecting to CF was based on a
misunderstanding of something Ben said.  The service broker needs to
be registered with a running CF deployment, so we need to figure out
how to manage the dependency that the broker cannot be registered
until the CF deployment is up and ready; this needs to leverage the
services framework, so we need to define both what data will indicate
that the deployment is ready, as well as ensure that the data
condition triggers a hook in Juju so that the charm can be aware of
the transition.

Additionally, we certainly should not be calling create-space from
within the broker, so the org and space to target need to come from an
external source, whether that is from config options (i.e., spaces are
managed manually by the user) or from another charm (perhaps each
deployed instance, or even each unit, of the cloudfoundry orchestrator
charm should implicitly be within a single space, that the
orchestrator charm manages?).

On Mon, Jun 23, 2014 at 5:30 AM, Prismakov Alexander
<alexander.prismakov@xxxxxxxxxxx> wrote:
> Hi Cory,
>
> Thank you for the your review.
> I’m rewriting code using Python instead of CF CLI. To avoid juju hangs/deadlocks the script may be called as a separate process without waiting for completion. Without a guaranty of success...
> Can I ask you what did you mean writing “Would it be possible to run that as a normal Ubuntu service and avoid all of the difficulty of connecting to CF
> altogether?” What exact to run? The service broker? It runs as a service. We just need perform several steps to register the broker and the service in CF. With CF CLI or API.
>
> -Alex P.
>
> On Jun 20, 2014, at 19:28, Cory Johns <cory.johns@xxxxxxxxxxxxx> wrote:
>
>> Using the API at a minimum gives us better control over things like
>> timeouts.  See my earlier comment about the charm causing juju to hang
>> / deadlock... From what I can see, that still applies, since the
>> connect.sh script still sleep-waits, as well as the fact that
>> service-relation-joined hook doesn't use the services framework to
>> ensure that the data it needs is available (it doesn't even ensure
>> that the connect.sh script itself is in place yet).
>>
>> That issue, plus the presence of "create-space my-space" make me
>> seriously wonder if deploying the service broker as a CF app is even
>> the correct approach.  Would it be possible to run that as a normal
>> Ubuntu service and avoid all of the difficulty of connecting to CF
>> altogether?
>>
>>
>> On Thu, Jun 19, 2014 at 10:23 PM, Alexander Prismakov
>> <alexander.prismakov@xxxxxxxxxxx> wrote:
>>> Hi Cory,
>>>
>>> thank you for your remarks. As you may be already see, CF connection logic already removed from upstart script and called only when we add relation between CC and the broker.
>>> And, broker itself use REST API. CF CLI used only for registering the service in CF. Sure we may use just API calls for that, but why? There is special tools for it called CF CLI…
>>> In most of the charms we use command line tools like gunzip, wget, apt-get etc. Even charm helpers library use python wrappers for command line tools.
>>> Anyway, if you guys think that we have avoid using any cli tools and implement all logic using only plain Python I start rewriting this piece of code with GET/POST using Python.
>>>
>>> -Alex Prismakov | Altoros
>>>
>>> On Jun 19, 2014, at 19:22, Cory Johns <cory.johns@xxxxxxxxxxxxx> wrote:
>>>
>>>> Just to clarify, I was referring to the cf-mysql-broker charm, and
>>>> upon re-checking it, it's attempting to call the CF CLI in the upstart
>>>> script, which shouldn't actually be called until CF is ready after
>>>> all, so maybe just daemonizing it properly is the correct solution if
>>>> it really needs to sleep-wait for the API to be ready.  However, it
>>>> doesn't seem like this belongs in the upstart script, and should be
>>>> moved to the charm using requests, as previously mentioned.
>>>>
>>>> On Thu, Jun 19, 2014 at 9:05 AM, Cory Johns <cory.johns@xxxxxxxxxxxxx> wrote:
>>>>> My understanding was that it was a REST API
>>>>> (http://docs.cloudfoundry.org/services/api.html) and that you would
>>>>> just use requests
>>>>> (http://docs.python-requests.org/en/latest/index.html) or similar; am
>>>>> I misunderstanding the issue?
>>>>>
>>>>> Also, one big problem I ran into with the charm was that it attempted
>>>>> to communicate with CF before it was ready, and ended up blocking
>>>>> Juju, such that no further Juju commands would be responded to, even
>>>>> though nothing was in an error state.  (That this is possible, is also
>>>>> an issue in Juju, but we should avoid it in the charm, as well.  Also,
>>>>> the communication would fail anyway, since CF wasn't ready and was
>>>>> blocked on the broker charm to become ready.)
>>>>>
>>>>> On Thu, Jun 19, 2014 at 5:36 AM, Kapil Thangavelu
>>>>> <kapil.thangavelu@xxxxxxxxxxxxx> wrote:
>>>>>> I'd like to Ben to reply this as that was part of his feedback.
>>>>>>
>>>>>> -k
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 19, 2014 at 7:14 AM, Alexander Prismakov
>>>>>> <alexander.prismakov@xxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>> Hi Kapil, guys
>>>>>>>
>>>>>>> I fixed ‘credential issue’ in the charm and added new relation to CC.
>>>>>>> The charm still use CF CLI because I haven’t found answers on my
>>>>>>> questions. One more time: there is no Python wrapper for CC API calls.
>>>>>>> According to this post
>>>>>>> (http://blog.gopivotal.com/cloud-foundry-pivotal/products/working-with-the-cloud-controller-api-in-ruby-beyond-cfoundry)
>>>>>>> Ruby gem cfoundry also deprecated. So using CF CLI is only one option right
>>>>>>> now (let me know if you not agree). Second option is to develop Python
>>>>>>> wrapper from scratch.
>>>>>>> Could you please review this change?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Alex P. | Altoros
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~cf-charmers
>>>>>> Post to     : cf-charmers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~cf-charmers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>
>