Re: [Architecture] [VOTE] Release of WSO2 Identity Server 5.6.0 RC2

[Madawa Soysa]

Hi All,

We are closing the vote as we found an issue when loading the registry
browser. We will fix the issue and release another release candidate as
soon as possible.

Thanks,
Madawa

On Thu, Jun 14, 2018 at 10:45 AM Dewni Weeraman  wrote:

> Hi all,
>
> Sorry I made a small mistake. Please note that the above scenarios were
> tested on RC2 pack.
>
> Thanks,
> Dewni
>
> On Thu, Jun 14, 2018 at 10:40 AM, Dewni Weeraman  wrote:
>
>> Hi,
>>
>> Tested below scenarios on RC1 pack,
>>
>>- OAuth token revocation.
>>- Invoke the OAuth Introspection Endpoint.
>>- Entitlement policy creation using write policy in xml and
>>publishing.
>>- Using REST APIs via XACML to manage entitlement.
>>- Create, update, get, delete an OAuth app using Dynamic Client
>>Registration endpoint.
>>
>>
>> No blocking issues found.
>>
>> [+] Stable - Go ahead and release
>>
>> Thanks,
>> Dewni
>>
>> On Wed, Jun 13, 2018 at 4:41 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've tested following scenarios on the IS 5.6.0-RC2 pack with default
>>> database setup.
>>>
>>>- Enable user self-registration and self-register a new user.
>>>- Add multiple consent purposes with multiple PII categories.
>>>-
>>>- Login to dashboard and see whether we can see the default consent
>>>and above added PII categories.
>>>-
>>>- Confirm claims are getting filtered based on consents.
>>>- Configure a service provider with OpenID Connect and acquire
>>>access tokens via Authorization Code, Implicit, Client Credential
>>>andPassword grant types.
>>>- Enable ID token encryption for the service provider and test the
>>>flow with decryption for all grant types.
>>>- Delete the self-signed up user, create another user with the exact
>>>same username, log in to the dashboard and see what are the consents
>>>shown.
>>>- Revoke consents of the user via the dashboard and try accessing
>>>the SP to verify the consents are asked again.
>>>- Delete the SP, login to the dashboard and see whether the consents
>>>are deleted for that SP.
>>>
>>>
>>> No blocking issues are found.
>>>
>>> +1 to go ahead with the release.
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>>
>>> On Wed, Jun 13, 2018 at 12:18 PM Madawa Soysa  wrote:
>>>
 Hi all,

 We are pleased to announce the second release candidate of WSO2
 Identity Server 5.6.0.

 This release fixes the following issues

- 5.6.0-RC1 Fixes

- 5.6.0-Beta Fixes

- 5.6.0-Alpha2 Fixes

- 5.6.0-Alpha Fixes

- 5.6.0-M7 Fixes

- 5.6.0-M6 Fixes

- 5.6.0-M5 Fixes

- 5.6.0-M4 Fixes

- 5.6.0-M3 Fixes

- 5.6.0-M2 Fixes

- 5.6.0-M1 Fixes


 Source and distribution,
 Runtime -
 https://github.com/wso2/product-is/releases/tag/v5.6.0-rc2
 Analytics -
 https://github.com/wso2/analytics-is/releases/v5.6.0-rc2

 Please download, test the product and vote.

 [+] Stable - go ahead and release
 [-] Broken - do not release (explain why)

 Thanks,
 WSO2 Identity and Access Management Team -
 --

 Madawa Soysa / Senior Software Engineer
 mada...@wso2.com / +94714616050

 *WSO2 Inc.*
 lean.enterprise.middleware

   




>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Dewni Weeraman*
>> Trainee Software Engineer | WSO2
>>
>> Email: de...@wso2.com
>> Mobile: +94772979049
>> Web: http://wso2.com/
>>
>>
>>
>>
>
>
> --
> *Dewni Weeraman*
> Trainee Software Engineer | WSO2
>
> Email: de...@wso2.com
> Mobile: +94772979049
> Web: http://wso2.com/
>
>
>
>

-- 

Madawa Soysa / Senior Software Engineer
mada...@wso2.com / +94714616050

*WSO2 Inc.*
lean.enterprise.middleware

  

Re: [Architecture] [VOTE] Release of WSO2 Identity Server 5.6.0 RC2

[Dewni Weeraman]

Hi all,

Sorry I made a small mistake. Please note that the above scenarios were
tested on RC2 pack.

Thanks,
Dewni

On Thu, Jun 14, 2018 at 10:40 AM, Dewni Weeraman  wrote:

> Hi,
>
> Tested below scenarios on RC1 pack,
>
>- OAuth token revocation.
>- Invoke the OAuth Introspection Endpoint.
>- Entitlement policy creation using write policy in xml and publishing.
>- Using REST APIs via XACML to manage entitlement.
>- Create, update, get, delete an OAuth app using Dynamic Client
>Registration endpoint.
>
>
> No blocking issues found.
>
> [+] Stable - Go ahead and release
>
> Thanks,
> Dewni
>
> On Wed, Jun 13, 2018 at 4:41 PM, Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> I've tested following scenarios on the IS 5.6.0-RC2 pack with default
>> database setup.
>>
>>- Enable user self-registration and self-register a new user.
>>- Add multiple consent purposes with multiple PII categories.
>>-
>>- Login to dashboard and see whether we can see the default consent
>>and above added PII categories.
>>-
>>- Confirm claims are getting filtered based on consents.
>>- Configure a service provider with OpenID Connect and acquire access
>>tokens via Authorization Code, Implicit, Client Credential andPassword
>>grant types.
>>- Enable ID token encryption for the service provider and test the
>>flow with decryption for all grant types.
>>- Delete the self-signed up user, create another user with the exact
>>same username, log in to the dashboard and see what are the consents
>>shown.
>>- Revoke consents of the user via the dashboard and try accessing the
>>SP to verify the consents are asked again.
>>- Delete the SP, login to the dashboard and see whether the consents
>>are deleted for that SP.
>>
>>
>> No blocking issues are found.
>>
>> +1 to go ahead with the release.
>>
>> Thanks,
>> Vihanga.
>>
>>
>> On Wed, Jun 13, 2018 at 12:18 PM Madawa Soysa  wrote:
>>
>>> Hi all,
>>>
>>> We are pleased to announce the second release candidate of WSO2 Identity
>>> Server 5.6.0.
>>>
>>> This release fixes the following issues
>>>
>>>- 5.6.0-RC1 Fixes
>>>
>>>- 5.6.0-Beta Fixes
>>>
>>>- 5.6.0-Alpha2 Fixes
>>>
>>>- 5.6.0-Alpha Fixes
>>>
>>>- 5.6.0-M7 Fixes
>>>
>>>- 5.6.0-M6 Fixes
>>>
>>>- 5.6.0-M5 Fixes
>>>
>>>- 5.6.0-M4 Fixes
>>>
>>>- 5.6.0-M3 Fixes
>>>
>>>- 5.6.0-M2 Fixes
>>>
>>>- 5.6.0-M1 Fixes
>>>
>>>
>>> Source and distribution,
>>> Runtime -  https://github.com/wso2/product-is/releases/tag/v5.6.0-
>>> rc2
>>> Analytics - https://github.com/wso2/analytics-is/releases/v5.6.0-rc2
>>>
>>> Please download, test the product and vote.
>>>
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thanks,
>>> WSO2 Identity and Access Management Team -
>>> --
>>>
>>> Madawa Soysa / Senior Software Engineer
>>> mada...@wso2.com / +94714616050
>>>
>>> *WSO2 Inc.*
>>> lean.enterprise.middleware
>>>
>>>   
>>>
>>>
>>>
>>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Dewni Weeraman*
> Trainee Software Engineer | WSO2
>
> Email: de...@wso2.com
> Mobile: +94772979049
> Web: http://wso2.com/
>
>
>
>


-- 
*Dewni Weeraman*
Trainee Software Engineer | WSO2

Email: de...@wso2.com
Mobile: +94772979049
Web: http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [VOTE] Release of WSO2 Identity Server 5.6.0 RC2

[Dewni Weeraman]

Hi,

Tested below scenarios on RC1 pack,

   - OAuth token revocation.
   - Invoke the OAuth Introspection Endpoint.
   - Entitlement policy creation using write policy in xml and publishing.
   - Using REST APIs via XACML to manage entitlement.
   - Create, update, get, delete an OAuth app using Dynamic Client
   Registration endpoint.


No blocking issues found.

[+] Stable - Go ahead and release

Thanks,
Dewni

On Wed, Jun 13, 2018 at 4:41 PM, Vihanga Liyanage  wrote:

> Hi all,
>
> I've tested following scenarios on the IS 5.6.0-RC2 pack with default
> database setup.
>
>- Enable user self-registration and self-register a new user.
>- Add multiple consent purposes with multiple PII categories.
>-
>- Login to dashboard and see whether we can see the default consent
>and above added PII categories.
>-
>- Confirm claims are getting filtered based on consents.
>- Configure a service provider with OpenID Connect and acquire access
>tokens via Authorization Code, Implicit, Client Credential andPassword
>grant types.
>- Enable ID token encryption for the service provider and test the
>flow with decryption for all grant types.
>- Delete the self-signed up user, create another user with the exact
>same username, log in to the dashboard and see what are the consents
>shown.
>- Revoke consents of the user via the dashboard and try accessing the
>SP to verify the consents are asked again.
>- Delete the SP, login to the dashboard and see whether the consents
>are deleted for that SP.
>
>
> No blocking issues are found.
>
> +1 to go ahead with the release.
>
> Thanks,
> Vihanga.
>
>
> On Wed, Jun 13, 2018 at 12:18 PM Madawa Soysa  wrote:
>
>> Hi all,
>>
>> We are pleased to announce the second release candidate of WSO2 Identity
>> Server 5.6.0.
>>
>> This release fixes the following issues
>>
>>- 5.6.0-RC1 Fixes
>>
>>- 5.6.0-Beta Fixes
>>
>>- 5.6.0-Alpha2 Fixes
>>
>>- 5.6.0-Alpha Fixes
>>
>>- 5.6.0-M7 Fixes
>>
>>- 5.6.0-M6 Fixes
>>
>>- 5.6.0-M5 Fixes
>>
>>- 5.6.0-M4 Fixes
>>
>>- 5.6.0-M3 Fixes
>>
>>- 5.6.0-M2 Fixes
>>
>>- 5.6.0-M1 Fixes
>>
>>
>> Source and distribution,
>> Runtime -  https://github.com/wso2/product-is/releases/tag/v5.6.0-rc2
>> Analytics - https://github.com/wso2/analytics-is/releases/v5.6.0-rc2
>>
>> Please download, test the product and vote.
>>
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> WSO2 Identity and Access Management Team -
>> --
>>
>> Madawa Soysa / Senior Software Engineer
>> mada...@wso2.com / +94714616050
>>
>> *WSO2 Inc.*
>> lean.enterprise.middleware
>>
>>   
>>
>>
>>
>>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Dewni Weeraman*
Trainee Software Engineer | WSO2

Email: de...@wso2.com
Mobile: +94772979049
Web: http://wso2.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Manager Micro Gateway 2.5.0-M1 Released!!!

[Harsha Kumara]

The WSO2 API Manager team is pleased to announce the release of API Manager
Micro Gateway 2.5.0-M1. It's now available to download.Distribution

https://github.com/wso2/product-microgateway/releases/download/v2.5.0-m1-r/wso2am-micro-gw-2.5.0-m1.zip

Documentation

https://docs.wso2.com/display/AM2xx/Configuring+the+API+Microgateway
Introduction

The Microgateway is a specialized form of the WSO2 API Gateway. Its main
characteristics are

   - Its ability to execute in isolation without mandatory connections to
   other components (Key Manager, Traffic Manager, etc).
   - Ability to host a subset of APIs of choice (defined on the API
   Publisher) instead of all.
   - Immutability - if you update an API you need to re-create the
   container/instance, no hot deployment.
   Microgateway offers you a proxy that is capable of performing security
   validations (OAuth, Basic Auth, Signed JWT), in-memory (local) rate
   limiting and operational analytics.

Design Goals

Following are some of its main expectations of Microgateway

Ability to host just one or a selected set (subset) of APIs only.
Ability to execute in complete isolation once setup, without having the
need to contact the Management or Security components.
Easy integration with CI/CD processes.
Seamless integration with deployment automation tools and techniques.
Architecture

The following diagram illustrates the process of getting an API (or a
selected set of APIs) to be hosted on a Microgateway.

[image: Architecture]

Setting up microgateway

This product will include a CLI, the B7a platform distribution and a few
B7a extensions (Endpoints and Filters). The CLI will have two main
responsibilities.

   - Setting up a Microgateway project.
   - Running the Microgateway project.

These two steps will be treated as two phases. One will first complete the
setup phase and move on to the Run phase. The reason for treating them as
phases is to make it possible for developers to take control of the runtime
if and when required. For example, what gets run as default on a
Microgateway is a simple API proxy. If a developer needs to perform some
sort of an integration or change the Ballerina source files for some other
reason, he could engage with the project after the setup phase and do the
required modifications before the runtime is deployed.
Bug Fixes And Improvements in 2.5.0-M1

   - GitHub (Product-Microgateway
   

   )

Known Issues

All the open issues pertaining to WSO2 API Manager Microgateway are
reported at the following location:

   - GitHub (Product-microgateway
   
   )

How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

   -

   Developer List: d...@wso2.org | Subscribe | Mail Archive
   -

   User List: u...@wso2.org | Subscribe | Mail Archive

Reporting Issues

We encourage you to report issues, documentation faults, and feature
requests regarding WSO2 API Manager Micro Gateway through the public API
Manager Micro Gateway Git Repo
.
-- The WSO2 API Manager Team --

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Passing parameters from authentication script to Authenticators

[Senthalan Kanagalingam]

[update]

hi all,

We had an offline discussion and decided to change the authentication
script syntax.  We will be having an extra object in the 2nd parameter in
the executeStep which is introduced to filter the authenticators[1]. There
we can specify the authenticator and parameter

executeStep(, { authenticationOptions  : ,
*authenticatorParams : [ {authenticator : ,*

*params : {  :  }*

*]*,

{onSuccess: function(){}, onFail: function(){}})



An example will be,

function onInitialRequest (context) {
   executeStep(1 ,{ authenticationOptions  : [{ authenticator : "Sample
HardwareKey Authenticator"},{ idp : "google" }],
authenticatorParams : [{ authenticator : "Sample HardwareKey
Authenticator",
 params : {
   "foo" : "xyz"
 }},
   { idp : "google",
  params : {
   "foo" : "abc"
 }}]
  },{
 onSuccess : function(context) {
  executeStep(2);
 }
   });
}

In authenticator (java code), we can access the parameter map defined by
the script for that particular authenticator using getRuntimeParams()
method.

Please share your idea about this new syntax change and the method name.


[1] - "[IS] Filtering authentication options of a step by script"


On Tue, Jun 12, 2018 at 5:32 PM Senthalan Kanagalingam 
wrote:

> Hi all,
>
> With an offline discussion we decided to change the definition from
> parameter to property.
>
> context.*property*.foo = "xyz";
> and/or
> context.*property*['foo'] = "xyz";
>
> So in the authenticator we can access using getScriptProperty("foo");
>
> thanks,
> Senthalan.
>
> On Mon, Jun 11, 2018 at 3:45 PM Senthalan Kanagalingam 
> wrote:
>
>> Hi Pulasthi,
>>
>> On Mon, Jun 11, 2018 at 11:36 AM Pulasthi Mahawithana 
>> wrote:
>>
>>> Hi Senthalan,
>>>
>>> On Mon, Jun 11, 2018 at 11:10 AM Senthalan Kanagalingam <
>>> sentha...@wso2.com> wrote:
>>>
 Hi all,

 I am working on the $subject. The purpose of this implementation is to
 have application-specific configurations for authenticators. Currently, we
 can static configurations for the authenticators in the
 application-authentication.xml file.

 In the script, we can set the parameters as follow, If we want to pass
 the foo to the authenticator,

 context.foo = "xyz";

>>>
>>>
>>
>>> Shall we change this to following to avoid any conflicts with existing
>>> context objects?
>>>
>>> context.parameter.foo = "xyz";
>>> and/or
>>> context.parameter['foo'] = "xyz";
>>>
>>
>> + 1. I have implemented with the suggestions.
>>
>>
>>>

 We can get back the value in the authenticators( executed after this
 definition) by calling context.getScriptParameter("foo")

 I have developed a POC for this. I have created a new map in the
 "AuthenticationContext" to save these parameters.

 Please share your thoughts about this implementation.

 thanks,
 Senthalan.


 *Senthalan Kanagalingam*
 *Software Engineer - WSO2 Inc.*
 *Mobile : +94 (0) 77 18 77 466*
 

>>>
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Associate Technical Lead
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: https://medium.com/@pulasthi7/
>>>
>>> 
>>>
>>
>>
>> --
>>
>> *Senthalan Kanagalingam*
>> *Software Engineer - WSO2 Inc.*
>> *Mobile : +94 (0) 77 18 77 466*
>> 
>>
>
>
> --
>
> *Senthalan Kanagalingam*
> *Software Engineer - WSO2 Inc.*
> *Mobile : +94 (0) 77 18 77 466*
> 
>


-- 

*Senthalan Kanagalingam*
*Software Engineer - WSO2 Inc.*
*Mobile : +94 (0) 77 18 77 466*

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [VOTE] Release of WSO2 Identity Server 5.6.0 RC2

[Vihanga Liyanage]

Hi all,

I've tested following scenarios on the IS 5.6.0-RC2 pack with default
database setup.

   - Enable user self-registration and self-register a new user.
   - Add multiple consent purposes with multiple PII categories.
   -
   - Login to dashboard and see whether we can see the default consent and
   above added PII categories.
   -
   - Confirm claims are getting filtered based on consents.
   - Configure a service provider with OpenID Connect and acquire access
   tokens via Authorization Code, Implicit, Client Credential andPassword
   grant types.
   - Enable ID token encryption for the service provider and test the flow
   with decryption for all grant types.
   - Delete the self-signed up user, create another user with the exact
   same username, log in to the dashboard and see what are the consents
   shown.
   - Revoke consents of the user via the dashboard and try accessing the SP
   to verify the consents are asked again.
   - Delete the SP, login to the dashboard and see whether the consents are
   deleted for that SP.


No blocking issues are found.

+1 to go ahead with the release.

Thanks,
Vihanga.


On Wed, Jun 13, 2018 at 12:18 PM Madawa Soysa  wrote:

> Hi all,
>
> We are pleased to announce the second release candidate of WSO2 Identity
> Server 5.6.0.
>
> This release fixes the following issues
>
>- 5.6.0-RC1 Fixes
>
>- 5.6.0-Beta Fixes
>
>- 5.6.0-Alpha2 Fixes
>
>- 5.6.0-Alpha Fixes
>
>- 5.6.0-M7 Fixes
>
>- 5.6.0-M6 Fixes
>
>- 5.6.0-M5 Fixes
>
>- 5.6.0-M4 Fixes
>
>- 5.6.0-M3 Fixes
>
>- 5.6.0-M2 Fixes
>
>- 5.6.0-M1 Fixes
>
>
> Source and distribution,
> Runtime -  https://github.com/wso2/product-is/releases/tag/v5.6.0-rc2
> Analytics - https://github.com/wso2/analytics-is/releases/v5.6.0-rc2
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> WSO2 Identity and Access Management Team -
> --
>
> Madawa Soysa / Senior Software Engineer
> mada...@wso2.com / +94714616050
>
> *WSO2 Inc.*
> lean.enterprise.middleware
>
>   
>
>
>
>

-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Tool to configure changes while starting an API-M profile

[Sarubi Thillainathan]

Hi Nuwan,

I'll include that as well.

Thanks,
Sarubi

On Wed, Jun 13, 2018 at 2:19 PM, Nuwan Dias  wrote:

> In the doc, it would be better to put the logs that are being printed
> while the optimization happens as an example.
>
> On Wed, Jun 13, 2018 at 12:06 PM, Sarubi Thillainathan 
> wrote:
>
>> Hi all,
>>
>> PR for $Subject can be found in [1].
>> Documentation for this can be found in [2]
>>
>> [1] https://github.com/wso2/product-apim/pull/3350
>> [2] https://docs.google.com/document/d/1nB112HRslaqXLQA50lXdHblf
>> 42QgMTIzTCAPVaOFjrA/edit?usp=sharing
>>
>>
>> On Fri, Jun 8, 2018 at 9:14 AM, Chamila De Alwis 
>> wrote:
>>
>>> Hi Nuwan,
>>>
>>> Thanks! I understand the context now and I completely agree that some
>>> kind of convenience is required to prune the base distribution to profile
>>> specific ones. It could very well be automated better than being documented
>>> instructions.
>>>
>>> My idea was that if some kind of automation could be done, it would be
>>> better suited on top of what we have already built out (ex: our knowledge
>>> on Puppet, what WUM client does with pack building). On the other hand,
>>> automation which considers details after a certain point could have to
>>> cater for a wider spectrum of requirements, which could make the tool
>>> complicated.
>>>
>>> +1 to make the tool to automate the prunning part of the process.
>>>
>>> Startup time getting affected by the `-Dprofile` property might not be
>>> that much of a concern at all (other than for Containerized scenarios,
>>> which could make use of pre-baked optimized packs), because instance
>>> downtimes are almost always pre-planned and will be done with back up
>>> nodes. So few additional seconds would not be that much of a difference.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Associate Technical Lead | WSO2
>>> +94 77 220 7163
>>> Blog: https://medium.com/@chamilad
>>>
>>>
>>>
>>>
>>> On Thu, Jun 7, 2018 at 1:18 AM Nuwan Dias  wrote:
>>>
 While these concerns are valid, I think we need to step back and look
 at this. If you look at are current documentation related to profiles, you
 will see that we have lots of manual instructions to optimize the profiles.
 What this tool/command does is to simply automate all those manual
 instructions. So our "produce" at the end of the day will be exactly the
 same as it is today.

 This tool does modify some configs, but I wouldn't consider that as a
 config automation. Config automation is supposed to do configs to make the
 product work according to a particular deployment architecture. The configs
 we're modifying in this case do nothing to do with deployment architecture.
 All it does is to remove unnecessary processes and stuff based on the
 profile. I would rather consider the outcome/produce of this tool to be
 used as the base image on which config automation tools should run on.

 I don't think WUM is a problem because WUM always gives you a fresh
 distribution. It does not work/modify your current running instance.
 Therefore a WUM user has to run the tool/process on the WUM updated
 distribution as they do today. So the pipeline would be

 wum_update --> optimize --> puppet --> run

 As Sinthuja has pointed it would perhaps be good to create a new distro
 (.zip) after this process so that one can use it as the base distro. We
 have currently focused on making the optimization work seamlessly with the
 -Dprofile=x startup command, which is how a majority of of customers using
 profiles use the product.

 Thanks,
 NuwanD.

 On Thu, Jun 7, 2018 at 12:19 PM, Chamila De Alwis 
 wrote:

> Thanks Sarubi for the detailed explanation! I had understood the
> context wrong and this cleared up some of the doubts I had. However, I
> still have a hard time grasping the whole user story.
>
> 1. I assume the changes you mention are the ones at [1]. If that is
> the case, there are indeed configuration changes involved. These are
> typically handled by a configuration automation tool. This is the overlap
> I'm concerned with. With the limited information I have, I guess any 
> config
> automation will have to consider both scenarios where this script is
> present and absent. In other words, a set of scripts that work with a pack
> edited by this script would not work with the shipped pack.
>
> 2. What would be the effect of WUM updates? If the script considers
> the config changes in #1, and if any WUM updates affect those
> configurations (any changes would be additions), would the script also 
> have
> to be updated?
>
> 3. Going along with what Sinthuja has raised above, if new packs are
> to be created, then most of the operations would be what a config
> automation tool does.
>
> 4. What would be 

Re: [Architecture] Tool to configure changes while starting an API-M profile

[Nuwan Dias]

In the doc, it would be better to put the logs that are being printed while
the optimization happens as an example.

On Wed, Jun 13, 2018 at 12:06 PM, Sarubi Thillainathan 
wrote:

> Hi all,
>
> PR for $Subject can be found in [1].
> Documentation for this can be found in [2]
>
> [1] https://github.com/wso2/product-apim/pull/3350
> [2] https://docs.google.com/document/d/1nB112HRslaqXLQA50lXdHblf42QgM
> TIzTCAPVaOFjrA/edit?usp=sharing
>
>
> On Fri, Jun 8, 2018 at 9:14 AM, Chamila De Alwis 
> wrote:
>
>> Hi Nuwan,
>>
>> Thanks! I understand the context now and I completely agree that some
>> kind of convenience is required to prune the base distribution to profile
>> specific ones. It could very well be automated better than being documented
>> instructions.
>>
>> My idea was that if some kind of automation could be done, it would be
>> better suited on top of what we have already built out (ex: our knowledge
>> on Puppet, what WUM client does with pack building). On the other hand,
>> automation which considers details after a certain point could have to
>> cater for a wider spectrum of requirements, which could make the tool
>> complicated.
>>
>> +1 to make the tool to automate the prunning part of the process.
>>
>> Startup time getting affected by the `-Dprofile` property might not be
>> that much of a concern at all (other than for Containerized scenarios,
>> which could make use of pre-baked optimized packs), because instance
>> downtimes are almost always pre-planned and will be done with back up
>> nodes. So few additional seconds would not be that much of a difference.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Associate Technical Lead | WSO2
>> +94 77 220 7163
>> Blog: https://medium.com/@chamilad
>>
>>
>>
>>
>> On Thu, Jun 7, 2018 at 1:18 AM Nuwan Dias  wrote:
>>
>>> While these concerns are valid, I think we need to step back and look at
>>> this. If you look at are current documentation related to profiles, you
>>> will see that we have lots of manual instructions to optimize the profiles.
>>> What this tool/command does is to simply automate all those manual
>>> instructions. So our "produce" at the end of the day will be exactly the
>>> same as it is today.
>>>
>>> This tool does modify some configs, but I wouldn't consider that as a
>>> config automation. Config automation is supposed to do configs to make the
>>> product work according to a particular deployment architecture. The configs
>>> we're modifying in this case do nothing to do with deployment architecture.
>>> All it does is to remove unnecessary processes and stuff based on the
>>> profile. I would rather consider the outcome/produce of this tool to be
>>> used as the base image on which config automation tools should run on.
>>>
>>> I don't think WUM is a problem because WUM always gives you a fresh
>>> distribution. It does not work/modify your current running instance.
>>> Therefore a WUM user has to run the tool/process on the WUM updated
>>> distribution as they do today. So the pipeline would be
>>>
>>> wum_update --> optimize --> puppet --> run
>>>
>>> As Sinthuja has pointed it would perhaps be good to create a new distro
>>> (.zip) after this process so that one can use it as the base distro. We
>>> have currently focused on making the optimization work seamlessly with the
>>> -Dprofile=x startup command, which is how a majority of of customers using
>>> profiles use the product.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Thu, Jun 7, 2018 at 12:19 PM, Chamila De Alwis 
>>> wrote:
>>>
 Thanks Sarubi for the detailed explanation! I had understood the
 context wrong and this cleared up some of the doubts I had. However, I
 still have a hard time grasping the whole user story.

 1. I assume the changes you mention are the ones at [1]. If that is the
 case, there are indeed configuration changes involved. These are typically
 handled by a configuration automation tool. This is the overlap I'm
 concerned with. With the limited information I have, I guess any config
 automation will have to consider both scenarios where this script is
 present and absent. In other words, a set of scripts that work with a pack
 edited by this script would not work with the shipped pack.

 2. What would be the effect of WUM updates? If the script considers the
 config changes in #1, and if any WUM updates affect those configurations
 (any changes would be additions), would the script also have to be updated?

 3. Going along with what Sinthuja has raised above, if new packs are to
 be created, then most of the operations would be what a config automation
 tool does.

 4. What would be overlap/effect on the product installer effort that is
 going on in the IE team [2]


 [1] - https://docs.wso2.com/display/AM2xx/Product+Profiles
 [2] - "Installers for WSO2 products"

 Regards,
 Chamila de Alwis

[Architecture] [VOTE] Release of WSO2 Identity Server 5.6.0 RC2

[Madawa Soysa]

Hi all,

We are pleased to announce the second release candidate of WSO2 Identity
Server 5.6.0.

This release fixes the following issues

   - 5.6.0-RC1 Fixes
   
   - 5.6.0-Beta Fixes
   
   - 5.6.0-Alpha2 Fixes
   
   - 5.6.0-Alpha Fixes
   
   - 5.6.0-M7 Fixes
   
   - 5.6.0-M6 Fixes
   
   - 5.6.0-M5 Fixes
   
   - 5.6.0-M4 Fixes
   
   - 5.6.0-M3 Fixes
   
   - 5.6.0-M2 Fixes
   
   - 5.6.0-M1 Fixes
   

Source and distribution,
Runtime -  https://github.com/wso2/product-is/releases/tag/v5.6.0-rc2
Analytics - https://github.com/wso2/analytics-is/releases/v5.6.0-rc2

Please download, test the product and vote.

[+] Stable - go ahead and release
[-] Broken - do not release (explain why)

Thanks,
WSO2 Identity and Access Management Team -
-- 

Madawa Soysa / Senior Software Engineer
mada...@wso2.com / +94714616050

*WSO2 Inc.*
lean.enterprise.middleware

  
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Tool to configure changes while starting an API-M profile

[Sarubi Thillainathan]

Hi all,

PR for $Subject can be found in [1].
Documentation for this can be found in [2]

[1] https://github.com/wso2/product-apim/pull/3350
[2]
https://docs.google.com/document/d/1nB112HRslaqXLQA50lXdHblf42QgMTIzTCAPVaOFjrA/edit?usp=sharing


On Fri, Jun 8, 2018 at 9:14 AM, Chamila De Alwis  wrote:

> Hi Nuwan,
>
> Thanks! I understand the context now and I completely agree that some kind
> of convenience is required to prune the base distribution to profile
> specific ones. It could very well be automated better than being documented
> instructions.
>
> My idea was that if some kind of automation could be done, it would be
> better suited on top of what we have already built out (ex: our knowledge
> on Puppet, what WUM client does with pack building). On the other hand,
> automation which considers details after a certain point could have to
> cater for a wider spectrum of requirements, which could make the tool
> complicated.
>
> +1 to make the tool to automate the prunning part of the process.
>
> Startup time getting affected by the `-Dprofile` property might not be
> that much of a concern at all (other than for Containerized scenarios,
> which could make use of pre-baked optimized packs), because instance
> downtimes are almost always pre-planned and will be done with back up
> nodes. So few additional seconds would not be that much of a difference.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead | WSO2
> +94 77 220 7163
> Blog: https://medium.com/@chamilad
>
>
>
>
> On Thu, Jun 7, 2018 at 1:18 AM Nuwan Dias  wrote:
>
>> While these concerns are valid, I think we need to step back and look at
>> this. If you look at are current documentation related to profiles, you
>> will see that we have lots of manual instructions to optimize the profiles.
>> What this tool/command does is to simply automate all those manual
>> instructions. So our "produce" at the end of the day will be exactly the
>> same as it is today.
>>
>> This tool does modify some configs, but I wouldn't consider that as a
>> config automation. Config automation is supposed to do configs to make the
>> product work according to a particular deployment architecture. The configs
>> we're modifying in this case do nothing to do with deployment architecture.
>> All it does is to remove unnecessary processes and stuff based on the
>> profile. I would rather consider the outcome/produce of this tool to be
>> used as the base image on which config automation tools should run on.
>>
>> I don't think WUM is a problem because WUM always gives you a fresh
>> distribution. It does not work/modify your current running instance.
>> Therefore a WUM user has to run the tool/process on the WUM updated
>> distribution as they do today. So the pipeline would be
>>
>> wum_update --> optimize --> puppet --> run
>>
>> As Sinthuja has pointed it would perhaps be good to create a new distro
>> (.zip) after this process so that one can use it as the base distro. We
>> have currently focused on making the optimization work seamlessly with the
>> -Dprofile=x startup command, which is how a majority of of customers using
>> profiles use the product.
>>
>> Thanks,
>> NuwanD.
>>
>> On Thu, Jun 7, 2018 at 12:19 PM, Chamila De Alwis 
>> wrote:
>>
>>> Thanks Sarubi for the detailed explanation! I had understood the context
>>> wrong and this cleared up some of the doubts I had. However, I still have a
>>> hard time grasping the whole user story.
>>>
>>> 1. I assume the changes you mention are the ones at [1]. If that is the
>>> case, there are indeed configuration changes involved. These are typically
>>> handled by a configuration automation tool. This is the overlap I'm
>>> concerned with. With the limited information I have, I guess any config
>>> automation will have to consider both scenarios where this script is
>>> present and absent. In other words, a set of scripts that work with a pack
>>> edited by this script would not work with the shipped pack.
>>>
>>> 2. What would be the effect of WUM updates? If the script considers the
>>> config changes in #1, and if any WUM updates affect those configurations
>>> (any changes would be additions), would the script also have to be updated?
>>>
>>> 3. Going along with what Sinthuja has raised above, if new packs are to
>>> be created, then most of the operations would be what a config automation
>>> tool does.
>>>
>>> 4. What would be overlap/effect on the product installer effort that is
>>> going on in the IE team [2]
>>>
>>>
>>> [1] - https://docs.wso2.com/display/AM2xx/Product+Profiles
>>> [2] - "Installers for WSO2 products"
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Associate Technical Lead | WSO2
>>> +94 77 220 7163
>>> Blog: https://medium.com/@chamilad
>>>
>>>
>>>
>>>
>>> On Wed, Jun 6, 2018 at 11:21 PM Sinthuja Rajendran 
>>> wrote:
>>>
 Hi,
 On Thu, Jun 7, 2018 at 11:07 AM Sarubi Thillainathan