Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Tue, Apr 12, 2016 at 11:48 PM, Chamila De Alwis wrote: > Hi, > > To continue the earlier concern to copy all the files inside > `repository/components/lib` folder without specifying their filenames in > the Hiera YAML, I think that would cause problems when multiple

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi, To continue the earlier concern to copy all the files inside `repository/components/lib` folder without specifying their filenames in the Hiera YAML, I think that would cause problems when multiple profiles and platforms are provisioned. For example we don't need Kubernetes Membership Scheme

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Tue, Apr 12, 2016 at 11:01 PM, Imesh Gunaratne wrote: > Looks good! Regarding the "iaas" folder, shall we rename it to default and > remove the files under product/profile/? > +1. I renamed this to `default`. `default` platform will contain all the common data that will be

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi, One more point regarding the file list, I think we can copy all the files > found under repository/components/lib without specifically defining them in > the Hiera file. WDYT? Totally +1, it will make it much easier for the user. Regards, Vishanth On Tue, Apr 12, 2016 at 12:24 PM, Imesh

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi, I think we can copy all the files found under repository/components/lib > without specifically defining them in the Hiera file. WDYT? This is possible if we are not copying any profile specific files. Since we are not copying profile specific files I think we can copy all the files found

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

+1 IMO it is better to proceed with this and later improve it as needed. One more point regarding the file list, I think we can copy all the files found under repository/components/lib without specifically defining them in the Hiera file. WDYT? Thanks On Tue, Apr 12, 2016 at 9:56 AM, Chamila De

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Thanuja, +1, although I'm again concerned with the structural complexity. However when weighed against other options available (having the YAML files in the same folder, enabling deep merge [1], etc) this is the best option as I see. `kubernetes/default.yaml` for WSO2 AM 1.10.0 would look

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 2:06 PM, Chamila De Alwis wrote: > Hi Pubudu, > > That's a good idea, however, we can't exactly map `environment` with the > `platform` concept. How about using a new level on top of the profile > specific level mapping to `platform`? > > :hierarchy: >

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 12:47 PM, Gayan Gunarathne wrote: > > > I think we can make this with with Defined Types[1][2] without creating > duplicate set of YAML files for each platform. We can do the same as the > example given in the document. > > Thanks Gayan! It is not very

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Pubudu, That's a good idea, however, we can't exactly map `environment` with the `platform` concept. How about using a new level on top of the profile specific level mapping to `platform`? :hierarchy: - "node/%{::clientcert}" *-

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Isuru, Without duplicating files and adding new files, I would rather prefer to use the following hierarchy. For each and every different environment we can have product profiles and include the environment specific values. For Kubernetes, we can include the clustering section only in

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 12:47 PM, Gayan Gunarathne wrote: > > > On Mon, Apr 11, 2016 at 12:39 PM, Lakmal Warusawithana > wrote: > >> >> >> On Mon, Apr 11, 2016 at 12:22 PM, Imesh Gunaratne wrote: >> >>> Hi Chamila, >>> >>> On Mon, Apr 11, 2016

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 12:39 PM, Lakmal Warusawithana wrote: > > > On Mon, Apr 11, 2016 at 12:22 PM, Imesh Gunaratne wrote: > >> Hi Chamila, >> >> On Mon, Apr 11, 2016 at 7:19 AM, Chamila De Alwis >> wrote: >> >>> Hi Isuru, Imesh, >>> >>>

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 12:39 PM, Lakmal Warusawithana wrote: > > > On Mon, Apr 11, 2016 at 12:22 PM, Imesh Gunaratne wrote: > >> Hi Chamila, >> >> On Mon, Apr 11, 2016 at 7:19 AM, Chamila De Alwis >> wrote: >> >>> Hi Isuru, Imesh, >>> >>>

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Mon, Apr 11, 2016 at 12:22 PM, Imesh Gunaratne wrote: > Hi Chamila, > > On Mon, Apr 11, 2016 at 7:19 AM, Chamila De Alwis > wrote: > >> Hi Isuru, Imesh, >> >> IMO we shouldn't have any platform specific restructuring in >> wso2/puppet-modules. This should

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Chamila, On Mon, Apr 11, 2016 at 7:19 AM, Chamila De Alwis wrote: > Hi Isuru, Imesh, > > IMO we shouldn't have any platform specific restructuring in > wso2/puppet-modules. This should be done at the end user's setup. Another > point is that we have now decoupled

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Isuru, Imesh, IMO we shouldn't have any platform specific restructuring in wso2/puppet-modules. This should be done at the end user's setup. Another point is that we have now decoupled wso2/puppet-modules from wso2/dockerfiles and users are not required to incorporate puppet-modules in their

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Gayan, On Sun, Apr 10, 2016 at 5:02 PM, Gayan Gunarathne wrote: > IMO this will create maintainability issue. We need to maintain all the > separate hieradata structure for each scenarios.For the one particular > alternation we need to change whole set of files. > In this

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

IMO this will create maintainability issue. We need to maintain all the separate hieradata structure for each scenarios.For the one particular alternation we need to change whole set of files. Why can't we do this by using defined types in Hiera and lookup parameters for a given instance? Based

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Fri, Apr 8, 2016 at 7:48 PM, Isuru Haththotuwa wrote: > > > hieradata > |--- dev >|--- wso2 >| > |--- >|-- *vm* >

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Fri, Apr 8, 2016 at 7:48 PM, Isuru Haththotuwa wrote: > > > On Fri, Apr 8, 2016 at 5:12 PM, Imesh Gunaratne wrote: > >> Hi Devs, >> >> IMO we need to handle $subject without affecting other deployments. At >> the moment we have updated default.yaml with K8S

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Fri, Apr 8, 2016 at 7:48 PM, Isuru Haththotuwa wrote: > > > On Fri, Apr 8, 2016 at 5:12 PM, Imesh Gunaratne wrote: > >> Hi Devs, >> >> IMO we need to handle $subject without affecting other deployments. At >> the moment we have updated default.yaml with K8S

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

On Fri, Apr 8, 2016 at 5:12 PM, Imesh Gunaratne wrote: > Hi Devs, > > IMO we need to handle $subject without affecting other deployments. At the > moment we have updated default.yaml with K8S specific configurations and > manager and worker yaml files also have clustering

[Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Devs, IMO we need to handle $subject without affecting other deployments. At the moment we have updated default.yaml with K8S specific configurations and manager and worker yaml files also have clustering configurations enabled for K8S. Thanks -- *Imesh Gunaratne* Senior Technical Lead WSO2