Re: [Architecture] How can we improve our profiles story?

2016-10-10 Thread Afkham Azeez
Yes we should have separate deployment.properties files and not duplicate the config files. On Tue, Oct 11, 2016 at 10:31 AM, Muhammed Shariq wrote: > The issue with packing all configs file according to a particular profile > is that we'll end up packing many duplicate files,

Re: [Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Lakmal Warusawithana
Basically this has 3 parts. 1. Enable network load balancer to dynamically create containers based on first request 2. Terminate containers if idle. 3. Improve startup time by having pool of running containers and dynamically allocate to tenants ( this is what Sanjeewa mention)

Re: [Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Lakmal Warusawithana
On Tue, Oct 11, 2016 at 10:22 AM, Lakmal Warusawithana wrote: > > On Tue, Oct 11, 2016 at 10:06 AM, Manjula Rathnayake > wrote: > >> Hi Sanjeewa, >> >> Are you suggesting an API manager deployment pattern using containers? >> Container per tenant and per

Re: [Architecture] How can we improve our profiles story?

2016-10-10 Thread Muhammed Shariq
The issue with packing all configs file according to a particular profile is that we'll end up packing many duplicate files, which might not be optimal. One way to get around this problem would be to use the ConfigResolver - deployment.properties file introduced in C5 to override only the required

Re: [Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Lakmal Warusawithana
On Tue, Oct 11, 2016 at 10:06 AM, Manjula Rathnayake wrote: > Hi Sanjeewa, > > Are you suggesting an API manager deployment pattern using containers? > Container per tenant and per gateway, key manager etc? > Yes. With C5 APIM we will have per tenant gateway, store,

Re: [Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Manjula Rathnayake
Hi Sanjeewa, Are you suggesting an API manager deployment pattern using containers? Container per tenant and per gateway, key manager etc? thank you. On Mon, Oct 10, 2016 at 9:06 PM, Malaka Silva wrote: > Hi Sanjeewa, > > My understanding is gateway pool is not tenant

Re: [Architecture] Feature requirements on IS to be the sole Key Manager of API Manager

2016-10-10 Thread Abimaran Kugathasan
Hi Nuwan, I have some clarifications on this. On Mon, Oct 10, 2016 at 6:18 PM, Nuwan Dias wrote: > Hi, > > With the current efforts on moving to C5 based architecture, API Manager > plans to rely on standalone IS (without installing features) so that it can > operate as the

Re: [Architecture] Feature requirements on IS to be the sole Key Manager of API Manager

2016-10-10 Thread Johann Nallathamby
+1. It is important we support this in next major IS release from day 1. In fact most of these APIs are part of UMA standard. Farasath did UMA backend implementation as a GSoC project. You can find more details on the implementation at [1]. [1] [GSoC] User-Managed Access (UMA) Profile for OAuth2

Re: [Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Malaka Silva
Hi Sanjeewa, My understanding is gateway pool is not tenant specific and will not be returned but rather terminated? On Mon, Oct 10, 2016 at 8:01 PM, Sanjeewa Malalgoda wrote: > Hi All, > Starting this mail thread to continue discussion on "speedup instance > activate time

[Architecture] Speedup traffic serving process in scalable/ containerized deployment

2016-10-10 Thread Sanjeewa Malalgoda
Hi All, Starting this mail thread to continue discussion on "speedup instance activate time when we move ahead with container based deployments". As of now all of us are working on speedup server start time and deploy instances on demand with the help of load balancer. Please note that this is not

[Architecture] Feature requirements on IS to be the sole Key Manager of API Manager

2016-10-10 Thread Nuwan Dias
Hi, With the current efforts on moving to C5 based architecture, API Manager plans to rely on standalone IS (without installing features) so that it can operate as the Key Manager for the API Gateway. In order to achieve this, there are a few feature gaps in IS we have identified earlier that

Re: [Architecture] [APIM] Life cycle Management

2016-10-10 Thread Prasanna Dangalla
Hi Rajith, On Mon, Oct 10, 2016 at 3:30 PM, Rajith Roshan wrote: > Hi, >> > please find the images below > >> On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan wrote: >> >>> Hi all, >>> >>> Life cycle is an integral part in any product. Each SOA governance

Re: [Architecture] [APIM] Life cycle Management

2016-10-10 Thread Rajith Roshan
> > Hi, > please find the images below > On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan wrote: > >> Hi all, >> >> Life cycle is an integral part in any product. Each SOA governance >> related artifacts can have their own life cycle. Capabilities provided in >> order to

[Architecture] [APIM] Life cycle Management

2016-10-10 Thread Rajith Roshan
Hi all, Life cycle is an integral part in any product. Each SOA governance related artifacts can have their own life cycle. Capabilities provided in order to manage life cycles not only allow you to properly organize your assets but also provides many extensibilities (For ex through custom

Re: [Architecture] How can we improve our profiles story?

2016-10-10 Thread Kishanthan Thangarajah
I like the idea of providing a descriptor about a profile (describes what artifacts that should be included) and use a tool or a script to create the profile specific runtime pack. But we also need to consider what Sameera mentioned. I see the issue can come only with configuration repo because,