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 <chami...@wso2.com> 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 <chami...@wso2.com> >> 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 <chami...@wso2.com> >>>> 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 >> > > -- 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