[Dev] WSO2 ESB Synapse Config and kubernetes

[Ramon Gordillo]

Hi.

Is there any way to store synapse configurarion for ESB in a database, or
should we provision an kubernetes pvc to persist the esb configuration?

Thanks in advance.

Ramon
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Kubernetes and developer studio

[Ramon Gordillo]

Hi.

Has anyone connected directly Developer Studio with any carbon product
deployed in kubernetes as a remote server?

If so, which ports should be configured in dev studio?

Thanks.

Ramon
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Developer Studio Kernel RC released !

[Ramon Gordillo]

I have tested on Mars 2 (4.5.2). Developer studio has installed ok. It
seems to browse the products and get me a list, but none of them install.

I have seen that release/update site points to 4.0.0 carbon set. I have
changed to 4.1.0 platform bundle and it seems to install, at least the greg.

Maybe there is any kind of incompatibility between 4.0.0 sets and mars 2.

HTH.

2016-04-28 8:46 GMT+02:00 Awanthika Senarath :

> Hello all,
>
> I have tested the followings
>
>
>- Installation via P2
>- Updater tool preference store values.
>- Installing updates and new features via developer studio updater tool
>- Automatic Updater tool configurations and functionality.
>- Installing CEP and Data services tooling on top of kernel.
>
>
> my vote :  +1
>
>
> Regards
> Awanthika
>
> Awanthika Senarath
> Software Engineer, WSO2 Inc.
> Mobile: +94717681791
>
>
>
> On Tue, Apr 26, 2016 at 6:57 PM, Kavith Lokuhewage 
> wrote:
>
>> Hello Devs,
>>
>> Please note that source tag in above link has been incorrectly named.
>> Hence, we have recreated the tag for RC with proper name at following path.
>>
>> https://github.com/wso2/developer-studio/tree/developer-studio-kernel-4.1.0-RC
>>
>>
>> Thanks,
>>
>> On Tue, Apr 26, 2016 at 4:40 PM, Awanthika Senarath 
>> wrote:
>>
>>> Hello Devs,
>>>
>>>
>>> We are pleased to announce the vote for RC of
>>> *WSO2 Developer Studio Kernel 4.1.0.*
>>>
>>> P2 repository of WSO2 developer Studio kernel 4.1.0 is available here
>>> .
>>>  Source
>>> and Tag Location to be voted upon is available here
>>> 
>>> .
>>>
>>> Developer Studio 4.1.0 Kernel is released on Eclipse Mars (Eclipse 4.5)
>>>
>>> Developer Studio Kernel contains a single feature which has the bundles
>>> that are required to implement WSO2 specific product tooling on Eclipse.
>>>
>>>- This release contains Developer Studio migration to Eclipse mars
>>>- Improvements in the Developer Studio Updater tool for automatic
>>>updates
>>>
>>> [+] Stable - go ahead and release
>>> [-]  Broken - do not release (please explain why)
>>>
>>>
>>> Regards,
>>> Dev Studio Team
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Kavith Lokuhewage*
>> Software Engineer
>> WSO2 Inc. - http://wso2.com
>> lean . enterprise . middleware
>> Mobile - +9477-9-145-123 | +9471-455-6-401
>> Linkedin 
>> Twitter 
>>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Kubernetes (and Openshift) modules

[Ramon Gordillo]

Hi, Chamila.

About your point 1, it is not just the same in both situations. If you
restart a container that auto-configures, it is just a restarting, you
don't have to do anything else. But if you have a configured image, you
have to change the configuration files somehow, rebuild the docker image,
push it to a docker registry, and then restart it. It is not the same
straightforward process.

Your second point, is the one chosen by well-known microservices
frameworks, like consul, spring cloud-config, zookeeper, etc, so IMO there
should be no blocking problems either.

The main problem I see is the namespace. If you plan to deploy just one
project (namespace) for all the kubernetes cluster, then it is not a big
deal, but if you plan that each team has its own project with its own
API/ESB/whatever, then there is a huge maintainability issue with the
static approach.

2016-04-04 4:05 GMT+02:00 Chamila De Alwis :

> Hi Ramon,
>
> One issue that can arise if a configuration step is introduced to Docker
> images is the propagation of configuration changes in a running cluster. If
> the configuration is done for a generic server at startup, the subsequent
> changes to the config has to go live following either of two ways.
>
> 1. Kill the existing containers and let the PaaS healing component (ex: RC
> in Kubernetes) to spawn new ones and let new config be applied to those
> containers. This approach is the same for an already configured image.
> 2. Have some kind of an agent on the containers to poll and pull new
> config to the existing containers. This approach is used in Apache Stratos,
> and it tends to introduce another set of problems, when it comes to
> containers.
>
> IMO, although the management of different, already configured, servers is
> bit cumbersome, it can ease the already PaaS recommended approaches to
> various problems at the cluster management layer. For example, Kubernetes
> has a rolling-update, which takes an image name as the new version of the
> server to gradually update the cluster. This encourages an immutable image
> with changes that get written in to versioned images.
>
> For the maintainability issue of the images, can a Puppet based image
> building pipeline be applied? This would have a single Puppet server
> (configuration automation layer) which would trigger (on demand or by a
> hook of some kind) an image build with a certain set of parameters, that
> would result in a (new version or an overwriting version for the) set of
> Docker images in the local Docker registry. Additionally this event can
> trigger another execution where the Kubernetes clusters are updated. This
> way the configuration is preserved and effectively separated from the
> images and image maintenance is simplified.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Fri, Apr 1, 2016 at 4:58 PM, Imesh Gunaratne  wrote:
>
>> Hi Ramon,
>>
>> On Thu, Mar 31, 2016 at 9:42 PM, Ramon Gordillo > > wrote:
>>
>>> Hi.
>>>
>>> After doing some research and test on the puppet modules and dockerfiles
>>> with WSO2 API Management, I have some thoughts to share on this list.
>>>
>>> Great! It's really nice to hear you thoughts on $subject.
>>
>>>
>>> Some particular information, for example the DNS domain name for the
>>> cluster, the namespace, etc, is a runtime configuration. That is, if we
>>> want, for example, to deploy an instance of api management per project (aka
>>> namespace), with the current approach it will require to build a set of
>>> docker containers per project. Currently, we have 10 teams working in their
>>> own projects, so you can figure out the maintainability of 10 different
>>> sets.
>>>
>>> It's not a must create a container image with all the required
>> configuration. It's just a best practice. If the startup time of the server
>> is not a problem, running an orchestration tool at the startup should be
>> fine. We followed the same pattern few months back with Stratos + K8S.
>>
>> However I personally prefer fully configured container images approach as
>> they are less error prone and may not depend on any dynamic parameters. It
>> would be much similar to a product archive which includes all
>> configurations, the person who deploys the product just need to extract and
>> run. If there are any security concerns on the credentials and keys
>> packaged, we might need to use a tool like secure wallet.
>>
>>
>>> Apart from it, there are some configuration information that 

[Dev] Kubernetes (and Openshift) modules

[Ramon Gordillo]

Hi.

After doing some research and test on the puppet modules and dockerfiles
with WSO2 API Management, I have some thoughts to share on this list.

The initial idea for using puppet for configuring the dockerfiles seems
great. It provides a lot of flexibility, and the ruby templates are easy
enough to extend it or customize it.

However, we have some experience building docker containers for Openshift
(kubernetes is the base for it), and there are some inherent problems with
a build-time configuration.

Some particular information, for example the DNS domain name for the
cluster, the namespace, etc, is a runtime configuration. That is, if we
want, for example, to deploy an instance of api management per project (aka
namespace), with the current approach it will require to build a set of
docker containers per project. Currently, we have 10 teams working in their
own projects, so you can figure out the maintainability of 10 different
sets.

Apart from it, there are some configuration information that can be
obtained from the kubernetes master instead of hardcoding it in the
container. Even the kubernetes master information is injected in the
containers in environment variables (
http://kubernetes.io/docs/user-guide/environment-guide/, see
KUBERNETES_SERVICE_HOST, KUBERNETES_SERVICE_PORT).

With those considerations, I propose to use puppet also at runtime when
starting the container, for configuring it using template environment
variables (which are instanced at runtime), and getting as much information
as we could automatically instead of forcing the user to provide it.

Other than that, I also propose to have one script at startup per PaaS
solution. It will customize the peculiarities of this PaaS, and adapt it to
the agnostic configuration. For example, in kubernetes, some environment
variables are injected by default in the container, but in CloudFoundry,
for example, other variables with other structure is used. With this
approach, the container can be used for both of them (even with standalone
docker-compose for example) just having a simple and reusable script for
any PaaS solution.

What do you think?

Thanks.

Regards.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Development environment

[Ramon Gordillo]

Hi.

I have seen these in the docs:

https://docs.wso2.com/display/TestedPlatforms/Tested+Operating+Systems

>From the versions on the doc, I guess it is some time since the last update.

If we want to build the sources from the repo, which is the environment
(OS, DB, JDK, IDE, etc) that the dev people is using? (not the possible
ones, but the exact configuration for them)

Many thanks.

Ramon
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Smooks problem

[Ramon Gordillo]

Hi, dev list.

I have opened ESBJAVA-3238 ,
because it seems that the smooks mediator is doing something strange. I
guess, it is something related to ESBJAVA-2977
. The problem is that I can no
longer use it to parse CSV files.

It is someone having a look at it? Will it be fixed with the 1.5 migration
that is suggested for 4.9.0?

Many thanks.

Best regards.

Ramon
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev