[Apiman-user] [DKIM] Re: publish api to specific gateway

Eric Wittmann eric.wittmann at redhat.com
Tue Dec 18 08:44:20 EST 2018 

Awesome, thanks for taking the time to figure all that out, Jon.

-Eric


On Fri, Dec 14, 2018 at 4:35 AM Jon Huang <chttl582 at gmail.com> wrote:

> Dear Eric
>
> Yes, I think it's the root cause.
> and sure, I've posted the issue on GitHub.
> Thanks
>
> Eric Wittmann <eric.wittmann at redhat.com> 於 2018年12月14日 週五 上午4:30寫道：
>
>> Very interesting, thanks Jon.  So if I understand correctly, the problem
>> is that the Client has a contract for API1 (published to GW1) and a
>> contract for API2 (published to GW2).  And so when registering a client,
>> we're trying to send Contracts for APIs that don't exist on the GW.  So
>> yeah, filtering the list of Contracts during registration makes sense.  We
>> should file this as a bug in Apiman (on GitHub).  Would you be willing to
>> do that?
>>
>> https://github.com/apiman/apiman/issues
>>
>> -Eric
>>
>>
>> On Thu, Dec 13, 2018 at 1:54 AM Jon Huang <chttl582 at gmail.com> wrote:
>>
>>> Dear Eric
>>>
>>> I spent some time to track this issue.
>>> First I hit the status API (GATEWAY_API_URL/system/status) and got
>>> following response:
>>> {
>>>     "id": "apiman-gateway-api",
>>>     "name": "API Gateway REST API",
>>>     "description": "The API Gateway REST API is used by the API Manager
>>> to publish APIs and register clients.  You can use it directly if you wish,
>>> but if you are utilizing the API Manager then it's probably best to avoid
>>> invoking this API directly.",
>>>     "version": "1.5.2-SNAPSHOT",
>>>     "up": true
>>> }
>>> seems OK, then I hit the register client API (PUT  GATEWAY_API_URL
>>> /clients) to retrieve further information, which returned an
>>> ApiNotFoundException.
>>> After reviewing the payload, I found the register client API sent every
>>> contract info to the gateway endpoint. (ex: contract A & B to Gateway 2,
>>> refer to following diagram)
>>> {
>>> "organizationId": "ORG",
>>> "clientId": "CLIENT",
>>> "version": "1.0",
>>> "apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2",
>>> "contracts": [{
>>> "apiOrgId": "ORG",
>>> "apiId": "API1",
>>> "apiVersion": "1.0",
>>> "plan": "plan",
>>> "policies": []
>>> }, {
>>> "apiOrgId": "ORG",
>>> "apiId": "API2",
>>> "apiVersion": "1.0",
>>> "plan": "plan",
>>> "policies": []
>>> }
>>> ]
>>> }
>>>
>>> [image: image.png]
>>>
>>> So if there is an contract's which its API publishing to another gateway
>>> leads to 404 not found exception. (ex: contract A info sent to Gateway 2)
>>> Maybe filtering the register client API payload or preventing API
>>> manager UI from creating contract between APIs with different gateways can
>>> solve this issue. (or is there any other solution?)
>>> Thanks.
>>>
>>>
>>> Eric Wittmann <eric.wittmann at redhat.com> 於 2018年12月6日 週四 下午9:47寫道：
>>>
>>>> Your diagram looks exactly right.  I don't know why you are getting a
>>>> 404 error when trying to register the client.  My best guess is that your
>>>> Gateway 2 configuration is actually incorrect and that the "Test Gateway"
>>>> function is returning a false positive somehow.  Can you post the
>>>> configuration settings you are using for *BOTH* of your Gateways?  (I
>>>> assume you can successfully publish an API to Gateway 1).
>>>>
>>>> You should be able to manually confirm your Gateway settings using e.g.
>>>> curl or postman.  There is an endpoint on the Gateway API that you can hit:
>>>>
>>>> GATEWAY_API_URL/system/status
>>>>
>>>> You'll need to provide auth info for this to work, but it will return a
>>>> JSON response like this:
>>>>
>>>> {
>>>>     "id": "xyz",
>>>>     "name": "Apiman Gateway API",
>>>>    "description": "... something here ...",
>>>>    "version": "x.y.z",
>>>>    "up": true
>>>> }
>>>>
>>>> The UI should be checking that endpoint when you click the "Test
>>>> Gateway" button, but perhaps there's a bug in that.
>>>>
>>>> If the above endpoint can be hit and verified, then I'm at a complete
>>>> loss as to why you'd be getting a 404 when trying to publish!  The
>>>> implication is that the Gateway API endpoint that the UI is attempting to
>>>> use is missing.  But if /system/status can be found, then everything else
>>>> should be available too!
>>>>
>>>> @Marc Savy <msavy at redhat.com> - any thoughts on this?
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On Thu, Dec 6, 2018 at 3:02 AM Jon Huang <chttl582 at gmail.com> wrote:
>>>>
>>>>> Dear Eric
>>>>>
>>>>> Thanks for your explanation.
>>>>> I tried to deploy another gateway with a new storage(Elasticsearch)
>>>>> and configure API to publish on the new one. (API manager version 1.5.1)
>>>>> However when I tried to create a contract between API and client apps
>>>>> then re-register client apps, error happened.
>>>>> It seems API manager fails to connect to gateway2. (But UI-> Manage
>>>>> Gateways -> Edit Gateway -> Test Gateway returns *Gateway
>>>>> Configuration Valid*)
>>>>> (io.apiman.manager.api.rest.contract.exceptions.ActionException:
>>>>> Failed to register client.)
>>>>> I put detail log in attachment if you are interested.
>>>>> Thanks
>>>>>
>>>>> simple diagram for my deployment test.
>>>>> [image: image.png]
>>>>>
>>>>>
>>>>> Volk, Florian <Florian.Volk at scheer-group.com> 於 2018年11月30日 週五
>>>>> 下午10:24寫道：
>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>>
>>>>>>
>>>>>> thanks for this detailed answer J
>>>>>>
>>>>>> This is quite interesting. We didn’t expected this behavior. Maybe it
>>>>>> would be good to place this in the documentation, maybe with this picture ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>> But this raises a few new questions for us. I try to explain:
>>>>>>
>>>>>>
>>>>>>
>>>>>> ·         Do we need for *alternate* setup two UIs if we don’t want
>>>>>> to use the REST interface or CLI-Tool?
>>>>>>
>>>>>> o   One for «Gateway Alpha» and one for «Gateway Beta»?
>>>>>>
>>>>>> o   Because I think you can only connect one elasticseach instance
>>>>>> with the UI. Am I right on this?
>>>>>>
>>>>>> o   What about the metrics in this use case à leads to two UIs?
>>>>>>
>>>>>>
>>>>>>
>>>>>> ·         For the «one logical gateway»
>>>>>>
>>>>>> o   If I understand you correctly this would mean that I also have
>>>>>> to configure only one gateway in my UI and can add X more without adding
>>>>>> them into the UI.
>>>>>> I just have to point them against the same elasticsearch instance.
>>>>>>
>>>>>> I also post this mail to the github issue, so we can stay within the
>>>>>> mailinglist.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> Florian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Von:* Eric Wittmann <eric.wittmann at redhat.com>
>>>>>> *Gesendet:* Friday, 30 November 2018 14:57
>>>>>> *An:* Volk, Florian <Florian.Volk at scheer-group.com>
>>>>>> *Cc:* chttl582 at gmail.com; Marc Savy <marc.savy at redhat.com>; Kihm,
>>>>>> Benjamin <Benjamin.Kihm at scheer-group.com>; Gebert, Alfred <
>>>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org
>>>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific
>>>>>> gateway
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure no problem.  The typical use-case for having multiple Gateway
>>>>>> nodes is to scale the gateway layer horizontally and then put a load
>>>>>> balancer in front of them.  So for example you might start up 5 apiman
>>>>>> gateway instances and configure them all to use the same Elasticsearch
>>>>>> instance for persistence (i.e. where to store configuration info like which
>>>>>> APIs have been published).  In this use-case, every gateway instance has
>>>>>> the same set of APIs "published" to it.  You can publish an API from the
>>>>>> UI/manager to **any** of the gateway instances and they will all know about
>>>>>> that API.  This is the "Single Logical Gateway" use-case -- the UI/manager
>>>>>> and all consumers don't know or care how many gateway nodes there are -
>>>>>> there could be 1 node, or there could be 100.  It behaves the same
>>>>>> logically.
>>>>>>
>>>>>>
>>>>>>
>>>>>> An **alternate** use case for having multiple gateways is when you
>>>>>> actually want different APIs to be deployed to different gateways.  So
>>>>>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A,
>>>>>> B, and C.  Then you have Gateway Beta which you want to proxy traffic to
>>>>>> APIs C, D, and E.  In that case, consumer traffic MUST be routed through
>>>>>> Gateway Alpha in order to access APIs A and B.  Consumer traffic MUST be
>>>>>> routed through Gateway Beta to access APIs D and E.  Finally, consumer
>>>>>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order
>>>>>> to access API C.  Think of this as the "Two Logical Gateways" use-case.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In order to achieve the "Two Logical Gateways" use-case, you will
>>>>>> need **two** separate persistence stores (Elasticsearch instances).  Then
>>>>>> you configure Gateway Alpha to use persistence store #1 and configure
>>>>>> Gateway Beta to use persistence store #2.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that you can have multiple gateway nodes for EACH of the two
>>>>>> logical gateways.  So for example you could have 5 gateway instances all
>>>>>> pointing to persistence store #1 - these 5 nodes would make up a single
>>>>>> logical gateway called "Gateway Alpha".  Then you could have 10 gateway
>>>>>> instances all pointing to persistence store #2 - and these would be a
>>>>>> single logical gateway called "Gateway Beta".
>>>>>>
>>>>>>
>>>>>>
>>>>>> Here is a diagram of what the architecture might look like:
>>>>>>
>>>>>>
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian <
>>>>>> Florian.Volk at scheer-group.com> wrote:
>>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>>
>>>>>>
>>>>>> now I’m confused. We use Elasticsearch as backend. If I understand
>>>>>> you correctly it would mean that we have to setup an Elasticsearch instance
>>>>>> for each gateway?
>>>>>>
>>>>>> On the other point, if the gateways operate as logical unit, why is
>>>>>> there a configuration option in the ui?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you explain this a little bit more detailed? Maybe you have a
>>>>>> configuration example.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Florian
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Von:* Eric Wittmann <eric.wittmann at redhat.com>
>>>>>> *Gesendet:* Friday, 30 November 2018 14:22
>>>>>> *An:* Volk, Florian <Florian.Volk at scheer-group.com>
>>>>>> *Cc:* chttl582 at gmail.com; Marc Savy <marc.savy at redhat.com>; Kihm,
>>>>>> Benjamin <Benjamin.Kihm at scheer-group.com>; Gebert, Alfred <
>>>>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org
>>>>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific
>>>>>> gateway
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are both gateways using the same persistent storage?  Each gateway
>>>>>> would need separate, independent persistence otherwise they will behave as
>>>>>> a single "logical" gateway.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian <
>>>>>> Florian.Volk at scheer-group.com> wrote:
>>>>>>
>>>>>> Hello together,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was interested in this and made a short test in my loacal
>>>>>> environment and I am able to reproduce this.
>>>>>>
>>>>>> I created a ticket on github for this (
>>>>>> https://github.com/apiman/apiman/issues/711). We may can fix this
>>>>>> shortly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Florian
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Von:* apiman-user-bounces at lists.jboss.org <
>>>>>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang
>>>>>> *Gesendet:* Friday, 30 November 2018 03:28
>>>>>> *An:* marc.savy at redhat.com
>>>>>> *Cc:* apiman-user at lists.jboss.org
>>>>>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear Marc
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes I untick another gateway however request towards both gateways
>>>>>> still works.
>>>>>>
>>>>>> Besides I tried to publish API via admin REST API (post api version
>>>>>> then put gateway info), both gateways forwards request too.
>>>>>>
>>>>>> Before filing a bug is there any apigw setting I shall check? (such
>>>>>> as parameter in apiman.properties or etc...)
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Marc Savy <marc.savy at redhat.com> 於 2018年11月21日 週三 下午9:35寫道：
>>>>>>
>>>>>> Apologies for the terribly slow reply. We've had so much spam I've
>>>>>> missed legitimate emails like this.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Did you explicitly untick the other gateway? Was this via the UI or
>>>>>> the API?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Did you resolve this issue? If not, please file a bug:
>>>>>> https://github.com/apiman/apiman/issues
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 4 Oct 2018 at 05:00, Jon Huang <chttl582 at gmail.com> wrote:
>>>>>>
>>>>>> Dears
>>>>>>
>>>>>>
>>>>>>
>>>>>> I had set up 2 gateways.
>>>>>>
>>>>>> When I new an API, I have to choose which gateway to publish. (select
>>>>>> list at Gateway section in the implementation tab).
>>>>>>
>>>>>> However after creating a client app and contract for test, I found
>>>>>> request via another gateway still works.
>>>>>>
>>>>>> (I guest when publishing to gateway 1 and request via gateway 2 shall
>>>>>> fail)
>>>>>>
>>>>>> Am I misunderstanding or I miss some settings to make it work?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181218/0c5384e6/attachment-0001.html

More information about the Apiman-user mailing list