cf-charmers team mailing list archive

[Cory Johns <cory.johns@xxxxxxxxxxxxx>]

I agree that, to register a service broker, a space is required.
However, that does not imply that we must create a space when the cc
<-> broker relation is joined, just that we must delay registering the
service broker until the space is available.  This is the distinction
that the services framework has over the vanilla juju hooks framework:
we're no longer defining *when* something needs to happen, but,
rather, what is required *before* it can happen.

And for that, I can immediately see two possibilities, that I
mentioned previously, for how the space can be created: manually by
the user (and communicated by a config set), or (semi)automatically by
a charm (e.g., the orchestrator, cf-controller, a stand-alone charm
specifically for representing a space, etc) (and communicated via the
relation).  But I'm not at all certain that those are the only two
options.

On Mon, Jun 23, 2014 at 8:52 AM, Alex Prismakov <prismakov@xxxxxxxxx> wrote:
> Cory,
> To register the broker/service during CF deployment with a bundle we need a
> space in CF. Before any user interaction. It may be defined in a config
> file. But we need create it when CC-Broker relation occurs.
> -Alex P.
>
> 23 июня 2014 г. 18:28 пользователь "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
>> >>>>>>
>> >>>
>> >
>>
>> --
>> 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