Hi, On Thu, Jul 18, 2013 at 6:43 PM, Samisa Abeysinghe <[email protected]> wrote:
> > > > 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? > I might be stating the obvious, but IMO, the implementation of the construct "Environment" should be done in a more generic manner without limiting ourselves to just two environments. It should be a deployment decision to use two or more "Environment"s and the names production/sandbox would just be labels to uniquely identify the managed environments. > > >> 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 > > Regards, Prabath -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: [email protected] <[email protected]> Mobile: +94774171471 <http://harshana05.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
