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 <lak...@wso2.com>
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 <lak...@wso2.com>
>> 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 <chami...@wso2.com>
>>> 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 <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
>>>>
>>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.; http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> Lakmal Warusawithana
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.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
