Let me put this another way. Has anybody come across any system which provides a sandbox API & production API offer a third option?
On Fri, Jul 19, 2013 at 5:00 AM, Afkham Azeez <[email protected]> wrote: > YAGNI <http://en.wikipedia.org/wiki/You_aren't_gonna_need_it> > > We have done this several times in the past. An example that comes to my > mind is Axis2 service versioning. > > > On Fri, Jul 19, 2013 at 4:43 AM, Samisa Abeysinghe <[email protected]>wrote: > >> Well, if we have the ability to add another, in case someone want it, the >> system would not go brittle. >> >> At least leave room for such, by design. >> >> >> On Thu, Jul 18, 2013 at 9:00 PM, Afkham Azeez <[email protected]> wrote: >> >>> We were considering the concept of having generic environments, but >>> could not think of a non-hypothetical use case, where we would need >>> anything apart from sandbox & production. Both of these are in the >>> production stage. >>> >>> Azeez >>> >>> >>> On Thu, Jul 18, 2013 at 7:04 PM, Prabath Abeysekera >>> <[email protected]>wrote: >>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>** >>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * >>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>> * >>> * >>> *Lean . Enterprise . Middleware* >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>** > email: **[email protected]* <[email protected]>* cell: +94 77 3320919 > blog: **http://blog.afkham.org* <http://blog.afkham.org>* > twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * > linked-in: **http://lk.linkedin.com/in/afkhamazeez* > * > * > *Lean . Enterprise . Middleware* > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>** email: **[email protected]* <[email protected]>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
