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
