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
