IMO, we shouldn't replicate config files in stratos-installer. I agree
with Lahiru's suggestion. We can keep the XML files in product modules
and write to those files by looking up XML tags. We need to get rid of
those place holders.
On Wed, Aug 20, 2014 at 12:07 PM, Sajith Kariyawasam wrote:
>
>
On Wed, Aug 20, 2014 at 12:01 PM, Sajith Kariyawasam
wrote:
> How about if we keep the config files inside product distribution, and we
> write a script in stratos-installer to copy / replace config files from
> original location (product distribution) to stratos-installer 's config
> directory?
How about if we keep the config files inside product distribution, and we
write a script in stratos-installer to copy / replace config files from
original location (product distribution) to stratos-installer 's config
directory?
On Wed, Aug 20, 2014 at 11:46 AM, Nirmal Fernando
wrote:
> I think
If one set has placeholders then they are ideally not duplicates right ?
For exact duplicates would having a git post-commit hook be a solution ?
On Wed, Aug 20, 2014 at 11:46 AM, Nirmal Fernando
wrote:
> I think we have to maintain it in two places otherwise if the file isn't
> there in the p
I put a page on the wiki a while back:
https://cwiki.apache.org/confluence/display/STRATOS/Committers+%3A+Applying+github+pull+requests
On 20 Aug 2014 06:22, "Akila Ravihansa Perera" wrote:
> Hi Udara,
>
> You cannot merge directly to Github repo since that's only a mirror of
> Apache git repo.
I think we have to maintain it in two places otherwise if the file isn't
there in the product distribution, product would fail to start and also
since we're using place holders in the config files inside the installer,
some of those could cause failures when parsing the XML.
On Wed, Aug 20, 2014
Furthermore Prasanna and I are in the process of writing chef scripts for a
few the cartridges. We will for the time being go with the current
structure of keeping the templates on the agent module, as the proposed
changes would not be implemented within our deadlines. But it should be
noted down t
On Wed, Aug 20, 2014 at 11:00 AM, Gayan Gunarathne wrote:
> Do we recommend to use the Stratos product build itself without using the
> Stratos installer?
>
yes. If we configure and start stratos manually, that process will not use
configuration files which are inside stratos installer.
>
>
If w
On Wed, Aug 20, 2014 at 11:24 AM, Sajith Kariyawasam
wrote:
> Nirmal, I'm bit unclear, in Virtual Machine scenario, the partitioning
> according to you is based on Availability Zone. Does that mean partitioning
> can "only" be based on AZ's? But according to our docs [1] we can have
> provider
Nirmal, I'm bit unclear, in Virtual Machine scenario, the partitioning
according to you is based on Availability Zone. Does that mean partitioning
can "only" be based on AZ's? But according to our docs [1] we can have
provider level, region level, zone level or rack level. So my understanding
is
[
https://issues.apache.org/jira/browse/STRATOS-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103425#comment-14103425
]
ASF GitHub Bot commented on STRATOS-598:
Github user asfgit closed the pull reque
On Wed, Aug 20, 2014 at 11:00 AM, Gayan Gunarathne wrote:
> Do we recommend to use the Stratos product build itself without using the
> Stratos installer?
>
Yes, Gayan, we do.
>
> If we recommed to use the Stratos installer every time,IMO we can maintain
> the config in separately in stratus in
Do we recommend to use the Stratos product build itself without using the
Stratos installer?
If we recommed to use the Stratos installer every time,IMO we can maintain
the config in separately in stratus installer and in setup time we can add
them appropriately.
Thanks,
Gayan
On Wed, Aug 20, 20
Hi Udara,
You cannot merge directly to Github repo since that's only a mirror of
Apache git repo.
However, you can still merge them by fetching from GitHub PR and then
pushing it to Apache git repo. Please refer to the 'merge GitHub PR'
thread that was initiated by Chris sometime back.
Thanks.
O
Hi,
Do I have permission to merge PR. I don't see merge option.
On Wed, Aug 20, 2014 at 10:11 AM, Udara Liyanage wrote:
> Hi,
>
> I'm in support currently, but will have a look as time permits
>
>
> On Wed, Aug 20, 2014 at 9:55 AM, Nirmal Fernando
> wrote:
>
>> Hi Stratos Committers,
>>
>> We
On Wed, Aug 20, 2014 at 10:34 AM, Udara Liyanage wrote:
> Hi,
>
> We have duplicates some product configurations files, one inside product
> and one in stratos-installer. At the boot time (when setup.sh is executed)
> config files inside products will be replaced by the config files inside
> stra
Hi,
We have duplicates some product configurations files, one inside product
and one in stratos-installer. At the boot time (when setup.sh is executed)
config files inside products will be replaced by the config files inside
stratos-installer.
Maintaining duplicate config files become an overhead
Hi,
I'm in support currently, but will have a look as time permits
On Wed, Aug 20, 2014 at 9:55 AM, Nirmal Fernando
wrote:
> Hi Stratos Committers,
>
> We have 6 PRs on the queue. Anyone available for reviewing and merging
> them?
>
> https://github.com/apache/stratos/pulls
>
> --
> Best Regar
Hi Stratos Committers,
We have 6 PRs on the queue. Anyone available for reviewing and merging
them?
https://github.com/apache/stratos/pulls
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.c
Thanks Nirmal, Sajith & Akila for the productive hangout yesterday. Please
update the design to wiki.
Cheers,
--Tuna
On Tue, Aug 19, 2014 at 11:04 AM, Nirmal Fernando
wrote:
> Current DockerIaas implementation uses default Jclouds TemplateOptions
> class. But in order to get all the available
On Wed, Aug 20, 2014 at 7:25 AM, Nirmal Fernando
wrote:
> Hi Lahiru,
>
>
> On Tue, Aug 19, 2014 at 9:02 PM, Lahiru Sandaruwan
> wrote:
>
>> mm.. Then why a sub-partition?
>>
>
> Since Autoscaler should spawn both host machines + docker instances inside
> host machines.
>
Basically, what we need
Hi Lahiru,
On Tue, Aug 19, 2014 at 9:02 PM, Lahiru Sandaruwan wrote:
> mm.. Then why a sub-partition?
>
Since Autoscaler should spawn both host machines + docker instances inside
host machines.
> May be i should wait on the other thread you start.
>
Yes, please.. I am still researching :-)
On Wed, Aug 20, 2014 at 6:52 AM, Nirmal Fernando
wrote:
>
>
>
> On Wed, Aug 20, 2014 at 3:45 AM, Imesh Gunaratne wrote:
>
>> If we group a Docker/Core OS host as a partition, if the host goes down
>> the entire partition will be unavailable.
>>
>
Hi Imesh, this is the same behavior we see for an
Also, please read Findings on CoreOS thread for a summarized set of
information on CoreOS.
On Wed, Aug 20, 2014 at 6:52 AM, Nirmal Fernando
wrote:
>
>
>
> On Wed, Aug 20, 2014 at 3:45 AM, Imesh Gunaratne wrote:
>
>> If we group a Docker/Core OS host as a partition, if the host goes down
>> the
On Wed, Aug 20, 2014 at 3:45 AM, Imesh Gunaratne wrote:
> If we group a Docker/Core OS host as a partition, if the host goes down
> the entire partition will be unavailable.
>
> Core OS uses a similar concept in clustering to avoid this problem:
> https://coreos.com/using-coreos/clustering/
>
Ye
[
https://issues.apache.org/jira/browse/STRATOS-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nirmal Fernando updated STRATOS-757:
Attachment: 0001-added-cartridge-agent-plugin-support.patch
Attaching the patch provided b
Nirmal Fernando created STRATOS-757:
---
Summary: Cartridge Agent Health Stats Plugin
Key: STRATOS-757
URL: https://issues.apache.org/jira/browse/STRATOS-757
Project: Stratos
Issue Type: Bug
I've created a Jira to track this
https://issues.apache.org/jira/browse/STRATOS-757
On Wed, Jul 9, 2014 at 8:11 PM, Michael Hall (michaha2)
wrote:
> Hi,
>
> We want to upstream support for cartridge agent health statistics
> plugins.
>
> The attached patch (for 4.0.0) doesn’t change the cart
Hi Imesh,
On Wed, Aug 20, 2014 at 3:45 AM, Imesh Gunaratne wrote:
> If we group a Docker/Core OS host as a partition, if the host goes down
> the entire partition will be unavailable.
>
+1, [1] reveals a bit about Amazon definition. I think we can define the
zones and regions based on network l
If we group a Docker/Core OS host as a partition, if the host goes down the
entire partition will be unavailable.
Core OS uses a similar concept in clustering to avoid this problem:
https://coreos.com/using-coreos/clustering/
Will us be able to span a partition among multiple hosts?
On Tue, Aug
Great!
This seems to be the best way of improving the module structure with regard
to agent module. +1
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Tue, Aug 19, 2014 at 8:01 PM, Rajkumar Rajaratnam
wrote:
> Hi Chamila,
>
> To load custo
mm.. Then why a sub-partition? May be i should wait on the other thread you
start.
On Tue, Aug 19, 2014 at 12:43 AM, Nirmal Fernando
wrote:
>
>
>
> On Tue, Aug 19, 2014 at 12:50 PM, Lahiru Sandaruwan
> wrote:
>
>> Hi Nirmal,
>>
>>
>> On Mon, Aug 18, 2014 at 11:42 PM, Nirmal Fernando > > wrote:
hello i didnt find this log im using EC2 with docker and stratos then i
create an image with centos and configure the puppet agent following this
tutorial
https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Creating+a+Cartridge+on+EC2#id-4.0.0CreatingaCartridgeonEC2-Step2-Configuringthecartr
Hi Chamila,
To load custom templates (from a cartridge module),
*content => template("${module}/agent/${name}.erb")*
We will be creating a directory (agent) inside a cartridge module's
templates directory (puppet/modules/ruby/templates/agent) and keep all
custom agent extension there. We need to
Yes.
Plus, we will modify agent's init.pp and add custom templates (if any) in
each cartridge module.
On Tue, Aug 19, 2014 at 7:02 PM, Chamila De Alwis wrote:
> So in the agent's push_templates defined type we'll replace *content =>
> template("agent/${name}.erb")* with *content =>
> template(
So in the agent's push_templates defined type we'll replace *content =>
template("agent/${name}.erb")* with *content =>
template("${module}/${name}.erb")*?
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Tue, Aug 19, 2014 at 4:54 PM, Rajkumar
Hi,
Currently we are having an agent puppet module, which includes all agent
extensions (puppet/modules/agent/templates/extensions/*).
All the cartridges need these extensions, but with different behaviors
(implementation of these extensions could be different from cartridge to
cartridge). For ex
On Tue, Aug 19, 2014 at 12:50 PM, Lahiru Sandaruwan
wrote:
> Hi Nirmal,
>
>
> On Mon, Aug 18, 2014 at 11:42 PM, Nirmal Fernando
> wrote:
>
>> Hi All,
>>
>> We need to clearly understand the mapping of Stratos concepts against
>> each deployment type in order to provide Docker support in Stratos.
Hi Nirmal,
On Mon, Aug 18, 2014 at 11:42 PM, Nirmal Fernando
wrote:
> Hi All,
>
> We need to clearly understand the mapping of Stratos concepts against each
> deployment type in order to provide Docker support in Stratos. Please see
> the following table and let me know your thoughts.
>
>
> Dep
39 matches
Mail list logo
