On Wed, Jul 17, 2013 at 5:34 PM, Sumedha Rubasinghe <[email protected]>wrote:
> I feel this functionality will be required in many other places. Thus > should be designed in a generalized manner. > +1 > > The most obvious place I can think of right now is, AppFactory deploying > applications into different environments. > AF is the most obvious one where we have this used already. > Same can be applicable for Carbon Apps as well. > > The generalized design should support: > 1. N number of environments > 2. Ability to mark default deployment environments > 3. @ the point of publishing an API, a list of deployment environments > will appear for selection > > Same pattern be extended in the APaaS world, where a given API can be > published into multiple stores. > We also need to critically analyze the model followed by deployment > synchronizer as it is solving some what similar problem. > > > > On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe <[email protected]>wrote: > >> Is the design such that, if we want more than 2 environments, that can be >> facilitated? >> >> >> On Wed, Jul 17, 2013 at 3:02 PM, Nuwan Dias <[email protected]> wrote: >> >>> Hi, >>> >>> This is regarding supporting multiple environments (production/sandbox) >>> for the API Gateway. Currently API Manager allows having two endpoints per >>> API. These are the production and sandbox endpoints. Although the sandbox >>> endpoint is supposed to be used for testing purposes, both production and >>> sandbox traffic is handled through a single Gateway. This can cause the >>> production Gateway be loaded with test traffic as well. >>> >>> This feature is to allow having two Gateway nodes (at least) for serving >>> production and sandbox traffic separately. Following is how it is supposed >>> to work. >>> >>> 1. When an API is published, it will be deployed on both the production >>> and sandbox Gateway nodes. >>> 2. The production Gateway will only serve production traffic and the >>> sandbox Gateway will only serve sandbox traffic. >>> 3. The Gateway will use the token type (production or sandbox) to >>> identify requests being received. >>> 4. The Token endpoint (/token) will remain same on both nodes. The token >>> being generated will depend on the type of consumer-key/consumer-secret >>> used. >>> 5. Both Gateway nodes will share a single APIMGT database. This is where >>> information related to APIs, Applications, Token, etc are stored. This will >>> be the same database as used by the publisher/store nodes. >>> >>> Currently an xml template is used for generating an API configuration >>> (synapse configuration). To allow the above mentioned feature to work, a >>> separate xml template will have to be maintained for each endpoint type >>> (production template and sandbox template). >>> >>> The api-manger.xml currently defines the location (url) of the Gateway. >>> A similar configuration will be introduced to define the location of the >>> sandbox Gateway. The API Store will display both endpoints accordingly. >>> >>> Thoughts/Suggestions welcome. >>> >>> Thanks, >>> NuwanD. >>> >>> -- >>> Nuwan Dias >>> >>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > /sumedha > b : bit.ly/sumedha > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
