- Nov 04, 2017
-
-
Jessica Yuen authored
Parameters are the customizable fields defining ksonnet components. For example, replica count, component name, or deployment image. Parameters are also able to be defined separately across environments. Meaning, this supports features to allow a "development" environment to only run a single replication instance for it's components, whereas allowing a "production" environment to run more replication instances to meet heavier production load demands. 'ks param set' is defined as follows: 'ks param set <component-name> <param-key> <param-value>' Examples: Updates the replica count of the 'guestbook' component to 4. 'ks param set guestbook replicas 4' Updates the replica count of the 'guestbook' component to 2 for the environment 'dev' 'ks param set guestbook replicas 2 --env=dev'
-
Jessica Yuen authored
The goal of this commit is to add an interface to `metadata.Manager` that allows retrieving of all environment params: `getEnvironmentParams(envName)`. This is done by: 1. Adding functionality to the snippet parser to get all environment params out of the snippet read from `environments/<env>/params.libsonnet` 2. Adding functionality to the snippet parser to get all component params out of the snippet read from `components/params.libsonnet` 3. Having the `metadata.Manager` implementation handle the 'joining' of params from 1) and 2), and returning that result.
-
Jessica Yuen authored
This commit will add an interface `SetEnvironmentParams` to metadata.Manager that allows setting of env params. Also implements the logic for parsing the jsonnet snippet to append / modify params in simple env param schemas. It will: 1. Update the params if the component exists in the jsonnet snippet. 2. Add the component if it does not exist.
-
Jessica Yuen authored
This commit will add an interface `GetComponentParams` to metadata.Manager that returns a map of parameters for the passed in component. Also implements the logic for parsing the jsonnet snippet to retrieve the parameters. This functionality will later support new commands to list parameters.
-
Jessica Yuen authored
This commit will: 1. Add an interface `SetComponentParams` to metadata.Manager that takes a list of parameters and sets those fields for the given component. 2. Add the jsonnet snippet manipulation logic that does the 'setting'. Parameters are set by: a. Keeping track of the parameters that are to be modified / added -- this defaults to the parameters provided to us. b. Discovering the current parameters in the existing snippet. c. Adding any parameters from (b) that is not in (a). d. Swapping out the old parameters with (c) in the snippet based on the location text span, and returning the new snippet.
-
Jessica Yuen authored
This commit will append both mandatory and optional prototype parameters to the component params.libsonnet file on `ks gen foo ...`. Default values will be used for optional params where the user does not specify flags to `ks gen foo ...`. Because we are trying to append to jsonnet, we will have to traverse the AST to first identify the location of where to insert the new component params. New components will be inserted at the bottom of the components object, with the params ordered alphabetically.
-
Jessica Yuen authored
We are currently parsing system prototypes using the default TextMate snippet which does not take into account the translation of params of format `import 'param://foo`. The jsonnet snippet parser does take this into account.
-
param://...Jessica Yuen authored
Rewrite system prototype params from `${foo}` format to `import 'param://foo'` so that they can be parsed correctly by the jsonnet snippet.
-
- Oct 31, 2017
-
-
Jessica Yuen authored
This commit will cause the jsonnet snippet parser to parse input of the form `import 'param://foo` to `params.foo` as opposed to the previous `${foo}`. ${foo} does not provide an easily accessible way to the params that are exposed through the params.libsonnet file. Since parameters are being exposed using a local 'params' variable, it makes sense for the jsonnet snippet to parse `import param://foo as `params.foo` instead.
-
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 expansion.
-
Jessica Yuen authored
This commit will generate the `environments/<env>/params.libsonnet` file on `env add <env>`. The purpose of this file is to allow users to define custom parameters on an environment-to-environment basis. It is meant to allow for "overrides" to component params.
-
Jessica Yuen authored
The purpose of this file is to allow re-parameterization of components after they are created. `components/params.libsonnet` is generated on `ks init`. This file will contain a jsonnet obj containing two objs: 1. global: contains user-defined global parameters; accessible to all component and environments. 2. components: contains component-level parameters, defined initially from `ks prototype use ...` These objs are empty by default.
-
- Oct 26, 2017
-
-
Jessica Yuen authored
No need to redefine these flags as they are already specified in the clientgo flag bindings.
-
Jessica Yuen authored
'server' is consistent with what is used by clientgo. 'uri' only introduces new language to ksonnet with the same meaning.
-
Alex Clemmer authored
Support `diff`ing between two environments
-
Alex Clemmer authored
Transition to pure Go implementation of Jsonnet
-
Alex Clemmer authored
-
Alex Clemmer authored
-
Jessica Yuen authored
This change enables the user to diff between two environments that are either local or remote. i.e., `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.
-
Alex Clemmer authored
Set env namespace to default when namespace not provided
-
Alex Clemmer authored
-
- Oct 25, 2017
-
-
Jessica Yuen authored
For now, client-go bindings will be removed from the diff command. Doing this because when diffing between multiple remote environments, it becomes ambiguous which environment cluster the flags should belong to.
-
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.
-
Alex Clemmer authored
Init env metadata from provided context
-
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 `context`.
-
Alex Clemmer authored
[docs] update readme
-
Jessica Yao authored
Signed-off-by:
Jessica Yao <jessica@heptio.com>
-
- Oct 23, 2017
-
-
Alex Clemmer authored
Remove link to releases page
-
- Oct 20, 2017
-
-
Jessica Yuen authored
ksonnet.next isn't released yet. This message remained as a port from the original README file in the kubecfg project.
-
- Oct 19, 2017
-
-
Jessica Yuen authored
-
- Oct 17, 2017
-
-
Alex Clemmer authored
Rename binary to 'ks'; rename 'kubecfg' references to 'ksonnet'
-
Jessica Yuen authored
-
Jessica Yuen authored
-
Jess authored
Introduce namespace to environments
-
Jessica Yuen authored
Environments currently have the concept of a server URI, but it is ambiguous which cluster namespace to use. This commit will introduce the concept of namespaces to the env commands. For example, `kubecfg env add staging http://mock-staging-uri \ --namespace=staging-namespace` `kubecfg env set staging --namespace=staging-namespace` The default environment will use the namespace of the default context. This commit will also update commands that take the <env> arg such as `apply` to make use of the env namespace, if specified.
-
Alex Clemmer authored
Environment base.libsonnet and overrides
-
- Oct 06, 2017
-
-
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 environments/default/default.jsonnet`.
-
Jessica Yuen authored
-
Jessica Yuen authored
This commit will generate an "<env-name>.jsonnet" file when an environment is created. For example, the default environment would have the following tree structure: ├── environments │ ├── base.libsonnet │ └── default │ ├── .metadata │ │ ├── k.libsonnet │ │ ├── k8s.libsonnet │ │ └── swagger.json │ ├── default.jsonnet │ └── spec.json The goal of this file is to allow users to extend on base.libsonnet on a per-environment basis to allow for custom overrides, such as replica count.
-
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.
-