cf-charmers team mailing list archive

[Alex Prismakov <prismakov@xxxxxxxxx>]

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
>