1. 26 Feb, 2018 1 commit
  2. 23 Feb, 2018 1 commit
    • Jessica Yuen's avatar
      App spec to take a single destination · 936e31ab
      Jessica Yuen authored
      Currently the app.yaml spec takes a list of destinations. The change
      exists to anticipate support for an environment supporting multiple
      clusters or "destinations". The problem is, while the use case makes
      sense for `apply`, and `delete`, it becomes ambiguous which cluster is
      being referred to during commands such as `diff`. We've considered
      specifying a cluster during a `diff`, however, ks currently doesn't have
      a notion of a cluster identity. This change is to update the app.yaml to
      take a single destination to more accurately represent the state of
      Signed-off-by: default avatarJessica Yuen <im.jessicayuen@gmail.com>
  3. 21 Feb, 2018 1 commit
  4. 17 Feb, 2018 1 commit
  5. 08 Feb, 2018 3 commits
  6. 02 Feb, 2018 1 commit
    • Jessica Yuen's avatar
      Migrate environment spec.json to the app.yaml model · 19b3b928
      Jessica Yuen authored
      Currently spec.json contains detail about an environment's namespace and
      server. Following the proposal at
      design/proposals/modular-components.md, this change will consolidate
      environment specifications in the common ksonnet app.yaml file.
      An environment specification for the environment "dev", may look as
          - namespace: foo
            server: example.com
          k8sVersion: "1.8.1"
          path: dev
          - db
      Note: This change currently doesn't support
      (1) population of the k8sVersion field. This will occur as we migrate
      the environment .metadata folder.
      (2) deployment to more than one destination. This will occur once ks
      supports multi-cluster deployment.
      (3) setting of details other than the env name in `ks env set`. Prior
      to this change, users are able to namespace and server URI, however it
      becomes ambiguous which namespace is being set for an environment where
      there can be multiple destinations. We will encourage configuration in
      app.yaml itself.
      (4) targets. This will come in a later change.
      Signed-off-by: default avatarJessica Yuen <im.jessicayuen@gmail.com>
  7. 30 Jan, 2018 1 commit
  8. 10 Jan, 2018 1 commit
  9. 02 Jan, 2018 1 commit
  10. 13 Dec, 2017 1 commit
  11. 30 Nov, 2017 2 commits
  12. 29 Nov, 2017 2 commits
    • Jessica Yuen's avatar
      Only overwrite namespace, server if not explicitly specified · fccf212e
      Jessica Yuen authored
      Currently, namespace and server is being overwritten by the environment
      despite the user explicitly passing in the `--namespace` flag.
      Ex: during `ks apply dev --namespace=ns2`, `ns2` should take preference
      to the namespace specified by the dev environment.
      Signed-off-by: default avatarJessica Yuen <im.jessicayuen@gmail.com>
    • Alex Clemmer's avatar
      💪 Make env-name a required param in "env commands" · 4923a3f5
      Alex Clemmer authored
      Fixes #100.
      This commit will transition the ksonnet CLI away from accepting either a
      list of files or an environment (or both). A detailed explanation
      Historically, the ksonnet CLI has had several "environment commands".
      These commands (e.g., `apply`, `diff`, `delete`, `show`, etc.) all took
      one of the following:
        1. An environment name. For example, `apply us-west/dev` will `apply`
           everything in the `components/` directory to the cluster denoted by
        2. A set of files. For example, `apply -f foo.jsonnet -f bar.jsonnet`
           would apply those two specific Jsonnet files to the server
           specified by the current context in $KUBECONFIG.
        3. Both an environment name and a set of files. For example,
           `apply us-west/dev -f foo.jsonnet -f bar.jsonnet` would `apply`
           those two files to the cluster denoted by the `us-west/dev`
      This "duality" remained in place primarily because it was important for
      the ksonnet CLI to maintain functional compatibility (though not strict
      CLI-level app compatibility) with the kubecfg tool.
      Some time ago the ksonnet CLI was forked from the kubecfg CLI, but it is
      only in this commit that we abandon this duality. Specifically, this
      commit will _require_ the environment name for all commands. For
      example, the form of `apply` will now be:
      `apply <env-name> [-f <file>]`.
      There are main parts to this:
        1. Refactoring core abstractions that supports this "duality".
           Specifically, removing the `cmd.envSpec` type and several
           functions, such as `cmd.parseEnvCmd`.
        2. Updating the tests to reflect this new directory structure.
      Signed-off-by: default avatarJessica Yuen <im.jessicayuen@gmail.com>
  13. 28 Nov, 2017 1 commit
  14. 22 Nov, 2017 1 commit
    • Jessica Yuen's avatar
      Improve logging for init · 97631513
      Jessica Yuen authored
      - Add message:  Creating a new app 'foo' at path '/path/to/foo'
      - On success, add message:  ksonnet app successfully created! Next, try
        creating a component with `ks generate`
      - On failure, provide suggestions for the user.
      - Make note that the context is retrieved from the kubeconfig file at
        the environment variable $KUBECONFIG
  15. 21 Nov, 2017 1 commit
    • Alex Clemmer's avatar
      Fix `nil` dereference error in #129 · 7cd60cc1
      Alex Clemmer authored
      In line 161 of `root.go`, we're failing to check whether a cluster in
      the $KUBECONFIG clusters array exists before using it. This will cause a
      `nil` dereference error.
  16. 15 Nov, 2017 2 commits
  17. 13 Nov, 2017 1 commit
    • Jessica Yuen's avatar
      Provide access to ExtCodes when the '-f' flag is provided · c97220f4
      Jessica Yuen authored
      Currently, ExtCodes are only provided when the 'env' flag is present in
      commands. The result is errors occuring when we run commands such as `ks
      show default -f components/guestbook-ui.jsonnet`, where the params
      ExtVar is needed. This commit fixes that scenario.
  18. 08 Nov, 2017 3 commits
    • Jessica Yuen's avatar
      Jsonnet handling of component names with special characters · ce2d567d
      Jessica Yuen authored
      Currently, if a component name contains a special character, ex:
      foo-bar, this translates to the jsonnet identifier: foo-bar, which is
      invalid syntax.
      This change will quote component names where there are special
    • Alex Clemmer's avatar
      Add `vendor/` to Jsonnet paths · 5327cf5c
      Alex Clemmer authored
      This resolves the first half of #68. When we `generate` using a
      prototype from a vendored dependency, it often results in a compilation
      error when we `apply`, because these prototypes usually depend on code
      that exists in the dependency, and `vendor/` is not a part of the
      Jsonnet search path.
      This commit resolves this problem by adding it to the search path.
    • Jessica Yuen's avatar
      Pass overrides by reference when initiating client · beddf415
      Jessica Yuen authored
      This fixes the bug where objects weren't being deployed to the cluster
      specified by the environment. This bug occurred because overrides (ex:
      cluster, namespace) were being lost because we weren't applying the
      changes to the correct override object. To fix this, we needed to pass
      the overrides by reference.
  19. 31 Oct, 2017 1 commit
    • Jessica Yuen's avatar
      Expand environment params.libsonnet · d55fbed6
      Jessica Yuen authored
      Expose the import path to environments/:env/params.libsonnet as an
      ExtCode so that it is made accessible to component files during
  20. 26 Oct, 2017 2 commits
    • Jessica Yuen's avatar
      Rename environment uri references to server · 3c9e07e9
      Jessica Yuen authored
      'server' is consistent with what is used by clientgo. 'uri' only
      introduces new language to ksonnet with the same meaning.
    • Jessica Yuen's avatar
      Support `diff` between two environments · 2687c6d8
      Jessica Yuen authored
      This change enables the user to diff between two environments that are
      either local or remote.
      `kubecfg diff local:dev local:prod` will diff between the expanded
      templates for each environment on disk.
      `kubecfg diff remote:dev remote:prod` will diff between two remote
      environment clusters. It does this by first expanding the component
      templates of each environment. Then, the live objects are fetched from
      each of the clusters and the diff is performed against the live objects.
      `kubecfg diff local:dev remote:prod` is also an option. This will diff
      between the expanded templates for 'dev' on disk and the live objects
      on 'prod's server.
  21. 25 Oct, 2017 2 commits
    • Jessica Yuen's avatar
      Set env namespace to default when namespace not provided · 209a5abf
      Jessica Yuen authored
      `ks env set foo --namespace=""` and `ks env add foo` will both set the
      namespace to 'default' in the environment's spec.json file.
    • Jessica Yuen's avatar
      Init env metadata from provided context · e3e35d30
      Jessica Yuen authored
      `ks env add myenv --context=dev` will initialize the environment URI
      and namespace based on the context `dev`, as specfied in the
      kubeconfig file. The same applies for `ks init foo --context=dev`.
      If both the context and uri argument is not provided, the current
      context is used.
      This change will also remove uri as a mandatory arg in `ks env add`.
      The uri will be moved to a flag. It cannot be used at the same time as
  22. 17 Oct, 2017 3 commits
  23. 06 Oct, 2017 2 commits
    • Jessica Yuen's avatar
      Expand environment .jsonnet file · 6378e75a
      Jessica Yuen authored
      Commands that take `env` as a param currently expand all files in the
      `components` directory. This is no longer necessary with the
      introduction of `base.libsonnet` and the per-environment override
      `<env>.jsonnet` file.
      This commit will simply expand the single `<env>.jsonnet` file (which
      will implicitly expand all component files). The case of running
      `ksonnet apply default`, is equivalent to running `ksonnet apply -f
    • Jessica Yuen's avatar
      Generate base.libsonnet in environments/ · 4b50beb8
      Jessica Yuen authored
      base.libsonnet is a generated file that exists at the root of the
      environments directory. This file is generated for all ksonnet projects.
      The main goal of this file is to import all components in the components
      directory, so that environments are able to easily extend / override any
      one of these components in a modular structure.
  24. 05 Oct, 2017 1 commit
    • Jessica Yuen's avatar
      Remove unnecessary param from defaultNamespace() · c95cde93
      Jessica Yuen authored
      The `clientConfig` param currently being passed is not needed, because
      it exists as a package level var in root. It also makes little sense to
      pass a custom `clientConfig` because if `overrides.Context.Namespace` is
      populated, the namespace that is returned is configured as an override
      in the package level `clientConfig` and not the `clientConfig` in the
  25. 03 Oct, 2017 1 commit
    • Jessica Yuen's avatar
      Construct base components object · c97498df
      Jessica Yuen authored
      In order to support environment heirarchy, we need to be able to
      reference all components. This commit will implement component imports
      as k-v pairs ex: foo: "import/foo.jsonnet" as a Jsonnet object. This
      jsonnet object will then be assigned as an ExtCode so that it can be
      referenced by a base.libsonnet file which environments can build /
      override upon.
  26. 27 Sep, 2017 1 commit
  27. 21 Sep, 2017 2 commits
    • Alex Clemmer's avatar
      Remove client-go flags from commands that don't use them · f9723645
      Alex Clemmer authored
      Fixes #108.
    • Alex Clemmer's avatar
      Fix improper elision of -J flags · 4509a351
      Alex Clemmer authored
      Currently if we use a command like `apply default -f
      components/whatever.yaml`, kubecfg will fail to emit flags that add
      ksonnet-lib to the -J paths. This means that, while a command like
      `apply default` will correctly linke against (e.g.) `k.libsonnet`,
      adding the `-f` flag will not.
      This commit will correct this problem for all commands of this form.