Almost agree :) I think we have to make a distinction between sandbox and a "lab" environment to deploy a *preview* of an API - it's not ready to go, may be I will expose it to only a selected set of customers to be part of a beta program for example. It's not a 1.0, it's 0.8 - The main difference between sandbox and a "labs" envt, is that the versions deployed in sandbox and prod are the same. That is, since the versions on sandbox and prod are the same, promoting does not make sense. However promoting from labs to Sandbox/Prod does make sense. Lab env has no SLA, may be even no access keys, changes often and may break, does not have a rigid lifecycle, etc.
a) Number of env must be configurable - Although internal name can be fixed (sandbox, prod, lab), needs to have a display name which can vary AND can be localized (in different languages) b) Maximum 3 envs (Labs, Sandbox, Prod). After that, I agree we are mixing managing the API lifecycle and Service lifecycle. c) No promotion from sandbox to prod - However I must be able to have only Sandbox available while production is getting ready d) Eventually, promotions from labs to sandbox/production. d) Labs env has different setup, fixed SLA (only silver), optional subscription, different forums attached, separate statistics if any. e) SLAs on sandbox and production are different f) statistics on sandbox are separated from production. In the config below, I don't understand why the API endpoint is inside the envt config. Isnt't this part of the API config as it is now ? Thanks, Isabelle. __________________________________________________ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 18, 2013, at 12:52 PM, Nuwan Dias <nuw...@wso2.com> 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. > > 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/</ServerURL> > <Username>admin</Username> > <Password>admin</Password> > > <APIEndpointURL>http://192.168.10.100:8280,https://192.168.10.100:8243</APIEndpointURL> > </Environment> > <Environment> > <Type>sandbox</Type> > <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> > </Environments> > > Thanks, > NuwanD. > > > On Thu, Jul 18, 2013 at 8:43 AM, Nuwan Dias <nuw...@wso2.com> wrote: > On Wed, Jul 17, 2013 at 5:56 PM, Samisa Abeysinghe <sam...@wso2.com> wrote: > > > > On Wed, Jul 17, 2013 at 5:30 PM, Nuwan Dias <nuw...@wso2.com> wrote: > On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe <sam...@wso2.com> 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 <nuw...@wso2.com> 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 : nuw...@wso2.com > Phone : +94 777 775 729 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > -- > Nuwan Dias > > Senior Software Engineer - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > > -- > Nuwan Dias > > Senior Software Engineer - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > > > -- > Nuwan Dias > > Senior Software Engineer - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
