incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: Help with packaging and doc for sysadmins
Date Tue, 26 Feb 2013 10:00:56 GMT
Hey Hugo!

On Tue, Feb 26, 2013 at 2:55 PM, Hugo Trippaers
<HTrippaers@schubergphilis.com> wrote:
> Heya Rohit,
>
> Why would a sysadmin need to change this? They should be considered part of the source
code, any configuration should be done via the config in the database or with the *.properties
files.

I thought we wanted to use componentContext.xml to be able to provide
a way for sysadmin to enable or disable components (like
enable/disable apidiscovery plugin), I think Kelven or Alex can
comment on this.

With a properties file, like command.properties for example you can
disable an API by defining a rolemask, but the plugin maybe still
active, for example there could a plugin which extends CloudStack's
internal capability but won't actually expose an API for it.

Regards.

>
> Cheers,
>
> Hugo
>
>> -----Original Message-----
>> From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On Behalf
>> Of Rohit Yadav
>> Sent: Tuesday, February 26, 2013 10:22 AM
>> To: cloudstack-dev@incubator.apache.org
>> Cc: Hugo Trippaers; wido@widodh.nl
>> Subject: Help with packaging and doc for sysadmins
>>
>> Hi Hugo and Wido,
>>
>> Earlier we used to have components.xml from where a sysadmin could
>> enable/disable components for ex. a plugin.
>> Now we've applicationContext and other *Context xml files, but I see them
>> copied to WEB-INF/classes:
>> cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/applicationContext.xml
>>
>> How will a sysadmin change them, will they be copied to
>> /etc/cloudstack/* path or sysadmin would need to edit them wherever the
>> exploded war is installed?
>>
>> Regards.

Mime
View raw message