Signed-off-by: bryanl <bryanliles@gmail.com>

Functionality has been moved to more appropriate packages. Also add
actions for tasks that relied on metadata registry.

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

* relocate part related code to `pkg/registry`

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

* component list
* env describe
* env list
* env targets
* import
* ns create
* ns list
* param list
* param set

Signed-off-by: bryanl <bryanliles@gmail.com>

New component pipeline can handle jsonnet, yaml, and json components

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Fixes indentation and alignment issues in `ks param diff`.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

Fixes #311

There currently exists a discrepency between the param types expected
from:
1. The parts library and in generate / prototype use
2. ks param set

ks param set will set boolean types as jsonnet boolean types, however,
prototypes will set boolean types as strings (i.e. in quotes). This
change will make it such that ks param sets boolean types as strings.
The reason we're not setting booleans in both model is because that will
require a better dependency story around ksonnet/parts first.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

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
things.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

re: #292
Signed-off-by: bryanl <bryanliles@gmail.com>

This change will introduce a lib package that handles the reading,
writing, and serialization of the ksonnet-lib and the kubernete's open
API files.

Prior to this change, metadata was stored in an environment's .metadata
directory. This lead to redundant files where environments share the
same kubernetes API version.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

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
follows:

environments:
  dev:
    destinations:
    - namespace: foo
      server: example.com
    k8sVersion: "1.8.1"
    path: dev
    targets:
    - 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: Jessica Yuen <im.jessicayuen@gmail.com>

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Introduce `ks component rm <component>`. This functionality will:

1. Delete the component file from components/. This is determined by the
component file name. If there exists two files with the same name but
different file  extensions, we will error out.

2. Remove component references. This currently implies removing all
component referenes in the component/params.libsonnet file and the
environment-specific params.libsonnet files.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Currently users are unable to add their own registries through the CLI.
This limits them to a small subset of prototypes found in the default
incubator registry.

This commit will add the command `ks registry add`, that allows users to
add registries supporting the `github` protocol.

It will be of the form `ks registry add <registry-name> <registry-uri>
[--version]`. If a version is not specified, `latest` will be used.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

- 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

Foreground colors were causing conflicts with user's terminal colors.
i.e. Black text would show as invisible for users with a black terminal
background.

Historically, every time we've needed to write out something tabular,
we've hand-rolled an ad hoc padded row writer. Yes, in each case. Such
is #startuplife.

The third time we did this we wrote this with bugs, and so now we are
rewriting it in a general, tested function, and transitioning all places
where we call this to use this function.

When the user calls `ks init <whatever>`, we need to emit an `app.yaml`
for the new project. This commit will introduce such behavior.

Pretty prints differences between the component parameters of two
environments.

A component flag is accepted to diff against a single component. By
default, the diff is performed against all components.

Pretty prints component or environment parameters.

This command will display all parameters for the component specified. If
a component is not specified, parameters for all components will be
listed.

Furthermore, parameters can be listed on a per-environment basis.

Examples:

List all component parameters
  ks param list

List all parameters for the component "guestbook"
  ks param list guestbook

List all parameters for the environment "dev"
  ks param list --env=dev

List all parameters for the component "guestbook" in the environment
"dev"
  ks param list guestbook --env=dev`,

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'

'server' is consistent with what is used by clientgo. 'uri' only
introduces new language to ksonnet with the same meaning.

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.

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.

When we run `init`, currently we generate a simple environment called
'default' with no URI. A better idea is to generate the URI from the
current context of the active kubeconfig file, if it exists.