You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <bh...@apache.org> on 2013/02/26 10:21:42 UTC
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.
Re: Help with packaging and doc for sysadmins
Posted by Rohit Yadav <bh...@apache.org>.
Hey Hugo!
On Tue, Feb 26, 2013 at 2:55 PM, Hugo Trippaers
<HT...@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.
Re: Help with packaging and doc for sysadmins
Posted by Rohit Yadav <bh...@apache.org>.
On Tue, Feb 26, 2013 at 2:55 PM, Hugo Trippaers
<HT...@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.
But either way I'm fine, we can expose pluggablility by some
properties file, but such a thing will have to be implemented.
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.
Re: Help with packaging and doc for sysadmins
Posted by Dave Cahill <dc...@midokura.com>.
Hi,
For what it's worth, I was under the same impression as Rohit - that
administrators would edit components.xml to fit their deployment.
See for example this snippet from "Extending CloudStack Networking" [1]:
> "Generally, it is expected that the cloud administrator will configure
components.xml to avoid this clash."
I can see advantages to keeping this behvaior, but I may be missing part of
the picture.
Thanks,
Dave.
[1] https://cwiki.apache.org/CLOUDSTACK/extending-cloudstack-networking.html
On Tue, Feb 26, 2013 at 6:25 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.
>
> 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.
>
Re: Help with packaging and doc for sysadmins
Posted by Murali Reddy <Mu...@citrix.com>.
Hugo,
In the current model, components that are not needed by default are not
present in componentContext.xml. Just in case if you have not noticed, in
4.1, NiciraNvp bean is not enabled by default :). Admin needs to edit
componentContext.xml, to enable a optional component.
Thanks!
On 26/02/13 2:55 PM, "Hugo Trippaers" <HT...@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.
>
>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.
>
RE: Help with packaging and doc for sysadmins
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
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.
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.