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
