Question about best practices for environment-specific hst-configurations or Node-Properties

[Norman Rehbein]

Hello dear Hippo Community!

I have a question about best practices for keeping enviroment-specfic configurations or node properties.

For example in the production environment we have a property on a node in the hst:configuration, that defines an email address.

This value of the email address is different for test, than it is on production (for obvious reasons).

On every deploy this value gets set back to the default value. reload-on-startup is also false for those nodes.
That means, we have to manually change those values on every deploy.

What would be the best way to keep these environment specific values ?
running a groovy script with parameters, which sets these on every deploy?

I would really appreciate any advices!


Dear regards,

Norman Rehbein

[Marijan Milicevic]

Hi,

On Mon, May 15, 2017 at 4:46 PM, Norman Rehbein <rehbein...@gmail.com> wrote:

Hello dear Hippo Community!

I have a question about best practices for keeping enviroment-specfic configurations or node properties.

For example in the production environment we have a property on a node in the hst:configuration, that defines an email address.

This value of the email address is different for test, than it is on production (for obvious reasons).

On every deploy this value gets set back to the default value. reload-on-startup is also false for those nodes.

this is contradicting: if reload on startup is not set for those nodes those shouldn't be reloaded. 

 

That means, we have to manually change those values on every deploy.

What would be the best way to keep these environment specific values ?
running a groovy script with parameters, which sets these on every deploy?

I would really appreciate any advices!

this all depends on your application. One way is to externalize "system" properties to property file per environment (we are talking about properties that pretty much never change),

other way is to use properties plugin /resource bundles to store specific values. Daemon modules / repository managed components / channel manager properties / wicket plugins etc, can be configure once and make sure not to reload those (as in your example)

cheers

marijan

 

Dear regards,

Norman Rehbein

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Norman Rehbein]

Well, thanks for the advice for externalizing those system properties and especially the fast response!

Then I really do not understand why those changes to node-properties are not persisting.

As example: we have an rest-api-node:

<?xml version="1.0" encoding="UTF-8"?><sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" sv:name="akelius:api-config-common">
  <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:unstructured</sv:value>
  </sv:property>
  <sv:property sv:name="jcr:mixinTypes" sv:type="Name" sv:multiple="true">
    <sv:value>ns:config</sv:value>
  </sv:property>
  <sv:property sv:name="ns:cache" sv:type="String">
    <sv:value>http://localhost:8080/site/se/api/cache</sv:value>
  </sv:property>
  <sv:property sv:name="hippo:reloadonstartup" sv:type="Boolean">
    <sv:value>false</sv:value>
  </sv:property>
</sv:node>

this is the clearly an outermost node. On production or staging we would then change localhost to sth other, like mydomain.com.

On the restart the change persists, but when deploying a new release it is back to http://localhost:8080/site/se/api/cache...

Do you maybe have any idea what could be the cause of that? (in production autoexport is disabled)

Could it have sth to do with the initialize attribute?

You received this message because you are subscribed to a topic in the Google Groups "Hippo Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hippo-community/OeITFvTaLEE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hippo-community+unsubscribe@googlegroups.com.

[Norman Rehbein]

Well, thanks for the advice for externalizing those system properties and especially the fast response!

Then I really do not understand why those changes to node-properties are not persisting.

As example: we have an rest-api-node:

<?xml version="1.0" encoding="UTF-8"?><sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" sv:name="ns:api-config-common">

  <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:unstructured</sv:value>
  </sv:property>
  <sv:property sv:name="jcr:mixinTypes" sv:type="Name" sv:multiple="true">
    <sv:value>ns:config</sv:value>
  </sv:property>
  <sv:property sv:name="ns:cache" sv:type="String">
    <sv:value>http://localhost:8080/site/se/api/cache</sv:value>
  </sv:property>
  <sv:property sv:name="hippo:reloadonstartup" sv:type="Boolean">
    <sv:value>false</sv:value>
  </sv:property>
</sv:node>

this is the clearly an outermost node. On production or staging we would then change localhost to sth other, like mydomain.com.

On the restart the change persists, but when deploying a new release it is back to http://localhost:8080/site/se/api/cache...

Do you maybe have any idea what could be the cause of that? (in production autoexport is disabled)

Could it have sth to do with the initialize attribute?

Dear regards,

Norman Rehbein

2017-05-15 16:57 GMT+02:00 Marijan Milicevic <marijan....@bloomreach.com>:

You received this message because you are subscribed to a topic in the Google Groups "Hippo Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hippo-community/OeITFvTaLEE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hippo-community+unsubscribe@googlegroups.com.

[Woonsan Ko]

On Mon, May 15, 2017 at 10:46 AM, Norman Rehbein <rehbein...@gmail.com> wrote:

Hello dear Hippo Community!

I have a question about best practices for keeping enviroment-specfic configurations or node properties.

For example in the production environment we have a property on a node in the hst:configuration, that defines an email address.

This value of the email address is different for test, than it is on production (for obvious reasons).

On every deploy this value gets set back to the default value. reload-on-startup is also false for those nodes.
That means, we have to manually change those values on every deploy.

What would be the best way to keep these environment specific values ?

I guess you need those configurations only in delivery tier application.

If so, why don't you simply define those in hst-config.properties and access those through HstServices.getComponentManager().getContainerConfiguration()?

You can override the hst-config.properties by putting a hst.properties in $CATALINA_BASE/conf/ for each env.

Regards,

Woonsan

 

running a groovy script with parameters, which sets these on every deploy?

I would really appreciate any advices!


Dear regards,

Norman Rehbein

--

Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-community@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-community+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

woons...@bloomreach.com     www.onehippo.com

71 Summer Street, 2nd Floor, Boston, MA 02110

Amsterdam - Oosteinde 11, 1017 WT Amsterdam
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466