We're developing a list of Go cf CLI binaries to produce and wanted to get
feedback from the community on what should be included. So far, we've
committed to support:

Windows 7+
Mac OS X 10.7+
Ubuntu 10+
RHEL 5+ compatible Linux

Also, we're currently only producing 64-bit binaries, but we need
to support 32-bit too. Which 32-bit OS(s) should we be concerned with
first?

Thanks,
Scott

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

Search Discussions

  • Daniel Mikusa at Sep 23, 2013 at 10:59 am

    On Sep 22, 2013, at 9:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to get feedback from the community on what should be included. So far, we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux
    How will these be packaged for Linux? Will these be .deb and .rpm files? If so, could there also be a generic gzip / tar install?

    Dan
    Also, we're currently only producing 64-bit binaries, but we need to support 32-bit too. Which 32-bit OS(s) should we be concerned with first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • James Bayer at Sep 23, 2013 at 2:36 pm
    Our current plan is simply to distribute as binaries as compressed
    archives. Each platform only requires a single executable with no
    dependencies. Currently the compressed archive for each platform is about
    2MB compressed. If we discover that users really prefer a packaging
    mechanism we would certainly consider it.
    On Mon, Sep 23, 2013 at 3:59 AM, Daniel Mikusa wrote:
    On Sep 22, 2013, at 9:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to
    get feedback from the community on what should be included. So far, we've
    committed to support:
    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux
    How will these be packaged for Linux? Will these be .deb and .rpm files?
    If so, could there also be a generic gzip / tar install?

    Dan
    Also, we're currently only producing 64-bit binaries, but we need to
    support 32-bit too. Which 32-bit OS(s) should we be concerned with first?
    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Thank you,

    James Bayer

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Daniel Mikusa at Sep 23, 2013 at 3:47 pm

    On Sep 23, 2013, at 10:05 AM, James Bayer wrote:

    Our current plan is simply to distribute as binaries as compressed archives. Each platform only requires a single executable with no dependencies. Currently the compressed archive for each platform is about 2MB compressed. If we discover that users really prefer a packaging mechanism we would certainly consider it.
    Just throwing out my opinion here, but I generally like the compressed archive format. It tends to be more portable across Linux distros. IMHO, packaging is only nice if there is a repo, like an Ubuntu PPA, that you can connect to and get automatic updates.

    Having said that, what is the upgrade path going to be like with the Go cli? Will there be some auto-update or easy update mechanism? I liked how the Ruby cf client was easy to keep up-to-date by running "gem update".

    Dan
    On Mon, Sep 23, 2013 at 3:59 AM, Daniel Mikusa wrote:
    On Sep 22, 2013, at 9:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to get feedback from the community on what should be included. So far, we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux
    How will these be packaged for Linux? Will these be .deb and .rpm files? If so, could there also be a generic gzip / tar install?

    Dan
    Also, we're currently only producing 64-bit binaries, but we need to support 32-bit too. Which 32-bit OS(s) should we be concerned with first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.



    --
    Thank you,

    James Bayer

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Mike Youngstrom at Sep 23, 2013 at 6:20 pm
    32bit Windows 7+ is still fairly common in my org. Should probably provide
    a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to get
    feedback from the community on what should be included. So far, we've
    committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Scott Truitt at Sep 23, 2013 at 6:12 pm
    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to
    get feedback from the community on what should be included. So far, we've
    committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Dr Nic Williams at Sep 23, 2013 at 8:19 pm
    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic

    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt wrote:

    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to
    get feedback from the community on what should be included. So far, we've
    committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Matthew Reider at Sep 23, 2013 at 8:52 pm
    I like this idea. It's also how vSphere works. You get the right vCenter
    because vSphere has an install page you can browse to.

    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams wrote:

    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic

    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt wrote:

    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to
    get feedback from the community on what should be included. So far, we've
    committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mreider@gopivotal.com
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Matt Stine at Sep 23, 2013 at 9:24 pm
    +1000

    The best source for docs/language bindings/etc. related to a service
    endpoint is the service itself.

    On Mon, Sep 23, 2013 at 4:52 PM, Matthew Reider wrote:

    I like this idea. It's also how vSphere works. You get the right vCenter
    because vSphere has an install page you can browse to.

    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams wrote:

    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic

    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt wrote:

    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted to
    get feedback from the community on what should be included. So far, we've
    committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mreider@gopivotal.com
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Matt Stine | Community Engineer, Cloud Foundry | Pivotal
    901-493-5546 | Skype: mstine1978 | mstine@gopivotal.com

    goPivotal.com

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Patrick Mueller at Sep 26, 2013 at 2:35 pm
    One of the great things about using Go to build the CLI is that the
    executable is a single stand-alone executable. One of the constraints with
    Go right now is that you can only build executables, not shared libraries.
      Some people might consider that to be a plus (I tend towards that myself).
      It is a little different than what I'm used to.

    I think the story would be to have two executables. The launcher, and the
    meat. The launcher would be what the user invokes from the command-line,
    and the launcher would then exec() to the version-specific meat; most
    current meaty version if no target context, else the most recent compatible
    meaty version if there is a target context. Targets already cache their
    version in ~/.cf/tokens.yml

    The launcher would of course be able to install/manage multiple versions of
    the meaty executable.

    In any case, one of my current requirements for "multi-version cf cli" is
    that I need to be able to work with multiple versions on the same machine
    at the same time. I'm currently using two different cf installations with
    two different versions, at times I've used three, and I don't see the
    number getting much smaller than that. :-)

    Ideally, I don't have to do *anything* to "switch versions". The cli will
    do the right thing for the version of the target I'm playing with, as set
    via "cf target http://example.com/foo"


    On Mon, Sep 23, 2013 at 5:24 PM, Matt Stine wrote:

    +1000

    The best source for docs/language bindings/etc. related to a service
    endpoint is the service itself.

    On Mon, Sep 23, 2013 at 4:52 PM, Matthew Reider wrote:

    I like this idea. It's also how vSphere works. You get the right vCenter
    because vSphere has an install page you can browse to.


    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams <drnicwilliams@gmail.com
    wrote:
    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic

    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt wrote:

    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted
    to get feedback from the community on what should be included. So far,
    we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+unsubscribe@cloudfoundry.org.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mreider@gopivotal.com
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Matt Stine | Community Engineer, Cloud Foundry | Pivotal
    901-493-5546 | Skype: mstine1978 | mstine@gopivotal.com

    goPivotal.com

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.


    --
    Patrick Mueller
    http://muellerware.org

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Mike Heath at Sep 26, 2013 at 3:07 pm
    How will the CLI know which version of CF is being targeted? The /info
    endpoint on the Cloud Controller has a "version" field with the value of
    "2" but this seems a little too simplistic to split the CLI into just two
    executables. For example, how does the launcher know if it needs to use
    "meat" to support loggregator or not? The same could potentially apply to
    using v2 services or not.

    What about plug-ins? We get a lot of value out of plugins with the existing
    CLI and I'm assuming if we want to continue to get this value with the new
    CLI, we're going to have to compile and distribute our own CLI. How will
    the launcher know to use our custom "meat"?

    -Mike
    On Thursday, September 26, 2013 8:34:27 AM UTC-6, Patrick Mueller wrote:

    One of the great things about using Go to build the CLI is that the
    executable is a single stand-alone executable. One of the constraints with
    Go right now is that you can only build executables, not shared libraries.
    Some people might consider that to be a plus (I tend towards that myself).
    It is a little different than what I'm used to.

    I think the story would be to have two executables. The launcher, and the
    meat. The launcher would be what the user invokes from the command-line,
    and the launcher would then exec() to the version-specific meat; most
    current meaty version if no target context, else the most recent compatible
    meaty version if there is a target context. Targets already cache their
    version in ~/.cf/tokens.yml

    The launcher would of course be able to install/manage multiple versions
    of the meaty executable.

    In any case, one of my current requirements for "multi-version cf cli" is
    that I need to be able to work with multiple versions on the same machine
    at the same time. I'm currently using two different cf installations with
    two different versions, at times I've used three, and I don't see the
    number getting much smaller than that. :-)

    Ideally, I don't have to do *anything* to "switch versions". The cli will
    do the right thing for the version of the target I'm playing with, as set
    via "cf target http://example.com/foo"



    On Mon, Sep 23, 2013 at 5:24 PM, Matt Stine <mst...@gopivotal.com<javascript:>
    wrote:
    +1000

    The best source for docs/language bindings/etc. related to a service
    endpoint is the service itself.


    On Mon, Sep 23, 2013 at 4:52 PM, Matthew Reider <mre...@gopivotal.com<javascript:>
    wrote:
    I like this idea. It's also how vSphere works. You get the right vCenter
    because vSphere has an install page you can browse to.


    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams <drnicw...@gmail.com<javascript:>
    wrote:
    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic


    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt <str...@gopivotal.com<javascript:>
    wrote:
    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.


    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom <you...@gmail.com<javascript:>
    wrote:
    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike


    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt <str...@gopivotal.com<javascript:>
    wrote:
    We're developing a list of Go cf CLI binaries to produce and wanted
    to get feedback from the community on what should be included. So far,
    we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mre...@gopivotal.com <javascript:>
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Matt Stine | Community Engineer, Cloud Foundry | Pivotal
    901-493-5546 | Skype: mstine1978 | mstine@gopivotal.com

    goPivotal.com

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Patrick Mueller
    http://muellerware.org
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Dr Nic Williams at Sep 26, 2013 at 3:09 pm
    Re plugins I think packer does plugins via a collection of delegated apps. I think docker wants to go down the same route.
    On Thu, Sep 26, 2013 at 8:07 AM, Mike Heath wrote:

    How will the CLI know which version of CF is being targeted? The /info
    endpoint on the Cloud Controller has a "version" field with the value of
    "2" but this seems a little too simplistic to split the CLI into just two
    executables. For example, how does the launcher know if it needs to use
    "meat" to support loggregator or not? The same could potentially apply to
    using v2 services or not.
    What about plug-ins? We get a lot of value out of plugins with the existing
    CLI and I'm assuming if we want to continue to get this value with the new
    CLI, we're going to have to compile and distribute our own CLI. How will
    the launcher know to use our custom "meat"?
    -Mike
    On Thursday, September 26, 2013 8:34:27 AM UTC-6, Patrick Mueller wrote:

    One of the great things about using Go to build the CLI is that the
    executable is a single stand-alone executable. One of the constraints with
    Go right now is that you can only build executables, not shared libraries.
    Some people might consider that to be a plus (I tend towards that myself).
    It is a little different than what I'm used to.

    I think the story would be to have two executables. The launcher, and the
    meat. The launcher would be what the user invokes from the command-line,
    and the launcher would then exec() to the version-specific meat; most
    current meaty version if no target context, else the most recent compatible
    meaty version if there is a target context. Targets already cache their
    version in ~/.cf/tokens.yml

    The launcher would of course be able to install/manage multiple versions
    of the meaty executable.

    In any case, one of my current requirements for "multi-version cf cli" is
    that I need to be able to work with multiple versions on the same machine
    at the same time. I'm currently using two different cf installations with
    two different versions, at times I've used three, and I don't see the
    number getting much smaller than that. :-)

    Ideally, I don't have to do *anything* to "switch versions". The cli will
    do the right thing for the version of the target I'm playing with, as set
    via "cf target http://example.com/foo"



    On Mon, Sep 23, 2013 at 5:24 PM, Matt Stine <mst...@gopivotal.com<javascript:>
    wrote:
    +1000

    The best source for docs/language bindings/etc. related to a service
    endpoint is the service itself.


    On Mon, Sep 23, 2013 at 4:52 PM, Matthew Reider <mre...@gopivotal.com<javascript:>
    wrote:
    I like this idea. It's also how vSphere works. You get the right vCenter
    because vSphere has an install page you can browse to.


    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams <drnicw...@gmail.com<javascript:>
    wrote:
    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic


    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt <str...@gopivotal.com<javascript:>
    wrote:
    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.


    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom <you...@gmail.com<javascript:>
    wrote:
    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike


    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt <str...@gopivotal.com<javascript:>
    wrote:
    We're developing a list of Go cf CLI binaries to produce and wanted
    to get feedback from the community on what should be included. So far,
    we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mre...@gopivotal.com <javascript:>
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Matt Stine | Community Engineer, Cloud Foundry | Pivotal
    901-493-5546 | Skype: mstine1978 | mstine@gopivotal.com

    goPivotal.com

    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+u...@cloudfoundry.org <javascript:>.


    --
    Patrick Mueller
    http://muellerware.org
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Scott Truitt at Sep 26, 2013 at 5:21 pm
    We're well aware of the limits of our current API versioning approach, and
    actively discussing about how best to evolve it in the context of the CLI.
    Nothing concrete to report, but we're on it.

    On Thu, Sep 26, 2013 at 8:07 AM, Mike Heath wrote:

    How will the CLI know which version of CF is being targeted? The /info
    endpoint on the Cloud Controller has a "version" field with the value of
    "2" but this seems a little too simplistic to split the CLI into just two
    executables. For example, how does the launcher know if it needs to use
    "meat" to support loggregator or not? The same could potentially apply to
    using v2 services or not.

    What about plug-ins? We get a lot of value out of plugins with the
    existing CLI and I'm assuming if we want to continue to get this value with
    the new CLI, we're going to have to compile and distribute our own CLI. How
    will the launcher know to use our custom "meat"?

    -Mike

    On Thursday, September 26, 2013 8:34:27 AM UTC-6, Patrick Mueller wrote:

    One of the great things about using Go to build the CLI is that the
    executable is a single stand-alone executable. One of the constraints with
    Go right now is that you can only build executables, not shared libraries.
    Some people might consider that to be a plus (I tend towards that myself).
    It is a little different than what I'm used to.

    I think the story would be to have two executables. The launcher, and
    the meat. The launcher would be what the user invokes from the
    command-line, and the launcher would then exec() to the version-specific
    meat; most current meaty version if no target context, else the most recent
    compatible meaty version if there is a target context. Targets already
    cache their version in ~/.cf/tokens.yml

    The launcher would of course be able to install/manage multiple versions
    of the meaty executable.

    In any case, one of my current requirements for "multi-version cf cli" is
    that I need to be able to work with multiple versions on the same machine
    at the same time. I'm currently using two different cf installations with
    two different versions, at times I've used three, and I don't see the
    number getting much smaller than that. :-)

    Ideally, I don't have to do *anything* to "switch versions". The cli
    will do the right thing for the version of the target I'm playing with, as
    set via "cf target http://example.com/foo"


    On Mon, Sep 23, 2013 at 5:24 PM, Matt Stine wrote:

    +1000

    The best source for docs/language bindings/etc. related to a service
    endpoint is the service itself.

    On Mon, Sep 23, 2013 at 4:52 PM, Matthew Reider wrote:

    I like this idea. It's also how vSphere works. You get the right
    vCenter because vSphere has an install page you can browse to.

    On Mon, Sep 23, 2013 at 1:19 PM, Dr Nic Williams wrote:

    Dan's question about "upgrade path" was to be my question (and I think
    there's a different thread on the topic). Perhaps the CLI itself should be
    self updating; perhaps like Jenkins - you get the matching CLI from your
    backend service. That is, perhaps ccng distributes the go CLIs that are
    used to access it.

    Nic

    On Mon, Sep 23, 2013 at 8:12 PM, Scott Truitt wrote:

    Thanks, Mike, work on 32-bit Windows 7+ is in flight now.

    Dan, we're discussing a number of paths to updating. Will keep you
    posted.

    On Mon, Sep 23, 2013 at 8:54 AM, Mike Youngstrom wrote:

    32bit Windows 7+ is still fairly common in my org. Should probably
    provide a build for that.

    Mike

    On Sun, Sep 22, 2013 at 7:45 AM, Scott Truitt wrote:

    We're developing a list of Go cf CLI binaries to produce and wanted
    to get feedback from the community on what should be included. So far,
    we've committed to support:

    Windows 7+
    Mac OS X 10.7+
    Ubuntu 10+
    RHEL 5+ compatible Linux

    Also, we're currently only producing 64-bit binaries, but we need
    to support 32-bit too. Which 32-bit OS(s) should we be concerned with
    first?

    Thanks,
    Scott

    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@**cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@**cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to vcap-dev+u...@**cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@**cloudfoundry.org.


    --

    Matthew Reider
    Cloud Foundry Global Product Manager
    Pivotal
    875 Howard St. 5th Fl
    San Francisco CA 94103
    mre...@gopivotal.com
    415.990.3740

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@**cloudfoundry.org.


    --
    Matt Stine | Community Engineer, Cloud Foundry | Pivotal
    901-493-5546 | Skype: mstine1978 | mstine@gopivotal.com

    goPivotal.com

    To unsubscribe from this group and stop receiving emails from it, send
    an email to vcap-dev+u...@**cloudfoundry.org.


    --
    Patrick Mueller
    http://muellerware.org
    To unsubscribe from this group and stop receiving emails from it, send an
    email to vcap-dev+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Patrick Mueller at Sep 26, 2013 at 5:55 pm

    On Thu, Sep 26, 2013 at 11:07 AM, Mike Heath wrote:

    How will the CLI know which version of CF is being targeted? The /info
    endpoint on the Cloud Controller has a "version" field with the value of
    "2" but this seems a little too simplistic to split the CLI into just two
    executables. For example, how does the launcher know if it needs to use
    "meat" to support loggregator or not? The same could potentially apply to
    using v2 services or not.
    The launcher may be very thin - just figure out which version of the meaty
    executable to use (you would have one for every version of CF api you
    needed to use), and then pass the command onto it. If you try to run a
    "new" subcommand using an older meaty executable, the older meaty
    executable would presumably claim "subcommand not supported".

    That's the easy answer anyway :-)

    What about plug-ins? We get a lot of value out of plugins with the existing
    CLI and I'm assuming if we want to continue to get this value with the new
    CLI, we're going to have to compile and distribute our own CLI. How will
    the launcher know to use our custom "meat"?
    wrt plugins, I had posted some thoughts on that (do it the way git allows
    you to add subcommands, and also have the cli spit out JSON for
    "programmatic invocation"), on a previous thread [1]. I'm curious to look
    at packer's and docker's approaches also.

    [1]
    https://groups.google.com/a/cloudfoundry.org/d/topic/vcap-dev/Xa56uBdjD1U/discussion

    --
    Patrick Mueller
    http://muellerware.org

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Jan Dubois at Sep 26, 2013 at 6:15 pm

    On Thu, Sep 26, 2013 at 10:54 AM, Patrick Mueller wrote:
    The launcher may be very thin - just figure out which version of the meaty
    executable to use (you would have one for every version of CF api you needed
    to use), and then pass the command onto it.
    Is this really a good idea? If you can't keep the HTTP interface
    stable, or at least backwards compatible, why do you believe you can
    do a better job with the CLI? Because in your scenario the CLI becomes
    the new API; no other software will be able to re-implement the meaty
    parts for each CF release. So you are just moving the API
    compatibility problem from one point to another, not actually solving
    it.

    This new scenario also means that the CF API now is restricted to
    places than can run the CLI binary. E.g. the Eclipse interface for CF
    must be rewritten to shell out to the CLI executable instead of
    talking to the CC via HTTP. But what happens if you want to use it on
    your Solaris box? Who is going to produce the meaty binaries for that?
      Right now any system with an HTTP library can talk to CF. Throwing
    that away seems like a step backwards to me.

    Cheers,
    -Jan

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Patrick Mueller at Sep 26, 2013 at 7:13 pm

    On Thu, Sep 26, 2013 at 2:14 PM, Jan Dubois wrote:
    On Thu, Sep 26, 2013 at 10:54 AM, Patrick Mueller wrote:
    The launcher may be very thin - just figure out which version of the meaty
    executable to use (you would have one for every version of CF api you needed
    to use), and then pass the command onto it.
    Is this really a good idea? If you can't keep the HTTP interface
    stable, or at least backwards compatible, why do you believe you can
    do a better job with the CLI?
    First, my assumption has been that there are essentially TWO APIs - the
    HTTP API, and the command-line. Today the command-line isn't an API - in
    that you can't really use it to script non-trivial programs. But I'd like
    to be able to do that in script-y friendly languages (ruby, node, perl,
    python, whatever).

    These two APIs really serve two different needs, and I think both are
    required. Of course, the command-line API is "built on top of" the HTTP
    API.

    I don't think it's possible to keep a large-ish HTTP API stable or
    backwards compatible, in general. Can you prove me wrong? I think most
    folks have given up on that pipe-dream, and instead version their HTTP APIs
    by putting the version in the URL [1]. Seems totally workable to me. And,
    BTW, that's what CF is doing anyway [2]. :-)

    Dealing with the command-line is different though, and using Go adds it's
    own wrinkles. That's all I was discussing here.

    I should note I mentioned in the group at some point that I would hope the
    JSON that the CLI will hopefully be able to spit out to be the same as the
    JSON you get from the HTTP API, so that at least that documentation
    (description of JSON structures) could be shared between the HTTP and CLI
    APIs.

    [1] https://dev.twitter.com/docs/api/1.1/get/statuses/mentions_timeline
    [2] http://docs.cloudfoundry.com/docs/reference/cc-api.html

    --
    Patrick Mueller
    http://muellerware.org

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Jan Dubois at Sep 26, 2013 at 7:45 pm

    On Thu, Sep 26, 2013 at 12:12 PM, Patrick Mueller wrote:
    On Thu, Sep 26, 2013 at 2:14 PM, Jan Dubois wrote:
    Is this really a good idea? If you can't keep the HTTP interface
    stable, or at least backwards compatible, why do you believe you can
    do a better job with the CLI?
    First, my assumption has been that there are essentially TWO APIs - the HTTP
    API, and the command-line. Today the command-line isn't an API - in that
    you can't really use it to script non-trivial programs. But I'd like to be
    able to do that in script-y friendly languages (ruby, node, perl, python,
    whatever).

    These two APIs really serve two different needs, and I think both are
    required. Of course, the command-line API is "built on top of" the HTTP
    API.
    I'm in complete agreement so far.
    I don't think it's possible to keep a large-ish HTTP API stable or backwards
    compatible, in general. Can you prove me wrong? I think most folks have
    given up on that pipe-dream, and instead version their HTTP APIs by putting
    the version in the URL [1]. Seems totally workable to me. And, BTW, that's
    what CF is doing anyway [2]. :-)
    I also agree that a versioned API is necessary because you can't keep
    your API stable forever. But I disagree that it is impossible to keep
    an API backward compatible, at least during a single major version. I
    find the following requirements completely reasonable:

    * The latest client can talk to all older releases of the backend.
    * Any older client will continue to work against newer backends, but
    obviously won't support functionality added later.

    ("Any" and "all" are referring to instances of the same major release
    series only, e.g. CFv2).

    As I wrote before, if you think you cannot guarantee backwards
    compatibility at the backend API level, how can you guarantee it for
    the CLI API? Any code you have to add to the CLI to maintain
    compatibility could be added to the backend instead. What makes them
    different, except that different teams work on them?
    Dealing with the command-line is different though, and using Go adds it's
    own wrinkles. That's all I was discussing here.

    I should note I mentioned in the group at some point that I would hope the
    JSON that the CLI will hopefully be able to spit out to be the same as the
    JSON you get from the HTTP API, so that at least that documentation
    (description of JSON structures) could be shared between the HTTP and CLI
    APIs.
    That would be great!

    Cheers,
    -Jan

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.
  • Patrick Mueller at Sep 26, 2013 at 8:45 pm

    On Thu, Sep 26, 2013 at 3:44 PM, Jan Dubois wrote:

    I find the following requirements completely reasonable:

    * The latest client can talk to all older releases of the backend.
    * Any older client will continue to work against newer backends, but
    obviously won't support functionality added later.

    ("Any" and "all" are referring to instances of the same major release
    series only, e.g. CFv2).
    Sorry, I assumed you meant a single API that was always compatible with
    every version ever released. What you are describing is closer to semver
    [1], which I think would be a fine goal to set in terms of what the version
    numbers used by CF imply.

    [1] http://semver.org/

    --
    Patrick Mueller
    http://muellerware.org

    To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedSep 22, '13 at 1:45p
activeSep 26, '13 at 8:45p
posts18
users10

People

Translate

site design / logo © 2021 Grokbase