Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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 < raviha...@wso2.com> wrote: > Hi Chamila, > > Agre
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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}" - "wso2/%{::product_name}/%{::product_version}/%{::platform}/%{::product_profile}" - "w
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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}" >>> >>> >>> Thanks. >>> >>> >>> On Mon, May 9, 2016 at 11:31 AM, Ch
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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 deployed. With this addition I feel there is no reason to keep - "vm_typ
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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 related dependency jars for all the products. >>> Also we >>> need t
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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: >> - "node/%{::clientcert}" >> - >> "wso2/%{::product_na
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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 > WSO2 Inc.; http://wso2.com/ > > Blog: http://ravihans
Re: [Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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
+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
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
+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
[Dev] [Puppet] [Hiera] Introducing a hierarchy for platform specific common configuration
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