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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
