On Wed, Oct 12, 2016 at 7:36 PM, Kishanthan Thangarajah <kishant...@wso2.com
> wrote:

>
>
> On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>>
>> On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>> Do we really need multi-profile support (at an osgi level) on C5? What
>>>> if we have separate dedicated runtimes per profile? Which means that we
>>>> have a gateway runtime, store runtime, etc. within the same distribution?
>>>> Each will run on its own port, maybe using offsets by default (no need to
>>>> worry about that if each profile is a container).
>>>>
>>>
>>> This is the similar thing we are trying propose. The "profiles" concept
>>> is C5 is actually runtime we are talking about. It is not only about osgi
>>> bundles, but everything a runtime needs to start on its own.
>>>
>>> For example, api-manager store runtime needs set of bundles,
>>> configuration files and store UI component written using uuf/jaggery. The
>>> tool will create this runtime by reading the descriptor file and launch the
>>> instance as a separate JVM.
>>>
>>
>> But why would we need a tool to do that? What if we build the product
>> itself in that manner.
>>
>
> It's not only about API-Manager product but the same requirement is needed
> for IoT product (and IS may also have the requirement when running the
> user/admin portal separately) that require multiple runtimes. So isn't it
> better to provide a common way to do this?
>

Well, by providing a tool aren't we pushing the complication to the
customer's end? Specially when it comes to automating (puppet, chef)
customer specific deployment patterns and all, won't it be tricky to play
around with this tool to achieve it? Even for the case of IoTS and IS and
maybe even for the new ESB, I was thinking that all should build their own
distros in that way :).

>
>
>> Ex: Store will have all its bundles, config files, etc in a single
>> directory. And it'll have its own startup script (.sh). Same will be for
>> the publisher and other runtimes. It will result in a certain amount of
>> duplicate jars in those directories (carbon kernel), but that isn't much of
>> a problem isn't it? Do you see any other problems in doing that?
>>
>
> The duplication will be high here IMO based on the passed experience. The
> pack size will increase due to this.
>

Well, our focus should be to reduce the size of the runtime right? Not
really the pack. As far as the size of store, publisher, etc remain small,
it doesn't really matter if their accumulated size is large. Because the
objective of making the pack size small is to make them more container
friendly. So in practise, people will only execute individual runtimes in a
container and not the whole distribution (accumulated pack). Therefore as
far as the individual runtime is small, it should be fine I think.

>
>

>>> Additionally if we have option of docker compose given, then it will
>>> launch a docker instance with the store runtime.
>>>
>>>
>>>> Also if we have profiles, do we also have a global profile which runs
>>>> all components in one?
>>>>
>>>
>>> No, with the above model, there will not be a single profile (or global
>>> profile) which has all the runtime components in it and we have to move
>>> away from single product running all the components together in the same
>>> JVM. Each runtime will be started as different processes/JVM (can be
>>> OSGi-java process and just another java process).
>>>
>>> If a runtime needs a non-OSGi java process (say for example you want to
>>> start activemq as part of the product), then you can also do that using
>>> this proposed approach.
>>>
>>>
>>>
>>>> I doubt we'll be able to achieve the target of 1 to 2 sec startup time
>>>> if we do that.
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq <sha...@wso2.com>
>>>> wrote:
>>>>
>>>>> With regards to the discussion on improving some of the limitations in
>>>>> the our current product profiles support [1], we had a discussion to
>>>>> rethink how we can improve the support for running different profiles in 
>>>>> C5.
>>>>>
>>>>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana,
>>>>> Rohan
>>>>>
>>>>> *Limitations with the current approach*
>>>>>
>>>>> - We only consider the bundles.info and load the necessary bundles,
>>>>> however there might be certain configs and deployment artifacts that's not
>>>>> required
>>>>> - Some functionalities that aren't required for certain profiles are
>>>>> enabled (e.g. transports)
>>>>> - Distribution size is not optimal for container native architecture
>>>>>
>>>>> *Suggestion for profile support in C5*
>>>>>
>>>>> Considering the above limitation, we decided on building a profile
>>>>> specific distribution from the base distribution. The base distribution
>>>>> will pack all artifacts and also profile specific descriptors
>>>>>
>>>>> If there are any configs specific to a profile, those configs can be
>>>>> changed using the deployment.properties file. The base distribution will
>>>>> have deployment.properties file specific to the profiles, that way we 
>>>>> don't
>>>>> have to duplicate any config files.
>>>>>
>>>>> During the runtime, each profile will run as an independent process -
>>>>> for this, we'll be moving away from default 9763/9443 ports, instead each
>>>>> product will have an assigned port range.
>>>>>
>>>>> We will provide a tool that will look into the profile descriptors and
>>>>> build the bare minimum runtime corresponding to the profile. This tool 
>>>>> will
>>>>> copy the required bundles, config files etc by looking into the meta info.
>>>>> We can use the same tool to start the runtimes as well.
>>>>>
>>>>> The directory structure of the base distribution will be something
>>>>> like;
>>>>>
>>>>> wso2-am
>>>>> |-- bin
>>>>> |-- osgi
>>>>>      |-- plugins
>>>>> |-- conf
>>>>> |-- profiles
>>>>>      |-- gateway
>>>>>           |-- metadata.yaml
>>>>>           |-- deployment.properties
>>>>>      |-- km
>>>>>           |-- metadata.yaml
>>>>>           |-- deployment.properties
>>>>> |-- *runtime* --> wiill be created by the tool
>>>>>      |-- *wso2-am-gateway*
>>>>>      |-- *wso2-am-km*
>>>>>
>>>>> As shown in the folder structure, the tool will create the profile
>>>>> specific runtime by reading the bundles.info, metadata file etc. In
>>>>> the metadata.yaml file, we can specify what are the config files and other
>>>>> resources needed for that particular profile. So a given runtime will only
>>>>> have the minimum required jars and configs.
>>>>>
>>>>> Additionally, the tool provides the option to create docker-compose
>>>>> yaml that would take the created runtimes and deploy it in containers.
>>>>>
>>>>> We have started implementing the tool, please share your thoughts /
>>>>> suggestions.
>>>>>
>>>>> [1] - [Architecture] How can we improve our profiles story?
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Shariq
>>>>> Associate Technical Lead
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>> email : nuw...@wso2.com
>>>> Phone : +94 777 775 729
>>>>
>>>
>>>
>>>
>>> --
>>> *Kishanthan Thangarajah*
>>> Technical Lead,
>>> Platform Technologies Team,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com
>>> <http://kishanthan.wordpress.com>*
>>> Twitter - *http://twitter.com/kishanthan
>>> <http://twitter.com/kishanthan>*
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> *Kishanthan Thangarajah*
> Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>



-- 
Nuwan Dias

Software Architect - 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

Reply via email to