coreos / kpm Goto Github PK

proposal :

shardcount: 5
shards:
   - name: {{i}}

another one would e to transform shards into a hash:, and name shard list

resources:
  - name: etcd
    file: etcd-rc.yaml
    sharded: [new, existing]

shards:
  new:  
     count: 0..3
     nodes: 
         -  name: node{i} 
  existing:
     count: 3..5
         - name: node{i}

The type is inside the manifest already

This project looks great! I really appreciate the new approach.

One thing that I ask is that we not repeat the same mistake that the docker hub made making a default namespace that seems to be rooted in a single namespace: hub.kubespray.io.

The approach we are taking with the OCI Image format, that was taken with the appc format, and in the Go language is to use a DNS federated namespace that can be delegated. It is too early to say exactly how the OCI delegation will work but you can read about the appc delegation here: https://github.com/appc/spec/blob/master/spec/discovery.md

Happy to discuss further, I think this is really important work y'all are doing.

This looks really interesting! I would be interested in testing it out, but I would like to do so with my own private hub / registry. Is the source for the registry / hub available at all? I can't see any instructions for running your own.

Thanks!

See how it could be extended to every calls

Currently exceptions are not rescue.

As a user I don't want to see a backtrace for an 'expected' error:

i.e logging failed or unauthorized access should print a 'nice' message to the user

Propose a platform or a method to automaticaly deploy packages on a cluster to validate them.

A quick td;lr to switch from helm to kpm

command separated a=b or multiple -x

• kpm deploy --variables a=b,c=d
• kpm deploy -x a=b -x c=d

or json data

• kpm deploy --variables '{"a": "b", "c": "d"}'

i.e:

variables:
  name:  foo

deploy:
  - name: titi/lala
    variables:
        user:  {{$self.name}}

steps:

• pip install kpm
• kpm --help
• kpm list
• kpm login
• kpm new myghost/ghost
• cp ghost resources
• template values
• edit manifest
• kpm push
• kpm deploy myghost/ghost
• deploy a private registry
• kpm deploy kubespray/kpm-registry
• kpm list -H http://private-registry
• kpm new myprivate/ghost
• cp ingress/tls/secrets
• edit manifest
• kpm push -H http://private-registry
• kpm deploy myprivate/ghost -H http://private-registry

At somepoint the kpm-cli may not be compatible with a version of the API.
In such case users should be asked to perform an upgrade and eventually reject all commands to force the upgrade.

This can be done by verifiing a header ?

Package would have different status at least:

• dev
• released

1. A package in dev is restricted to collaborators/users with read permission, it is not available to other users. A package in dev mode can be force push
2. Once a package is released it can't be force-push and it's available to all users

Check the current logged account

commands proposal:
kpm login --whoami
or
kpm login --info
kpm whoami

From the log

HTTPError: 404 Client Error: NOT FOUND for url: http://localhost:5000/api/v1/packages/devoxx/mysql/pull

but the client receive a 500

currently output is by default a human readable.
Add an option to format the ouput:

kpm deploy package-name --output json

3 permissions level:

• owner
• collaborator (r/w)
• user (r)

Add command to manage permissions:
proposal:

• set permissions

$ kpm set-perms --user targetuser --as collaborator package-name
-> Added targetuser as collbarator to package-name

• check permissions

$ kpm perms package-name`
user           perm
--------       -----------
ant31          owner
smana          collaborator
abodelot       user

false is transformed to 0

from Manifest()
to
Manifest(path="directory")

Package should failed early.

Currently a package can be submitted but may fail later (i.e bad variable resolution)

• Validate a package on create/update
• Fail with an explicit error message to help the packager to fix the package.

by default kpm list display latest stable verions

add an options to list latest 'pre-release' versions (semver):

$ kpm list --pre
app                               version      downloads
--------------------------------  ---------  -----------
kube-system/kube-ui               0.5.0-RC.4              38
logstash/logstash                 2.2.0-beta.1               31

see: https://github.com/kubespray/kpm-registry/issues/2

Filters have introduced crypto and more dep.

Should we have a separate repo for those filters ?

pip install kpm
pip install kpm-filters

Currently kpm replace the resource (delete/create).
Performing a PATCH seems a better default.

To keep the previous behavior (replace) available add a key in the manifest:

resources:
  - name: kube-ui-rc.yaml
    type: rc
    strategy: replace  

- name: resource.yaml
  type: deployment
  strategy: update   # Default  behavior

• k8s-elasticsearch/
• k8s-etcd/
• k8s-fabric8/
• k8s-heapster/
• k8s-influxdb/
• k8s-kubedash/
• k8s-kubedns/
• k8s-kube-logstash/
• k8s-kube-ui/
• k8s-memcached/
• k8s-pgbouncer/
• k8s-postgres/
• k8s-rabbitmq/
• k8s-redis/
• k8s-kibana
• k8s-rabbitmq
• k8s-kube-logstash

proposal:

tasks:
  - name: deploy app
    kpm: package=ant31/ghost namespace=titi state=present

On a fresh new registry:

 curl http://195.154.150.206:30958/api/v1/packages                                                                                    1 21:17:34
{
  "error": {
    "code": "package-not-found", 
    "details": {
      "package": "/kpm"
    }, 
    "message": "Package not found: /kpm"
  }
}%  

A user may want to keep a package private and share it only with a list of users ( #19 )

command:
kpm config --privacy private package-name

question: private by default?

• b64enc
• b64dec
• file_lookup # read file
• find_files # list files in directory
• rand
• default

This will break previous package: prepare a reupload or migration of current packages.

It would be nice to be able to use a file to define multiple applications and the associated command to use it.
Something similar to pip requirements files.

Discussion around that point for ac-discovery :
appc/spec#160

RFC: https://tools.ietf.org/html/rfc5785

• Package should be stored in some cache after being fetch.
• kpm-backend can act as a registry mirror server side and take offline package by default
• kpm-cli should allow to deploy from a package tarball: `kpm deploy --file package.tar

Inside the tarball there is a package.json that is the same received from API.

Display current:
kpm version
kpm-api version

kpm versions