Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

You do not have to add config data for each hierarchy. If you want to use
without any platform configuration then you can set the "platform" facter
variable to "default".

On Tue, May 10, 2016 at 9:54 AM, Lakmal Warusawithana 
wrote:

> Say platform k8s , we need to have vm_type right? I want to use vm_type
> docker , but without any platform configuration. How can I do that?
>
> On Tue, May 10, 2016 at 9:51 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Lakmal,
>>
>> Hierarchy will be the same (hiera.yaml). You need to set docker-compose
>> specific configuration in "vm_type/docker-compose.yaml" file. This is for
>> when building the image. Puppet cannot handle run time configuration in
>> container scenario. If there is no platform (Mesos, K8s etc.) involved then
>> no need to create platform specific yaml files.
>>
>> I think hiera.yaml should be abstract and flexible enough that a user
>> should be able to deploy WSO2 products/services on any platform or
>> container/VM type without changing it. Of course there can be custom
>> requirements. But this should suffice for most cases.
>>
>> Thanks.
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
>> wrote:
>>
>>> Say I want to use in docker-compose (with pure docker). What hiera files
>>> (config) I have to use?
>>>
>>> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
>>> wrote:
>>>
 I agree. Let's keep vm_type for simplicity.


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi Chamila,
>
> Docker is not really a platform if you look at the semantics. If we
> create another YAML for docker under platform hierarchy then we have to
> duplicate every platform specific YAML files under product hierarchy. I
> don't think it's a good option for us.
>
> Thanks.
>
> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
> wrote:
>
>> Hi Akila,
>>
>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>> sure about Rocket, however if there are no considerable data duplication
>> between Docker and a possible Rocket configuration data set, IMO we 
>> should
>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> It seems "vm_type" hierarchy should exist to build Docker images
>>> (provisioned via Puppet) and then run on bare Docker. Because when 
>>> building
>>> the images for default platform (which is the option for bare Docker),
>>> there should be a separate hierarchy to set the installation_dir 
>>> parameter
>>> to "/mnt".
>>>
>>> I think it makes sense to have a separate hierarchy to control the
>>> configuration data for containers or VMs since that is one layer below 
>>> the
>>> platform level in a deployment infrastructure. For eg: we can have a
>>> Kubernetes platform with Docker as the container technology OR it could 
>>> be
>>> even Rocket. Inside this whatever vm_type we can have any base operating
>>> system running. So I've refined the hierarchy as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "osfamily/%{::osfamily}"
>>> - "vm_type/%{::vm_type}"
>>> - "platform/%{::platform}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>> Since "wso2/common" and "common" are static hierarchies, those
>>> should be moved to the bottom. Please raise any concerns you may have 
>>> with
>>> this hierarchy.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis >> > wrote:
>>>
 +1, IMO that's better since now it's clear how what kubernetes.yaml
 stands for.


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Lakmal Warusawithana]

Say platform k8s , we need to have vm_type right? I want to use vm_type
docker , but without any platform configuration. How can I do that?

On Tue, May 10, 2016 at 9:51 AM, Akila Ravihansa Perera 
wrote:

> Hi Lakmal,
>
> Hierarchy will be the same (hiera.yaml). You need to set docker-compose
> specific configuration in "vm_type/docker-compose.yaml" file. This is for
> when building the image. Puppet cannot handle run time configuration in
> container scenario. If there is no platform (Mesos, K8s etc.) involved then
> no need to create platform specific yaml files.
>
> I think hiera.yaml should be abstract and flexible enough that a user
> should be able to deploy WSO2 products/services on any platform or
> container/VM type without changing it. Of course there can be custom
> requirements. But this should suffice for most cases.
>
> Thanks.
>
> Thanks.
>
> On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
> wrote:
>
>> Say I want to use in docker-compose (with pure docker). What hiera files
>> (config) I have to use?
>>
>> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
>> wrote:
>>
>>> I agree. Let's keep vm_type for simplicity.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Docker is not really a platform if you look at the semantics. If we
 create another YAML for docker under platform hierarchy then we have to
 duplicate every platform specific YAML files under product hierarchy. I
 don't think it's a good option for us.

 Thanks.

 On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
 wrote:

> Hi Akila,
>
> Why don't we use Docker as a platform rather than a vm_type? I'm not
> sure about Rocket, however if there are no considerable data duplication
> between Docker and a possible Rocket configuration data set, IMO we should
> keep the hierarchy simple and include Docker as a platform. WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> It seems "vm_type" hierarchy should exist to build Docker images
>> (provisioned via Puppet) and then run on bare Docker. Because when 
>> building
>> the images for default platform (which is the option for bare Docker),
>> there should be a separate hierarchy to set the installation_dir 
>> parameter
>> to "/mnt".
>>
>> I think it makes sense to have a separate hierarchy to control the
>> configuration data for containers or VMs since that is one layer below 
>> the
>> platform level in a deployment infrastructure. For eg: we can have a
>> Kubernetes platform with Docker as the container technology OR it could 
>> be
>> even Rocket. Inside this whatever vm_type we can have any base operating
>> system running. So I've refined the hierarchy as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "osfamily/%{::osfamily}"
>> - "vm_type/%{::vm_type}"
>> - "platform/%{::platform}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>> Since "wso2/common" and "common" are static hierarchies, those should
>> be moved to the bottom. Please raise any concerns you may have with this
>> hierarchy.
>>
>> Thanks.
>>
>>
>>
>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>> wrote:
>>
>>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>>> stands for.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Agreed. I don't think there would be anymore files in addition to
 common.yaml here. How about moving this to root level; for eg:
 "platform/kubernetes.yaml" ?

 Full Hierarchy will be as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Lakmal,

Hierarchy will be the same (hiera.yaml). You need to set docker-compose
specific configuration in "vm_type/docker-compose.yaml" file. This is for
when building the image. Puppet cannot handle run time configuration in
container scenario. If there is no platform (Mesos, K8s etc.) involved then
no need to create platform specific yaml files.

I think hiera.yaml should be abstract and flexible enough that a user
should be able to deploy WSO2 products/services on any platform or
container/VM type without changing it. Of course there can be custom
requirements. But this should suffice for most cases.

Thanks.

Thanks.

On Tue, May 10, 2016 at 9:45 AM, Lakmal Warusawithana 
wrote:

> Say I want to use in docker-compose (with pure docker). What hiera files
> (config) I have to use?
>
> On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis 
> wrote:
>
>> I agree. Let's keep vm_type for simplicity.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Docker is not really a platform if you look at the semantics. If we
>>> create another YAML for docker under platform hierarchy then we have to
>>> duplicate every platform specific YAML files under product hierarchy. I
>>> don't think it's a good option for us.
>>>
>>> Thanks.
>>>
>>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
>>> wrote:
>>>
 Hi Akila,

 Why don't we use Docker as a platform rather than a vm_type? I'm not
 sure about Rocket, however if there are no considerable data duplication
 between Docker and a possible Rocket configuration data set, IMO we should
 keep the hierarchy simple and include Docker as a platform. WDYT?


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi,
>
> It seems "vm_type" hierarchy should exist to build Docker images
> (provisioned via Puppet) and then run on bare Docker. Because when 
> building
> the images for default platform (which is the option for bare Docker),
> there should be a separate hierarchy to set the installation_dir parameter
> to "/mnt".
>
> I think it makes sense to have a separate hierarchy to control the
> configuration data for containers or VMs since that is one layer below the
> platform level in a deployment infrastructure. For eg: we can have a
> Kubernetes platform with Docker as the container technology OR it could be
> even Rocket. Inside this whatever vm_type we can have any base operating
> system running. So I've refined the hierarchy as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "osfamily/%{::osfamily}"
> - "vm_type/%{::vm_type}"
> - "platform/%{::platform}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
> Since "wso2/common" and "common" are static hierarchies, those should
> be moved to the bottom. Please raise any concerns you may have with this
> hierarchy.
>
> Thanks.
>
>
>
> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
> wrote:
>
>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>> stands for.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Agreed. I don't think there would be anymore files in addition to
>>> common.yaml here. How about moving this to root level; for eg:
>>> "platform/kubernetes.yaml" ?
>>>
>>> Full Hierarchy will be as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "platform/%{::platform}"
>>> - "osfamily/%{::osfamily}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Lakmal Warusawithana]

Say I want to use in docker-compose (with pure docker). What hiera files
(config) I have to use?

On Tue, May 10, 2016 at 6:18 AM, Chamila De Alwis  wrote:

> I agree. Let's keep vm_type for simplicity.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Docker is not really a platform if you look at the semantics. If we
>> create another YAML for docker under platform hierarchy then we have to
>> duplicate every platform specific YAML files under product hierarchy. I
>> don't think it's a good option for us.
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
>> wrote:
>>
>>> Hi Akila,
>>>
>>> Why don't we use Docker as a platform rather than a vm_type? I'm not
>>> sure about Rocket, however if there are no considerable data duplication
>>> between Docker and a possible Rocket configuration data set, IMO we should
>>> keep the hierarchy simple and include Docker as a platform. WDYT?
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 It seems "vm_type" hierarchy should exist to build Docker images
 (provisioned via Puppet) and then run on bare Docker. Because when building
 the images for default platform (which is the option for bare Docker),
 there should be a separate hierarchy to set the installation_dir parameter
 to "/mnt".

 I think it makes sense to have a separate hierarchy to control the
 configuration data for containers or VMs since that is one layer below the
 platform level in a deployment infrastructure. For eg: we can have a
 Kubernetes platform with Docker as the container technology OR it could be
 even Rocket. Inside this whatever vm_type we can have any base operating
 system running. So I've refined the hierarchy as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "osfamily/%{::osfamily}"
 - "vm_type/%{::vm_type}"
 - "platform/%{::platform}"
 - wso2/common
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"

 Since "wso2/common" and "common" are static hierarchies, those should
 be moved to the bottom. Please raise any concerns you may have with this
 hierarchy.

 Thanks.



 On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
 wrote:

> +1, IMO that's better since now it's clear how what kubernetes.yaml
> stands for.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Agreed. I don't think there would be anymore files in addition to
>> common.yaml here. How about moving this to root level; for eg:
>> "platform/kubernetes.yaml" ?
>>
>> Full Hierarchy will be as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "platform/%{::platform}"
>> - "osfamily/%{::osfamily}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Thanks.
>>
>>
>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>> wrote:
>>
>>> +1
>>>
>>> How about wso2/kubernetes.yaml instead of
>>> wso2/kubernetes/common.yaml? Will there be a YAML file in addition to 
>>> the
>>> common.yaml?
>>>
>>> - "wso2/%{::platform}"
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 We recently introduced a facter named "platform" to denote a PaaS
 framework or cluster management system on which WSO2 products could be
 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

I agree. Let's keep vm_type for simplicity.


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Tue, May 10, 2016 at 6:15 AM, Akila Ravihansa Perera 
wrote:

> Hi Chamila,
>
> Docker is not really a platform if you look at the semantics. If we create
> another YAML for docker under platform hierarchy then we have to duplicate
> every platform specific YAML files under product hierarchy. I don't think
> it's a good option for us.
>
> Thanks.
>
> On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis 
> wrote:
>
>> Hi Akila,
>>
>> Why don't we use Docker as a platform rather than a vm_type? I'm not sure
>> about Rocket, however if there are no considerable data duplication between
>> Docker and a possible Rocket configuration data set, IMO we should keep the
>> hierarchy simple and include Docker as a platform. WDYT?
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> It seems "vm_type" hierarchy should exist to build Docker images
>>> (provisioned via Puppet) and then run on bare Docker. Because when building
>>> the images for default platform (which is the option for bare Docker),
>>> there should be a separate hierarchy to set the installation_dir parameter
>>> to "/mnt".
>>>
>>> I think it makes sense to have a separate hierarchy to control the
>>> configuration data for containers or VMs since that is one layer below the
>>> platform level in a deployment infrastructure. For eg: we can have a
>>> Kubernetes platform with Docker as the container technology OR it could be
>>> even Rocket. Inside this whatever vm_type we can have any base operating
>>> system running. So I've refined the hierarchy as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "osfamily/%{::osfamily}"
>>> - "vm_type/%{::vm_type}"
>>> - "platform/%{::platform}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>> Since "wso2/common" and "common" are static hierarchies, those should be
>>> moved to the bottom. Please raise any concerns you may have with this
>>> hierarchy.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>>> wrote:
>>>
 +1, IMO that's better since now it's clear how what kubernetes.yaml
 stands for.


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi Chamila,
>
> Agreed. I don't think there would be anymore files in addition to
> common.yaml here. How about moving this to root level; for eg:
> "platform/kubernetes.yaml" ?
>
> Full Hierarchy will be as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "platform/%{::platform}"
> - "osfamily/%{::osfamily}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Thanks.
>
>
> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
> wrote:
>
>> +1
>>
>> How about wso2/kubernetes.yaml instead of
>> wso2/kubernetes/common.yaml? Will there be a YAML file in addition to the
>> common.yaml?
>>
>> - "wso2/%{::platform}"
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> We recently introduced a facter named "platform" to denote a PaaS
>>> framework or cluster management system on which WSO2 products could be
>>> deployed. With this addition I feel there is no reason to keep -
>>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>>> configuration parameters that is common across all the products for a
>>> specific platform.
>>>
>>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>>> membership scheme and 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Chamila,

Docker is not really a platform if you look at the semantics. If we create
another YAML for docker under platform hierarchy then we have to duplicate
every platform specific YAML files under product hierarchy. I don't think
it's a good option for us.

Thanks.

On Tue, May 10, 2016 at 6:10 AM, Chamila De Alwis  wrote:

> Hi Akila,
>
> Why don't we use Docker as a platform rather than a vm_type? I'm not sure
> about Rocket, however if there are no considerable data duplication between
> Docker and a possible Rocket configuration data set, IMO we should keep the
> hierarchy simple and include Docker as a platform. WDYT?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> It seems "vm_type" hierarchy should exist to build Docker images
>> (provisioned via Puppet) and then run on bare Docker. Because when building
>> the images for default platform (which is the option for bare Docker),
>> there should be a separate hierarchy to set the installation_dir parameter
>> to "/mnt".
>>
>> I think it makes sense to have a separate hierarchy to control the
>> configuration data for containers or VMs since that is one layer below the
>> platform level in a deployment infrastructure. For eg: we can have a
>> Kubernetes platform with Docker as the container technology OR it could be
>> even Rocket. Inside this whatever vm_type we can have any base operating
>> system running. So I've refined the hierarchy as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "osfamily/%{::osfamily}"
>> - "vm_type/%{::vm_type}"
>> - "platform/%{::platform}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>> Since "wso2/common" and "common" are static hierarchies, those should be
>> moved to the bottom. Please raise any concerns you may have with this
>> hierarchy.
>>
>> Thanks.
>>
>>
>>
>> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
>> wrote:
>>
>>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>>> stands for.
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi Chamila,

 Agreed. I don't think there would be anymore files in addition to
 common.yaml here. How about moving this to root level; for eg:
 "platform/kubernetes.yaml" ?

 Full Hierarchy will be as follows;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "platform/%{::platform}"
 - "osfamily/%{::osfamily}"
 - wso2/common
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"


 Thanks.


 On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
 wrote:

> +1
>
> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
> Will there be a YAML file in addition to the common.yaml?
>
> - "wso2/%{::platform}"
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> We recently introduced a facter named "platform" to denote a PaaS
>> framework or cluster management system on which WSO2 products could be
>> deployed. With this addition I feel there is no reason to keep -
>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>> configuration parameters that is common across all the products for a
>> specific platform.
>>
>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>> membership scheme and related dependency jars for all the products. Also 
>> we
>> need to set the installation dir to "/mnt" (instead of 
>> "/mnt/%{ipaddress}"
>> because ipaddress is not available at the image build time.
>>
>> Therefore I'd like to propose that we include the
>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look 
>> like
>> this;
>>
>> :hierarchy:
>> - 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

Hi Akila,

Why don't we use Docker as a platform rather than a vm_type? I'm not sure
about Rocket, however if there are no considerable data duplication between
Docker and a possible Rocket configuration data set, IMO we should keep the
hierarchy simple and include Docker as a platform. WDYT?


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Tue, May 10, 2016 at 5:57 AM, Akila Ravihansa Perera 
wrote:

> Hi,
>
> It seems "vm_type" hierarchy should exist to build Docker images
> (provisioned via Puppet) and then run on bare Docker. Because when building
> the images for default platform (which is the option for bare Docker),
> there should be a separate hierarchy to set the installation_dir parameter
> to "/mnt".
>
> I think it makes sense to have a separate hierarchy to control the
> configuration data for containers or VMs since that is one layer below the
> platform level in a deployment infrastructure. For eg: we can have a
> Kubernetes platform with Docker as the container technology OR it could be
> even Rocket. Inside this whatever vm_type we can have any base operating
> system running. So I've refined the hierarchy as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "osfamily/%{::osfamily}"
> - "vm_type/%{::vm_type}"
> - "platform/%{::platform}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
> Since "wso2/common" and "common" are static hierarchies, those should be
> moved to the bottom. Please raise any concerns you may have with this
> hierarchy.
>
> Thanks.
>
>
>
> On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis 
> wrote:
>
>> +1, IMO that's better since now it's clear how what kubernetes.yaml
>> stands for.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Chamila,
>>>
>>> Agreed. I don't think there would be anymore files in addition to
>>> common.yaml here. How about moving this to root level; for eg:
>>> "platform/kubernetes.yaml" ?
>>>
>>> Full Hierarchy will be as follows;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "platform/%{::platform}"
>>> - "osfamily/%{::osfamily}"
>>> - wso2/common
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>>> wrote:
>>>
 +1

 How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
 Will there be a YAML file in addition to the common.yaml?

 - "wso2/%{::platform}"


 Regards,
 Chamila de Alwis
 Committer and PMC Member - Apache Stratos
 Software Engineer | WSO2 | +94772207163
 Blog: code.chamiladealwis.com



 On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
 raviha...@wso2.com> wrote:

> Hi,
>
> We recently introduced a facter named "platform" to denote a PaaS
> framework or cluster management system on which WSO2 products could be
> deployed. With this addition I feel there is no reason to keep -
> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
> configuration parameters that is common across all the products for a
> specific platform.
>
> For eg: In Kubernetes platform, we need to copy the Kubernetes
> membership scheme and related dependency jars for all the products. Also 
> we
> need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
> because ipaddress is not available at the image build time.
>
> Therefore I'd like to propose that we include the
> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look 
> like
> this;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "wso2/%{::platform}/common"
> - wso2/common
> - "osfamily/%{::osfamily}"
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Any thoughts?
>
> Thanks.
>
> --
> Akila Ravihansa Perera
> 

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi,

It seems "vm_type" hierarchy should exist to build Docker images
(provisioned via Puppet) and then run on bare Docker. Because when building
the images for default platform (which is the option for bare Docker),
there should be a separate hierarchy to set the installation_dir parameter
to "/mnt".

I think it makes sense to have a separate hierarchy to control the
configuration data for containers or VMs since that is one layer below the
platform level in a deployment infrastructure. For eg: we can have a
Kubernetes platform with Docker as the container technology OR it could be
even Rocket. Inside this whatever vm_type we can have any base operating
system running. So I've refined the hierarchy as follows;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "osfamily/%{::osfamily}"
- "vm_type/%{::vm_type}"
- "platform/%{::platform}"
- wso2/common
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"

Since "wso2/common" and "common" are static hierarchies, those should be
moved to the bottom. Please raise any concerns you may have with this
hierarchy.

Thanks.



On Mon, May 9, 2016 at 12:48 PM, Chamila De Alwis  wrote:

> +1, IMO that's better since now it's clear how what kubernetes.yaml stands
> for.
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Chamila,
>>
>> Agreed. I don't think there would be anymore files in addition to
>> common.yaml here. How about moving this to root level; for eg:
>> "platform/kubernetes.yaml" ?
>>
>> Full Hierarchy will be as follows;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "platform/%{::platform}"
>> - "osfamily/%{::osfamily}"
>> - wso2/common
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Thanks.
>>
>>
>> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
>> wrote:
>>
>>> +1
>>>
>>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>>> Will there be a YAML file in addition to the common.yaml?
>>>
>>> - "wso2/%{::platform}"
>>>
>>>
>>> Regards,
>>> Chamila de Alwis
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer | WSO2 | +94772207163
>>> Blog: code.chamiladealwis.com
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
 Hi,

 We recently introduced a facter named "platform" to denote a PaaS
 framework or cluster management system on which WSO2 products could be
 deployed. With this addition I feel there is no reason to keep -
 "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
 configuration parameters that is common across all the products for a
 specific platform.

 For eg: In Kubernetes platform, we need to copy the Kubernetes
 membership scheme and related dependency jars for all the products. Also we
 need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
 because ipaddress is not available at the image build time.

 Therefore I'd like to propose that we include the
 "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
 this;

 :hierarchy:
 - "node/%{::clientcert}"
 - 
 "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
 - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
 - "wso2/%{::platform}/common"
 - wso2/common
 - "osfamily/%{::osfamily}"
 - common
 :backends:
 - yaml
 :yaml:
 :datadir: "hieradata/%{::environment}"


 Any thoughts?

 Thanks.

 --
 Akila Ravihansa Perera
 WSO2 Inc.;  http://wso2.com/

 Blog: http://ravihansa3000.blogspot.com

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


>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>


-- 
Akila Ravihansa Perera
WSO2 Inc.;  http://wso2.com/

Blog: http://ravihansa3000.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

+1, IMO that's better since now it's clear how what kubernetes.yaml stands
for.


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Mon, May 9, 2016 at 12:21 PM, Akila Ravihansa Perera 
wrote:

> Hi Chamila,
>
> Agreed. I don't think there would be anymore files in addition to
> common.yaml here. How about moving this to root level; for eg:
> "platform/kubernetes.yaml" ?
>
> Full Hierarchy will be as follows;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "platform/%{::platform}"
> - "osfamily/%{::osfamily}"
> - wso2/common
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Thanks.
>
>
> On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis 
> wrote:
>
>> +1
>>
>> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
>> Will there be a YAML file in addition to the common.yaml?
>>
>> - "wso2/%{::platform}"
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> We recently introduced a facter named "platform" to denote a PaaS
>>> framework or cluster management system on which WSO2 products could be
>>> deployed. With this addition I feel there is no reason to keep -
>>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>>> configuration parameters that is common across all the products for a
>>> specific platform.
>>>
>>> For eg: In Kubernetes platform, we need to copy the Kubernetes
>>> membership scheme and related dependency jars for all the products. Also we
>>> need to set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}"
>>> because ipaddress is not available at the image build time.
>>>
>>> Therefore I'd like to propose that we include the
>>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
>>> this;
>>>
>>> :hierarchy:
>>> - "node/%{::clientcert}"
>>> - 
>>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>>> - "wso2/%{::platform}/common"
>>> - wso2/common
>>> - "osfamily/%{::osfamily}"
>>> - common
>>> :backends:
>>> - yaml
>>> :yaml:
>>> :datadir: "hieradata/%{::environment}"
>>>
>>>
>>> Any thoughts?
>>>
>>> Thanks.
>>>
>>> --
>>> Akila Ravihansa Perera
>>> WSO2 Inc.;  http://wso2.com/
>>>
>>> Blog: http://ravihansa3000.blogspot.com
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>
>
> --
> Akila Ravihansa Perera
> WSO2 Inc.;  http://wso2.com/
>
> Blog: http://ravihansa3000.blogspot.com
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Akila Ravihansa Perera]

Hi Chamila,

Agreed. I don't think there would be anymore files in addition to
common.yaml here. How about moving this to root level; for eg:
"platform/kubernetes.yaml" ?

Full Hierarchy will be as follows;

:hierarchy:
- "node/%{::clientcert}"
- 
"wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
- "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
- "platform/%{::platform}"
- "osfamily/%{::osfamily}"
- wso2/common
- common
:backends:
- yaml
:yaml:
:datadir: "hieradata/%{::environment}"


Thanks.


On Mon, May 9, 2016 at 11:31 AM, Chamila De Alwis  wrote:

> +1
>
> How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml?
> Will there be a YAML file in addition to the common.yaml?
>
> - "wso2/%{::platform}"
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> We recently introduced a facter named "platform" to denote a PaaS
>> framework or cluster management system on which WSO2 products could be
>> deployed. With this addition I feel there is no reason to keep -
>> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
>> configuration parameters that is common across all the products for a
>> specific platform.
>>
>> For eg: In Kubernetes platform, we need to copy the Kubernetes membership
>> scheme and related dependency jars for all the products. Also we need to
>> set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}" because
>> ipaddress is not available at the image build time.
>>
>> Therefore I'd like to propose that we include the
>> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
>> this;
>>
>> :hierarchy:
>> - "node/%{::clientcert}"
>> - 
>> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
>> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
>> - "wso2/%{::platform}/common"
>> - wso2/common
>> - "osfamily/%{::osfamily}"
>> - common
>> :backends:
>> - yaml
>> :yaml:
>> :datadir: "hieradata/%{::environment}"
>>
>>
>> Any thoughts?
>>
>> Thanks.
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.;  http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
Akila Ravihansa Perera
WSO2 Inc.;  http://wso2.com/

Blog: http://ravihansa3000.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration

[Chamila De Alwis]

+1

How about wso2/kubernetes.yaml instead of wso2/kubernetes/common.yaml? Will
there be a YAML file in addition to the common.yaml?

- "wso2/%{::platform}"


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Mon, May 9, 2016 at 10:32 AM, Akila Ravihansa Perera 
wrote:

> Hi,
>
> We recently introduced a facter named "platform" to denote a PaaS
> framework or cluster management system on which WSO2 products could be
> deployed. With this addition I feel there is no reason to keep -
> "vm_type/%{::vm_type}" hierarchy. Also we need to way to introduce
> configuration parameters that is common across all the products for a
> specific platform.
>
> For eg: In Kubernetes platform, we need to copy the Kubernetes membership
> scheme and related dependency jars for all the products. Also we need to
> set the installation dir to "/mnt" (instead of "/mnt/%{ipaddress}" because
> ipaddress is not available at the image build time.
>
> Therefore I'd like to propose that we include the
> "wso2/%{platform}/common" to the hierarchy. Full hiera.yaml would look like
> this;
>
> :hierarchy:
> - "node/%{::clientcert}"
> - 
> "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}"
> - "wso2/%{::product_name}/%{::product_version}/%{::platform}/default"
> - "wso2/%{::platform}/common"
> - wso2/common
> - "osfamily/%{::osfamily}"
> - common
> :backends:
> - yaml
> :yaml:
> :datadir: "hieradata/%{::environment}"
>
>
> Any thoughts?
>
> Thanks.
>
> --
> Akila Ravihansa Perera
> WSO2 Inc.;  http://wso2.com/
>
> Blog: http://ravihansa3000.blogspot.com
>
> ___
> 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