From marc.savy at redhat.com  Fri Jul  7 09:29:10 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 7 Jul 2017 14:29:10 +0100
Subject: [Apiman-user] Enhancing apiman-cli to make headless gateway configs
	easier to use.
Message-ID: <CAA7j38+BPNU8Dr4YH8b43uLqx6CRzhMYDFEgUUx_Ai1L2mCtmQ@mail.gmail.com>

We've had some people using the Apiman Gateway headless for a while
now, either with the new immutable registry that loads from JSON[1],
or simply using any existing registry via the gateway API instead of
using a manager.

The main issue people encounter is that policy configuration contains
two fields that are difficult to work out and clumsy to encode
properly[1]:

- `policyImpl` requires the plugin's URI, including the path to its
main class. You can work these out by looking at the plugin's source
code, but that's rather circuitous and it would be nicer to just
provide the plugin's GAV (like in the manager) and for it to be
resolved.

- `policyJsonConfig`[3] needs to be escaped properly (and must valid
according to its schema).

Neither of these aspects are especially user-friendly. My proposal is
to extend apiman-cli's functionality to allow the Apiman Gateway to be
configured directly via a YAML/JSON file (i.e. declaratively).

We can therefore provide a more user-friendly interface that automates
the resolution of plugins; validations and escapes the policy config;
etc.

A final step would be to bundle the apiman-cli tool with our distros
to make it easier to access.

Any thoughts?

Regards,
Marc

[1] https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_elasticsearch
[2]  Of course, this interface was never truly designed to be used by
humans, so that's understandable
[3] Unfortunately named as it can be any arbitrary string, the policy
just needs to be able to decode it. For example, it could be XML.

From marc.savy at redhat.com  Tue Jul 18 18:34:48 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 18 Jul 2017 23:34:48 +0100
Subject: [Apiman-user] Enhancing apiman-cli to make headless gateway
	configs easier to use.
In-Reply-To: <CAA7j38+BPNU8Dr4YH8b43uLqx6CRzhMYDFEgUUx_Ai1L2mCtmQ@mail.gmail.com>
References: <CAA7j38+BPNU8Dr4YH8b43uLqx6CRzhMYDFEgUUx_Ai1L2mCtmQ@mail.gmail.com>
Message-ID: <CAA7j38KCtFCS++Sqo=RvWgynbkNX-X17vUwodD5tfm35c1OU+w@mail.gmail.com>

Here's a preview of my proposed data format -- it reuses the format
and model developed by Pete Cornish and his team; big kudos to them!
[1].

I'm soliciting suggestions and comments, feel free to reply here (or
reach out privately if that's not possible).

Example:

apiman-cli gateway apply -f /Users/msavy/tmp/sample.yaml

```
# sample.yaml
---
  system:
    gateways:
      - name: "test-gw"
        type: "REST"
        config:
          endpoint: "http://localhost:8080/apiman-gateway-api"
          username: "apimanager"
          password: "apiman123!"
    plugins:
      - name: TestPolicyFriendlyName // (1)
        groupId: "io.apiman.plugins"
        artifactId: "apiman-plugins-test-policy"
        version: "1.3.1.Final"
  org:
    name: "test"
    apis:
      - name: "example"
        version: "1.0"
        config:
          endpoint: "http://localhost:8080/services/echo"
          endpointType: "rest"
          public: true
          gateway: "test-gw"
        policies:
          - name: "CachingPolicy" // (2)
            config:
              ttl: 60
          - plugin: TestPolicyFriendlyName // (3)
            config:
              foo: 123
```
(1) Friendly name for plugin instead of having to refer to it by full GAV
(2) In-built policy will be looked up to ensure it exists and resolves
the correct FQCN.
(3) Add a policy by plugin friendly name (else GAV)

One rare edge case when multiple policies are defined in a single
plugin. In that situation we allow disambiguation by providing the
plugin's `id` in the `name`/`id` field:

```
<SNIP>
        policies:
          - name: PolicyOne
            plugin: PluginWithMultiplePolicies
            config:
              foo: 123
```

Thoughts? Feedback?

Still a bit of work to do before it's PR-ready but making some progress.

Regards,
Marc

[1] With one tiny addition.

On 7 July 2017 at 14:29, Marc Savy <marc.savy at redhat.com> wrote:
> We've had some people using the Apiman Gateway headless for a while
> now, either with the new immutable registry that loads from JSON[1],
> or simply using any existing registry via the gateway API instead of
> using a manager.
>
> The main issue people encounter is that policy configuration contains
> two fields that are difficult to work out and clumsy to encode
> properly[1]:
>
> - `policyImpl` requires the plugin's URI, including the path to its
> main class. You can work these out by looking at the plugin's source
> code, but that's rather circuitous and it would be nicer to just
> provide the plugin's GAV (like in the manager) and for it to be
> resolved.
>
> - `policyJsonConfig`[3] needs to be escaped properly (and must valid
> according to its schema).
>
> Neither of these aspects are especially user-friendly. My proposal is
> to extend apiman-cli's functionality to allow the Apiman Gateway to be
> configured directly via a YAML/JSON file (i.e. declaratively).
>
> We can therefore provide a more user-friendly interface that automates
> the resolution of plugins; validations and escapes the policy config;
> etc.
>
> A final step would be to bundle the apiman-cli tool with our distros
> to make it easier to access.
>
> Any thoughts?
>
> Regards,
> Marc
>
> [1] https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_elasticsearch
> [2]  Of course, this interface was never truly designed to be used by
> humans, so that's understandable
> [3] Unfortunately named as it can be any arbitrary string, the policy
> just needs to be able to decode it. For example, it could be XML.

From marc.savy at redhat.com  Tue Jul 25 12:11:13 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 25 Jul 2017 17:11:13 +0100
Subject: [Apiman-user] Enhancing apiman-cli to make headless gateway
	configs easier to use.
In-Reply-To: <CAA7j38KCtFCS++Sqo=RvWgynbkNX-X17vUwodD5tfm35c1OU+w@mail.gmail.com>
References: <CAA7j38+BPNU8Dr4YH8b43uLqx6CRzhMYDFEgUUx_Ai1L2mCtmQ@mail.gmail.com>
	<CAA7j38KCtFCS++Sqo=RvWgynbkNX-X17vUwodD5tfm35c1OU+w@mail.gmail.com>
Message-ID: <CAA7j38LSwVNftQE6q8YMr2Z=pzGnhifFD5X_J_37Fkh54pgHOQ@mail.gmail.com>

Here's the PR for those who want to track progress:

https://github.com/apiman/apiman-cli/pull/27

On 18 July 2017 at 23:34, Marc Savy <marc.savy at redhat.com> wrote:

> Here's a preview of my proposed data format -- it reuses the format
> and model developed by Pete Cornish and his team; big kudos to them!
> [1].
>
> I'm soliciting suggestions and comments, feel free to reply here (or
> reach out privately if that's not possible).
>
> Example:
>
> apiman-cli gateway apply -f /Users/msavy/tmp/sample.yaml
>
> ```
> # sample.yaml
> ---
>   system:
>     gateways:
>       - name: "test-gw"
>         type: "REST"
>         config:
>           endpoint: "http://localhost:8080/apiman-gateway-api"
>           username: "apimanager"
>           password: "apiman123!"
>     plugins:
>       - name: TestPolicyFriendlyName // (1)
>         groupId: "io.apiman.plugins"
>         artifactId: "apiman-plugins-test-policy"
>         version: "1.3.1.Final"
>   org:
>     name: "test"
>     apis:
>       - name: "example"
>         version: "1.0"
>         config:
>           endpoint: "http://localhost:8080/services/echo"
>           endpointType: "rest"
>           public: true
>           gateway: "test-gw"
>         policies:
>           - name: "CachingPolicy" // (2)
>             config:
>               ttl: 60
>           - plugin: TestPolicyFriendlyName // (3)
>             config:
>               foo: 123
> ```
> (1) Friendly name for plugin instead of having to refer to it by full GAV
> (2) In-built policy will be looked up to ensure it exists and resolves
> the correct FQCN.
> (3) Add a policy by plugin friendly name (else GAV)
>
> One rare edge case when multiple policies are defined in a single
> plugin. In that situation we allow disambiguation by providing the
> plugin's `id` in the `name`/`id` field:
>
> ```
> <SNIP>
>         policies:
>           - name: PolicyOne
>             plugin: PluginWithMultiplePolicies
>             config:
>               foo: 123
> ```
>
> Thoughts? Feedback?
>
> Still a bit of work to do before it's PR-ready but making some progress.
>
> Regards,
> Marc
>
> [1] With one tiny addition.
>
> On 7 July 2017 at 14:29, Marc Savy <marc.savy at redhat.com> wrote:
> > We've had some people using the Apiman Gateway headless for a while
> > now, either with the new immutable registry that loads from JSON[1],
> > or simply using any existing registry via the gateway API instead of
> > using a manager.
> >
> > The main issue people encounter is that policy configuration contains
> > two fields that are difficult to work out and clumsy to encode
> > properly[1]:
> >
> > - `policyImpl` requires the plugin's URI, including the path to its
> > main class. You can work these out by looking at the plugin's source
> > code, but that's rather circuitous and it would be nicer to just
> > provide the plugin's GAV (like in the manager) and for it to be
> > resolved.
> >
> > - `policyJsonConfig`[3] needs to be escaped properly (and must valid
> > according to its schema).
> >
> > Neither of these aspects are especially user-friendly. My proposal is
> > to extend apiman-cli's functionality to allow the Apiman Gateway to be
> > configured directly via a YAML/JSON file (i.e. declaratively).
> >
> > We can therefore provide a more user-friendly interface that automates
> > the resolution of plugins; validations and escapes the policy config;
> > etc.
> >
> > A final step would be to bundle the apiman-cli tool with our distros
> > to make it easier to access.
> >
> > Any thoughts?
> >
> > Regards,
> > Marc
> >
> > [1] https://apiman.gitbooks.io/apiman-installation-guide/
> installation-guide/vertx/download.html#_elasticsearch
> > [2]  Of course, this interface was never truly designed to be used by
> > humans, so that's understandable
> > [3] Unfortunately named as it can be any arbitrary string, the policy
> > just needs to be able to decode it. For example, it could be XML.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170725/96a8eebe/attachment.html 

From marc.savy at redhat.com  Thu Jul 27 06:14:09 2017
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 27 Jul 2017 11:14:09 +0100
Subject: [Apiman-user] JIRA problems (unable to log in)
Message-ID: <CAA7j38J7q9xZDcjuW66+-Aj1Bc5Ee-=_=DMOYar-Y=FKEhpP=Q@mail.gmail.com>

Hi All,

Community members have reported that they are unable to log into the
Apiman JIRA.
Unfortunately we had no idea up until now as our own accounts were
unaffected. We've contacted the relevant support folk and hopefully
the glitch will be resolved shortly.

Apologies for the inconvenience and just to reassure folk that work is
still very much progressing!

Regards,
Marc

From lchampagnac at vulog.com  Fri Jul 28 10:46:04 2017
From: lchampagnac at vulog.com (Laurent Champagnac)
Date: Fri, 28 Jul 2017 14:46:04 +0000
Subject: [Apiman-user] Champax / https://issues.jboss.org/browse/APIMAN-1201
Message-ID: <28bed94cae5d4b93b14c9a74d14d124e@S1984.EX1984.lan>

Hello,


as requested, initial email.


This is about https://issues.jboss.org/browse/APIMAN-1201?


Regards,

Champax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170728/7f1fd18a/attachment.html