On Thu, Jul 18, 2013 at 4:22 PM, Nuwan Dias <[email protected]> wrote: > We (Sumedha, Srinath, Azeez, Sanjiva and a few from the APIM-Team) had a > meeting to discuss on $subject and we came to a conclusion to maintain > production and sandbox environments only. The reason is that since we're > talking about APIs and not about the actual implementation of it, it does > not make much sense to have an API deployed on multiple environments. An > API could either be in production or in sandbox. Whatever that is not > production is considered to be sandbox. >
Well, I think that is too limiting. What is I want to have two "sandbox" like environments in my system? How can that be handled? > The concept of promoting from sandbox to production was also invalidated. > If a given API has both production and sandbox endpoints, it will be > deployed onto both environments at the time of publishing. If it has only > one it will only be deployed onto the relevant environment. If the other > endpoint is added later, it will be deployed onto that environment at that > point. > > After the conclusions of the discussions, the environment configuration > would be similar to the following. > > <Environments> > <Environment> > <Type>production</Type> > > <ServerURL>https://192.168.10.100:9443/services/<https://192.168.10.101:9443/services/> > </ServerURL> > <Username>admin</Username> > <Password>admin</Password> > > <APIEndpointURL>http://192.168.10.100:8280<http://192.168.10.101:8280/> > ,https://192.168.10.100:8243 <https://192.168.10.101:8243/> > </APIEndpointURL> > </Environment> > <Environment> > <Type>sandbox</Type> > > <ServerURL>https://192.168.20.100:9443/services/<https://192.168.10.101:9443/services/> > </ServerURL> > <Username>admin</Username> > <Password>admin</Password> > > <APIEndpointURL>http://192.168.20.100:8280<http://192.168.10.101:8280/> > ,https://192.168.20.100:8243 <https://192.168.10.101:8243/> > </APIEndpointURL> > </Environment> > </Environments> > > Thanks, > NuwanD. > > > On Thu, Jul 18, 2013 at 8:43 AM, Nuwan Dias <[email protected]> wrote: > >> On Wed, Jul 17, 2013 at 5:56 PM, Samisa Abeysinghe <[email protected]>wrote: >> >>> >>> >>> >>> On Wed, Jul 17, 2013 at 5:30 PM, Nuwan Dias <[email protected]> wrote: >>> >>>> 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? >>>>> >>>> >>>> Yes, this can be facilitated. >>>> >>> >>> Where would that config go? Also, ideally, want to be able to use my own >>> names in my setup rather than sandbox/prod say staging/live >>> >> >> Yes, that's the idea. These names will be displayed on the Store when >> listing the environments. The config would reside in the api-manager.xml. >> Although you can have multiple environments those will have to be >> categorized into two main types (production and sandbox) since we only >> support two key-types. I haven't thoroughly thought about the xml config >> but I'm guessing it would be similar to the following. >> >> <Environments> >> *<environment>* >> * <name>Live</name>* >> * <type>production</type>* >> * <deployByDefault>false</deployByDefault>* >> * <ServerURL>https://192.168.10.100:9443/services/</ServerURL>* >> * <Username>admin</Username>* >> * <Password>admin</Password>* >> * <APIEndpointURL>http://192.168.10.100:8280, >> https://192.168.10.100:8243</APIEndpointURL>* >> * </environment>* >> <environment> >> <name>Staging</name> >> <type>production</type> >> <deployByDefault>false</deployByDefault> >> <ServerURL>https://192.168.10.101:9443/services/</ServerURL> >> <Username>admin</Username> >> <Password>admin</Password> >> <APIEndpointURL>http://192.168.10.101:8280, >> https://192.168.10.101:8243</APIEndpointURL> >> </environment> >> <environment> >> <name>QA</name> >> <type>sandbox</type> >> <deployByDefault>true</deployByDefault> >> <ServerURL>https://192.168.20.100:9443/services/</ServerURL> >> <Username>admin</Username> >> <Password>admin</Password> >> <APIEndpointURL>http://192.168.20.100:8280, >> https://192.168.20.100:8243</APIEndpointURL> >> </environment> >> <environment> >> <name>Development</name> >> <type>sandbox</type> >> <deployByDefault>true</deployByDefault> >> <ServerURL>https://192.168.20.101:9443/services/</ServerURL> >> <Username>admin</Username> >> <Password>admin</Password> >> <APIEndpointURL>http://192.168.20.101:8280, >> https://192.168.20.101:8243</APIEndpointURL> >> </environment> >> </Environments> >> >> The 'type' attribute specifies the environment type whereas the >> 'deployByDefault' attribute specifies whether an API should be deployed >> onto that environment by default when an API is published. If >> 'deployByDefault' is false, the API will have to be promoted onto that >> environment from another. >> >> Thanks, >> NuwanD. >> >>> >>>> Another requirement which I missed to mention earlier is that we need >>>> to have a control of the environments in which a given API will reside. For >>>> example when an API is published, we need to say that it will initially be >>>> deployed on the Sandbox Gateway only. Once the user is satisfied with it he >>>> can promote it to Staging, Production, etc. >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >> >> >> -- >> Nuwan Dias >> >> Senior Software Engineer - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> > > > > -- > 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
