Make istioctl consistent for manager and mixer commands

[ayj]

istioctl's proxy rules are fully self-describing and only verbs are external to the configuration file. Mixer commands are not and require passing additional kind, scope, and subject as command line parameters. Unify this scheme between manager and mier for user-facing APIs so that istio <verb> -f <rule.yaml> is sufficient for all istio configuration.

$ istioctl [create|delete|replace] -f istio-configuration.yaml
$ istioctl get <type> <name>

... where proxy rule would remain the same,

$ cat route-rule.yaml
---
type: route-rule
name: reviews-default
spec:
  destination: reviews.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: v1

... and mixer rule would look something like the following,

$ cat mixer-rule.yaml
---
type: mixer-rule
name: denials
spec:
  scope: global
  subject: myservice.ns.svc.cluster.local
  revision: "2022"
  rules:
  - aspects:
    - kind: denials

Implementation

ServiceConfig exists as a top-level proto for fully self-described mixer rule but it is marked as deprecated. This should be un-deprecated (or equivalent added) and top-level proto message added to contains both mixer and proxy rules (via oneof, google.protobuf.Any, etc). istioctl would then parse YAML (or prototext) versions of this top-level proto and send to mixer/manager API server.

[ayj]

cc @mandarjog @rshriram

[ayj]

Client and server configuration code layout could also be reorganized under common config/ directory with subdirectories for client and server implementations.

[esnible]

Would you like some help with this? Either a "UI design" of what the CLI commands should be or an implementation?

[ayj]

I expect this to be largely dependent on the outcome of istio/api#94. In particular, we're trying to figure out what goes into the common meta header vs. resource specific body, e.g. are scope/subject encoded in resource name v.s. fields in spec. I'd like to target this work to start after ALPHA release to avoid code / UI churn.

[esnible]

Over on the Mixer issues, a user has requested a command to list subjects.
istio/old_mixer_repo#748

I'd like to see commands to list scopes and anything else that is exposed by the mixer REST API.

This work item is dependend on istio/api#94 which is a design item. How does the team collaborate on design items? Are there design meetings in addition to the standups?

[kyessenov]

There has been design discussions inside mixer team with a write-up regarding the future directions of the mixer and its config. It seems like the current config API is going to be largely deprecated but I don't know details.
@geeknoid @mandarjog

[kyessenov]

Issue moved to istio/galley #12 via ZenHub