You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Michael Brohl <mi...@ecomify.de> on 2017/11/03 09:10:00 UTC
Re: [PROPOSAL] Environment variable configuration
Just an update triggered by the question from Swapnil [1]: our
configuration mechanism mentioned below is now on Gradle so it would be
compatible with 16.11 and later.
Regards,
Michael
[1]
https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
Am 05.07.17 um 17:56 schrieb Michael Brohl:
> Hi Gil,
>
> we have similar challenges and modified OFBiz to deal with it easily.
> We offered to contribute this long time ago (2008) but it was decided
> against [1]. It was suggested to use patches instead but I think it's
> too complicated to manage several patch sets for different environments.
>
> We now use a staged configure mechanism which uses a base build file,
> auto detected machine name and provided parameters to decide which
> configurations should be pulled for the environment. It's currently
> Ant based and therefore does not fit into the current build mechanism
> (on the todo list).
>
> I like your approach also and I think it should be evaluated and
> discussed.
>
> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
> [1]
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>
>
>
> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>> Hello all,
>>
>> Working with different hosting companies, we used to have issues when
>> deploying OFBiz concerning technical configuration of the different
>> environments.
>> We are writing this mail to get feedback from the community and
>> eventually propose to improve OFBiz on this matter.
>>
>> For a customer, we are working with 4 instances of a release 13.07
>> OFBiz, and are currently using a set of patches (with
>> addonmanager...) to manage environment specific configurations.
>> During each production deployment, the hosting company receive from
>> our jenkins a precompiled archive containing OFBiz codebase, and then
>> apply the set of patches to configure it to the environment needs,
>> recompile and relaunch...
>>
>> This way of doing can cause issue when patch could not apply, after a
>> codebase modification (pretty rare but it happens).
>>
>> We are not satisfied with this way of doing, we are currently
>> thinking about using environment variables to configure technical
>> environment properties (those are on the hosting company
>> responsibility), and to keep functional specifics into the code base.
>> If you have some experience or advice in this matter, you are welcome.
>>
>> For our case, we currently have enhanced OFBiz to be able to get
>> environment variable from the operating system within property file
>> and some other configuration files (with default value if not set).
>>
>> Examples :
>> *In Property file :
>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or
>> ofbiz if unset
>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable
>> OTHER_CONF or ${partyId} if unset
>> *In entityengine.xml :
>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>
>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>
>> That allow us to keep functional parameters stored within git
>> branches. Our jenkins now is able to build our 4 configured and
>> compiled instances and deliver it to the hosting company, that just
>> have to set/check environment variable (database access, activeMQ,
>> log location, instance id, etc.) before starting OFBiz app. Now we
>> cannot have configuration failure during deployment.
>>
>> We will be glad to contribute it, if it's the good way to go !
>>
>> Best Regards !
>>
>> Gil Portenseigne
>>
>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Swapnil Mane <sw...@hotwaxsystems.com>.
Thank you Michael! :-)
- Best Regards,
Swapnil M Mane
On Fri, Nov 3, 2017 at 2:40 PM, Michael Brohl <mi...@ecomify.de>
wrote:
> Just an update triggered by the question from Swapnil [1]: our
> configuration mechanism mentioned below is now on Gradle so it would be
> compatible with 16.11 and later.
>
> Regards,
>
> Michael
>
> [1] https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b1
> 22eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>
> Hi Gil,
>>
>> we have similar challenges and modified OFBiz to deal with it easily. We
>> offered to contribute this long time ago (2008) but it was decided against
>> [1]. It was suggested to use patches instead but I think it's too
>> complicated to manage several patch sets for different environments.
>>
>> We now use a staged configure mechanism which uses a base build file,
>> auto detected machine name and provided parameters to decide which
>> configurations should be pulled for the environment. It's currently Ant
>> based and therefore does not fit into the current build mechanism (on the
>> todo list).
>>
>> I like your approach also and I think it should be evaluated and
>> discussed.
>>
>> Best regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268
>> b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>
>>
>>
>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>
>>> Hello all,
>>>
>>> Working with different hosting companies, we used to have issues when
>>> deploying OFBiz concerning technical configuration of the different
>>> environments.
>>> We are writing this mail to get feedback from the community and
>>> eventually propose to improve OFBiz on this matter.
>>>
>>> For a customer, we are working with 4 instances of a release 13.07
>>> OFBiz, and are currently using a set of patches (with addonmanager...) to
>>> manage environment specific configurations.
>>> During each production deployment, the hosting company receive from our
>>> jenkins a precompiled archive containing OFBiz codebase, and then apply the
>>> set of patches to configure it to the environment needs, recompile and
>>> relaunch...
>>>
>>> This way of doing can cause issue when patch could not apply, after a
>>> codebase modification (pretty rare but it happens).
>>>
>>> We are not satisfied with this way of doing, we are currently thinking
>>> about using environment variables to configure technical environment
>>> properties (those are on the hosting company responsibility), and to keep
>>> functional specifics into the code base.
>>> If you have some experience or advice in this matter, you are welcome.
>>>
>>> For our case, we currently have enhanced OFBiz to be able to get
>>> environment variable from the operating system within property file and
>>> some other configuration files (with default value if not set).
>>>
>>> Examples :
>>> *In Property file :
>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz
>>> if unset
>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable
>>> OTHER_CONF or ${partyId} if unset
>>> *In entityengine.xml :
>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz
>>> ?autoReconnect=true}"
>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>
>>> That allow us to keep functional parameters stored within git branches.
>>> Our jenkins now is able to build our 4 configured and compiled instances
>>> and deliver it to the hosting company, that just have to set/check
>>> environment variable (database access, activeMQ, log location, instance id,
>>> etc.) before starting OFBiz app. Now we cannot have configuration failure
>>> during deployment.
>>>
>>> We will be glad to contribute it, if it's the good way to go !
>>>
>>> Best Regards !
>>>
>>> Gil Portenseigne
>>>
>>>
>>
>>
>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Gil Portenseigne <gi...@nereide.fr>.
Hello,
Thanks for proposing your tried and tested configuration solution. The
idea of discussion the original proposal about OFBiz configuration with
environment variable stayed in my head.
In the light of your solution and with our implementation feedback (git
branching configuration + env variable), and others contributors
feedback, we might elaborate the best to ease configuration management.
Thanks and Regards.
Gil
On Sun, Feb 02, 2020 at 04:40:14PM +0100, Michael Brohl wrote:
> Hi everyone,
>
> the recent discussions reminded me of this thread again. There were a few
> people who were curious how we do configuration management and deployment
> (now in production for about 10 years). It is working for projects based on
> releases 13, 16, 17, 18 and trunk (with either Ant or Gradle).
>
> Although we have our ways to maintain this as not being part of the official
> OFBiz codebase, I still think it is a good approach worth contributing.
>
> Is this interesting for the community?
>
> If there is significant interest I would try to re-write the proposal I did
> in [1], updated to the newest Gradle mechanism and several aspects for multi
> stage projects.
>
> Cheers,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 17.11.17 um 22:18 schrieb Michael Brohl:
> > Hi Jacques,
> >
> > it takes some effort to make an OFBiz standard compatible patch of the
> > mechanism because we have several additions to the configurations. I
> > would take the effort if the community wants to adapt it but it's too
> > much work for just giving an idea.
> >
> > I have explained the mechanism in [1]. There it is based on Ant but we
> > already use it in projects with Gradle.
> >
> > We were looking for other solutions during the migration to Gradle but
> > haven't found a better approach considering all pros and cons (database
> > configuration, environment variables etc.). We use it for years on our
> > test- and production environments and it makes the handling of different
> > system specific configurations very easy.
> >
> > We are thinking about the introduction of an additional configuration
> > level so that we have the base configuration (containing all
> > properties), a project configuration level and the system specific
> > configurations. This helps us to additionally maintain projects using
> > different sets of plugins.
> >
> > I'm happy to explain more if something is unclear.
> >
> > Regards,
> >
> > Michael
> >
> >
> > [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> >
> >
> > Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
> > > That's quite interesting Michael,
> > >
> > > Would you share in a Jira? Then we could get to merge all
> > > experiences and find a consensu.
> > >
> > > Jacques
> > >
> > >
> > > Le 03/11/2017 à 10:10, Michael Brohl a écrit :
> > > > Just an update triggered by the question from Swapnil [1]: our
> > > > configuration mechanism mentioned below is now on Gradle so it
> > > > would be compatible with 16.11 and later.
> > > >
> > > > Regards,
> > > >
> > > > Michael
> > > >
> > > > [1] https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
> > > >
> > > >
> > > > Am 05.07.17 um 17:56 schrieb Michael Brohl:
> > > > > Hi Gil,
> > > > >
> > > > > we have similar challenges and modified OFBiz to deal with
> > > > > it easily. We offered to contribute this long time ago
> > > > > (2008) but it was decided against [1]. It was suggested to
> > > > > use patches instead but I think it's too complicated to
> > > > > manage several patch sets for different environments.
> > > > >
> > > > > We now use a staged configure mechanism which uses a base
> > > > > build file, auto detected machine name and provided
> > > > > parameters to decide which configurations should be pulled
> > > > > for the environment. It's currently Ant based and therefore
> > > > > does not fit into the current build mechanism (on the todo
> > > > > list).
> > > > >
> > > > > I like your approach also and I think it should be evaluated
> > > > > and discussed.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Michael Brohl
> > > > > ecomify GmbH
> > > > > www.ecomify.de
> > > > >
> > > > > [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> > > > >
> > > > >
> > > > >
> > > > > Am 05.07.17 um 17:36 schrieb gil portenseigne:
> > > > > > Hello all,
> > > > > >
> > > > > > Working with different hosting companies, we used to
> > > > > > have issues when deploying OFBiz concerning technical
> > > > > > configuration of the different environments.
> > > > > > We are writing this mail to get feedback from the
> > > > > > community and eventually propose to improve OFBiz on
> > > > > > this matter.
> > > > > >
> > > > > > For a customer, we are working with 4 instances of a
> > > > > > release 13.07 OFBiz, and are currently using a set of
> > > > > > patches (with addonmanager...) to manage environment
> > > > > > specific configurations.
> > > > > > During each production deployment, the hosting company
> > > > > > receive from our jenkins a precompiled archive
> > > > > > containing OFBiz codebase, and then apply the set of
> > > > > > patches to configure it to the environment needs,
> > > > > > recompile and relaunch...
> > > > > >
> > > > > > This way of doing can cause issue when patch could not
> > > > > > apply, after a codebase modification (pretty rare but it
> > > > > > happens).
> > > > > >
> > > > > > We are not satisfied with this way of doing, we are
> > > > > > currently thinking about using environment variables to
> > > > > > configure technical environment properties (those are on
> > > > > > the hosting company responsibility), and to keep
> > > > > > functional specifics into the code base.
> > > > > > If you have some experience or advice in this matter,
> > > > > > you are welcome.
> > > > > >
> > > > > > For our case, we currently have enhanced OFBiz to be
> > > > > > able to get environment variable from the operating
> > > > > > system within property file and some other configuration
> > > > > > files (with default value if not set).
> > > > > >
> > > > > > Examples :
> > > > > > *In Property file :
> > > > > > password=${env:ONE_CONF:ofbiz} -> environment variable
> > > > > > ONE_CONF or ofbiz if unset
> > > > > > other_config=${env:OTHER_CONF:${partyId}} -> environment
> > > > > > variable OTHER_CONF or ${partyId} if unset
> > > > > > *In entityengine.xml :
> > > > > > jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
> > > > > >
> > > > > > jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
> > > > > > jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
> > > > > >
> > > > > > That allow us to keep functional parameters stored
> > > > > > within git branches. Our jenkins now is able to build
> > > > > > our 4 configured and compiled instances and deliver it
> > > > > > to the hosting company, that just have to set/check
> > > > > > environment variable (database access, activeMQ, log
> > > > > > location, instance id, etc.) before starting OFBiz app.
> > > > > > Now we cannot have configuration failure during
> > > > > > deployment.
> > > > > >
> > > > > > We will be glad to contribute it, if it's the good way to go !
> > > > > >
> > > > > > Best Regards !
> > > > > >
> > > > > > Gil Portenseigne
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: [PROPOSAL] Environment variable configuration
Posted by Michael Brohl <mi...@ecomify.de>.
Hi everyone,
the recent discussions reminded me of this thread again. There were a
few people who were curious how we do configuration management and
deployment (now in production for about 10 years). It is working for
projects based on releases 13, 16, 17, 18 and trunk (with either Ant or
Gradle).
Although we have our ways to maintain this as not being part of the
official OFBiz codebase, I still think it is a good approach worth
contributing.
Is this interesting for the community?
If there is significant interest I would try to re-write the proposal I
did in [1], updated to the newest Gradle mechanism and several aspects
for multi stage projects.
Cheers,
Michael Brohl
ecomify GmbH - www.ecomify.de
[1]
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
Am 17.11.17 um 22:18 schrieb Michael Brohl:
> Hi Jacques,
>
> it takes some effort to make an OFBiz standard compatible patch of the
> mechanism because we have several additions to the configurations. I
> would take the effort if the community wants to adapt it but it's too
> much work for just giving an idea.
>
> I have explained the mechanism in [1]. There it is based on Ant but we
> already use it in projects with Gradle.
>
> We were looking for other solutions during the migration to Gradle but
> haven't found a better approach considering all pros and cons
> (database configuration, environment variables etc.). We use it for
> years on our test- and production environments and it makes the
> handling of different system specific configurations very easy.
>
> We are thinking about the introduction of an additional configuration
> level so that we have the base configuration (containing all
> properties), a project configuration level and the system specific
> configurations. This helps us to additionally maintain projects using
> different sets of plugins.
>
> I'm happy to explain more if something is unclear.
>
> Regards,
>
> Michael
>
>
> [1]
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
>> That's quite interesting Michael,
>>
>> Would you share in a Jira? Then we could get to merge all experiences
>> and find a consensu.
>>
>> Jacques
>>
>>
>> Le 03/11/2017 à 10:10, Michael Brohl a écrit :
>>> Just an update triggered by the question from Swapnil [1]: our
>>> configuration mechanism mentioned below is now on Gradle so it would
>>> be compatible with 16.11 and later.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>> [1]
>>> https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>>>
>>>
>>> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>>>> Hi Gil,
>>>>
>>>> we have similar challenges and modified OFBiz to deal with it
>>>> easily. We offered to contribute this long time ago (2008) but it
>>>> was decided against [1]. It was suggested to use patches instead
>>>> but I think it's too complicated to manage several patch sets for
>>>> different environments.
>>>>
>>>> We now use a staged configure mechanism which uses a base build
>>>> file, auto detected machine name and provided parameters to decide
>>>> which configurations should be pulled for the environment. It's
>>>> currently Ant based and therefore does not fit into the current
>>>> build mechanism (on the todo list).
>>>>
>>>> I like your approach also and I think it should be evaluated and
>>>> discussed.
>>>>
>>>> Best regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>> [1]
>>>> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>>>
>>>>
>>>>
>>>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>>>> Hello all,
>>>>>
>>>>> Working with different hosting companies, we used to have issues
>>>>> when deploying OFBiz concerning technical configuration of the
>>>>> different environments.
>>>>> We are writing this mail to get feedback from the community and
>>>>> eventually propose to improve OFBiz on this matter.
>>>>>
>>>>> For a customer, we are working with 4 instances of a release 13.07
>>>>> OFBiz, and are currently using a set of patches (with
>>>>> addonmanager...) to manage environment specific configurations.
>>>>> During each production deployment, the hosting company receive
>>>>> from our jenkins a precompiled archive containing OFBiz codebase,
>>>>> and then apply the set of patches to configure it to the
>>>>> environment needs, recompile and relaunch...
>>>>>
>>>>> This way of doing can cause issue when patch could not apply,
>>>>> after a codebase modification (pretty rare but it happens).
>>>>>
>>>>> We are not satisfied with this way of doing, we are currently
>>>>> thinking about using environment variables to configure technical
>>>>> environment properties (those are on the hosting company
>>>>> responsibility), and to keep functional specifics into the code base.
>>>>> If you have some experience or advice in this matter, you are
>>>>> welcome.
>>>>>
>>>>> For our case, we currently have enhanced OFBiz to be able to get
>>>>> environment variable from the operating system within property
>>>>> file and some other configuration files (with default value if not
>>>>> set).
>>>>>
>>>>> Examples :
>>>>> *In Property file :
>>>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or
>>>>> ofbiz if unset
>>>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable
>>>>> OTHER_CONF or ${partyId} if unset
>>>>> *In entityengine.xml :
>>>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>>>>
>>>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>>>
>>>>> That allow us to keep functional parameters stored within git
>>>>> branches. Our jenkins now is able to build our 4 configured and
>>>>> compiled instances and deliver it to the hosting company, that
>>>>> just have to set/check environment variable (database access,
>>>>> activeMQ, log location, instance id, etc.) before starting OFBiz
>>>>> app. Now we cannot have configuration failure during deployment.
>>>>>
>>>>> We will be glad to contribute it, if it's the good way to go !
>>>>>
>>>>> Best Regards !
>>>>>
>>>>> Gil Portenseigne
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Michael,
I remember this discussion. My aim here is to replace the consensual advice we had with pre Gradle version, still at
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65865831#AddressingCustomRequirementsInOFBiz-PatchManagementUsingAntTargets
I think we can suggest more than one solution and people can then pick the one fitting more for them. Maybe you could begin to add yours in the
current AddressingCustomRequirementsInOFBiz page.
I'll suggest the same for Gil's with OFBIZ-9498.
Hope it clarifies things
Jacques
Le 17/11/2017 à 22:18, Michael Brohl a écrit :
> Hi Jacques,
>
> it takes some effort to make an OFBiz standard compatible patch of the mechanism because we have several additions to the configurations. I would
> take the effort if the community wants to adapt it but it's too much work for just giving an idea.
>
> I have explained the mechanism in [1]. There it is based on Ant but we already use it in projects with Gradle.
>
> We were looking for other solutions during the migration to Gradle but haven't found a better approach considering all pros and cons (database
> configuration, environment variables etc.). We use it for years on our test- and production environments and it makes the handling of different
> system specific configurations very easy.
>
> We are thinking about the introduction of an additional configuration level so that we have the base configuration (containing all properties), a
> project configuration level and the system specific configurations. This helps us to additionally maintain projects using different sets of plugins.
>
> I'm happy to explain more if something is unclear.
>
> Regards,
>
> Michael
>
>
> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
>> That's quite interesting Michael,
>>
>> Would you share in a Jira? Then we could get to merge all experiences and find a consensu.
>>
>> Jacques
>>
>>
>> Le 03/11/2017 à 10:10, Michael Brohl a écrit :
>>> Just an update triggered by the question from Swapnil [1]: our configuration mechanism mentioned below is now on Gradle so it would be compatible
>>> with 16.11 and later.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>> [1] https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>>>
>>>
>>> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>>>> Hi Gil,
>>>>
>>>> we have similar challenges and modified OFBiz to deal with it easily. We offered to contribute this long time ago (2008) but it was decided
>>>> against [1]. It was suggested to use patches instead but I think it's too complicated to manage several patch sets for different environments.
>>>>
>>>> We now use a staged configure mechanism which uses a base build file, auto detected machine name and provided parameters to decide which
>>>> configurations should be pulled for the environment. It's currently Ant based and therefore does not fit into the current build mechanism (on the
>>>> todo list).
>>>>
>>>> I like your approach also and I think it should be evaluated and discussed.
>>>>
>>>> Best regards,
>>>>
>>>> Michael Brohl
>>>> ecomify GmbH
>>>> www.ecomify.de
>>>>
>>>> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>>>
>>>>
>>>>
>>>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>>>> Hello all,
>>>>>
>>>>> Working with different hosting companies, we used to have issues when deploying OFBiz concerning technical configuration of the different
>>>>> environments.
>>>>> We are writing this mail to get feedback from the community and eventually propose to improve OFBiz on this matter.
>>>>>
>>>>> For a customer, we are working with 4 instances of a release 13.07 OFBiz, and are currently using a set of patches (with addonmanager...) to
>>>>> manage environment specific configurations.
>>>>> During each production deployment, the hosting company receive from our jenkins a precompiled archive containing OFBiz codebase, and then apply
>>>>> the set of patches to configure it to the environment needs, recompile and relaunch...
>>>>>
>>>>> This way of doing can cause issue when patch could not apply, after a codebase modification (pretty rare but it happens).
>>>>>
>>>>> We are not satisfied with this way of doing, we are currently thinking about using environment variables to configure technical environment
>>>>> properties (those are on the hosting company responsibility), and to keep functional specifics into the code base.
>>>>> If you have some experience or advice in this matter, you are welcome.
>>>>>
>>>>> For our case, we currently have enhanced OFBiz to be able to get environment variable from the operating system within property file and some
>>>>> other configuration files (with default value if not set).
>>>>>
>>>>> Examples :
>>>>> *In Property file :
>>>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz if unset
>>>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable OTHER_CONF or ${partyId} if unset
>>>>> *In entityengine.xml :
>>>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>>>
>>>>> That allow us to keep functional parameters stored within git branches. Our jenkins now is able to build our 4 configured and compiled instances
>>>>> and deliver it to the hosting company, that just have to set/check environment variable (database access, activeMQ, log location, instance id,
>>>>> etc.) before starting OFBiz app. Now we cannot have configuration failure during deployment.
>>>>>
>>>>> We will be glad to contribute it, if it's the good way to go !
>>>>>
>>>>> Best Regards !
>>>>>
>>>>> Gil Portenseigne
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Jacques,
it takes some effort to make an OFBiz standard compatible patch of the
mechanism because we have several additions to the configurations. I
would take the effort if the community wants to adapt it but it's too
much work for just giving an idea.
I have explained the mechanism in [1]. There it is based on Ant but we
already use it in projects with Gradle.
We were looking for other solutions during the migration to Gradle but
haven't found a better approach considering all pros and cons (database
configuration, environment variables etc.). We use it for years on our
test- and production environments and it makes the handling of different
system specific configurations very easy.
We are thinking about the introduction of an additional configuration
level so that we have the base configuration (containing all
properties), a project configuration level and the system specific
configurations. This helps us to additionally maintain projects using
different sets of plugins.
I'm happy to explain more if something is unclear.
Regards,
Michael
[1]
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
> That's quite interesting Michael,
>
> Would you share in a Jira? Then we could get to merge all experiences
> and find a consensu.
>
> Jacques
>
>
> Le 03/11/2017 à 10:10, Michael Brohl a écrit :
>> Just an update triggered by the question from Swapnil [1]: our
>> configuration mechanism mentioned below is now on Gradle so it would
>> be compatible with 16.11 and later.
>>
>> Regards,
>>
>> Michael
>>
>> [1]
>> https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>>
>>
>> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>>> Hi Gil,
>>>
>>> we have similar challenges and modified OFBiz to deal with it
>>> easily. We offered to contribute this long time ago (2008) but it
>>> was decided against [1]. It was suggested to use patches instead but
>>> I think it's too complicated to manage several patch sets for
>>> different environments.
>>>
>>> We now use a staged configure mechanism which uses a base build
>>> file, auto detected machine name and provided parameters to decide
>>> which configurations should be pulled for the environment. It's
>>> currently Ant based and therefore does not fit into the current
>>> build mechanism (on the todo list).
>>>
>>> I like your approach also and I think it should be evaluated and
>>> discussed.
>>>
>>> Best regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>> [1]
>>> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>>
>>>
>>>
>>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>>> Hello all,
>>>>
>>>> Working with different hosting companies, we used to have issues
>>>> when deploying OFBiz concerning technical configuration of the
>>>> different environments.
>>>> We are writing this mail to get feedback from the community and
>>>> eventually propose to improve OFBiz on this matter.
>>>>
>>>> For a customer, we are working with 4 instances of a release 13.07
>>>> OFBiz, and are currently using a set of patches (with
>>>> addonmanager...) to manage environment specific configurations.
>>>> During each production deployment, the hosting company receive from
>>>> our jenkins a precompiled archive containing OFBiz codebase, and
>>>> then apply the set of patches to configure it to the environment
>>>> needs, recompile and relaunch...
>>>>
>>>> This way of doing can cause issue when patch could not apply, after
>>>> a codebase modification (pretty rare but it happens).
>>>>
>>>> We are not satisfied with this way of doing, we are currently
>>>> thinking about using environment variables to configure technical
>>>> environment properties (those are on the hosting company
>>>> responsibility), and to keep functional specifics into the code base.
>>>> If you have some experience or advice in this matter, you are welcome.
>>>>
>>>> For our case, we currently have enhanced OFBiz to be able to get
>>>> environment variable from the operating system within property file
>>>> and some other configuration files (with default value if not set).
>>>>
>>>> Examples :
>>>> *In Property file :
>>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or
>>>> ofbiz if unset
>>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable
>>>> OTHER_CONF or ${partyId} if unset
>>>> *In entityengine.xml :
>>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>>>
>>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>>
>>>> That allow us to keep functional parameters stored within git
>>>> branches. Our jenkins now is able to build our 4 configured and
>>>> compiled instances and deliver it to the hosting company, that just
>>>> have to set/check environment variable (database access, activeMQ,
>>>> log location, instance id, etc.) before starting OFBiz app. Now we
>>>> cannot have configuration failure during deployment.
>>>>
>>>> We will be glad to contribute it, if it's the good way to go !
>>>>
>>>> Best Regards !
>>>>
>>>> Gil Portenseigne
>>>>
>>>
>>>
>>
>>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 03/11/2017 à 11:39, Jacques Le Roux a écrit :
> That's quite interesting Michael,
>
> Would you share in a Jira? Then we could get to merge all experiences and find a consensu.
OK Gil created one already in July https://issues.apache.org/jira/browse/OFBIZ-9498
>
> Jacques
>
>
> Le 03/11/2017 à 10:10, Michael Brohl a écrit :
>> Just an update triggered by the question from Swapnil [1]: our configuration mechanism mentioned below is now on Gradle so it would be compatible
>> with 16.11 and later.
>>
>> Regards,
>>
>> Michael
>>
>> [1] https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>>
>>
>> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>>> Hi Gil,
>>>
>>> we have similar challenges and modified OFBiz to deal with it easily. We offered to contribute this long time ago (2008) but it was decided
>>> against [1]. It was suggested to use patches instead but I think it's too complicated to manage several patch sets for different environments.
>>>
>>> We now use a staged configure mechanism which uses a base build file, auto detected machine name and provided parameters to decide which
>>> configurations should be pulled for the environment. It's currently Ant based and therefore does not fit into the current build mechanism (on the
>>> todo list).
>>>
>>> I like your approach also and I think it should be evaluated and discussed.
>>>
>>> Best regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>>
>>>
>>>
>>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>>> Hello all,
>>>>
>>>> Working with different hosting companies, we used to have issues when deploying OFBiz concerning technical configuration of the different
>>>> environments.
>>>> We are writing this mail to get feedback from the community and eventually propose to improve OFBiz on this matter.
>>>>
>>>> For a customer, we are working with 4 instances of a release 13.07 OFBiz, and are currently using a set of patches (with addonmanager...) to
>>>> manage environment specific configurations.
>>>> During each production deployment, the hosting company receive from our jenkins a precompiled archive containing OFBiz codebase, and then apply
>>>> the set of patches to configure it to the environment needs, recompile and relaunch...
>>>>
>>>> This way of doing can cause issue when patch could not apply, after a codebase modification (pretty rare but it happens).
>>>>
>>>> We are not satisfied with this way of doing, we are currently thinking about using environment variables to configure technical environment
>>>> properties (those are on the hosting company responsibility), and to keep functional specifics into the code base.
>>>> If you have some experience or advice in this matter, you are welcome.
>>>>
>>>> For our case, we currently have enhanced OFBiz to be able to get environment variable from the operating system within property file and some
>>>> other configuration files (with default value if not set).
>>>>
>>>> Examples :
>>>> *In Property file :
>>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz if unset
>>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable OTHER_CONF or ${partyId} if unset
>>>> *In entityengine.xml :
>>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>>
>>>> That allow us to keep functional parameters stored within git branches. Our jenkins now is able to build our 4 configured and compiled instances
>>>> and deliver it to the hosting company, that just have to set/check environment variable (database access, activeMQ, log location, instance id,
>>>> etc.) before starting OFBiz app. Now we cannot have configuration failure during deployment.
>>>>
>>>> We will be glad to contribute it, if it's the good way to go !
>>>>
>>>> Best Regards !
>>>>
>>>> Gil Portenseigne
>>>>
>>>
>>>
>>
>>
>
>
Re: [PROPOSAL] Environment variable configuration
Posted by Jacques Le Roux <ja...@les7arts.com>.
That's quite interesting Michael,
Would you share in a Jira? Then we could get to merge all experiences and find a consensu.
Jacques
Le 03/11/2017 à 10:10, Michael Brohl a écrit :
> Just an update triggered by the question from Swapnil [1]: our configuration mechanism mentioned below is now on Gradle so it would be compatible
> with 16.11 and later.
>
> Regards,
>
> Michael
>
> [1] https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 05.07.17 um 17:56 schrieb Michael Brohl:
>> Hi Gil,
>>
>> we have similar challenges and modified OFBiz to deal with it easily. We offered to contribute this long time ago (2008) but it was decided against
>> [1]. It was suggested to use patches instead but I think it's too complicated to manage several patch sets for different environments.
>>
>> We now use a staged configure mechanism which uses a base build file, auto detected machine name and provided parameters to decide which
>> configurations should be pulled for the environment. It's currently Ant based and therefore does not fit into the current build mechanism (on the
>> todo list).
>>
>> I like your approach also and I think it should be evaluated and discussed.
>>
>> Best regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>> [1] https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>>
>>
>>
>> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>>> Hello all,
>>>
>>> Working with different hosting companies, we used to have issues when deploying OFBiz concerning technical configuration of the different
>>> environments.
>>> We are writing this mail to get feedback from the community and eventually propose to improve OFBiz on this matter.
>>>
>>> For a customer, we are working with 4 instances of a release 13.07 OFBiz, and are currently using a set of patches (with addonmanager...) to
>>> manage environment specific configurations.
>>> During each production deployment, the hosting company receive from our jenkins a precompiled archive containing OFBiz codebase, and then apply
>>> the set of patches to configure it to the environment needs, recompile and relaunch...
>>>
>>> This way of doing can cause issue when patch could not apply, after a codebase modification (pretty rare but it happens).
>>>
>>> We are not satisfied with this way of doing, we are currently thinking about using environment variables to configure technical environment
>>> properties (those are on the hosting company responsibility), and to keep functional specifics into the code base.
>>> If you have some experience or advice in this matter, you are welcome.
>>>
>>> For our case, we currently have enhanced OFBiz to be able to get environment variable from the operating system within property file and some
>>> other configuration files (with default value if not set).
>>>
>>> Examples :
>>> *In Property file :
>>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz if unset
>>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable OTHER_CONF or ${partyId} if unset
>>> *In entityengine.xml :
>>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>>
>>> That allow us to keep functional parameters stored within git branches. Our jenkins now is able to build our 4 configured and compiled instances
>>> and deliver it to the hosting company, that just have to set/check environment variable (database access, activeMQ, log location, instance id,
>>> etc.) before starting OFBiz app. Now we cannot have configuration failure during deployment.
>>>
>>> We will be glad to contribute it, if it's the good way to go !
>>>
>>> Best Regards !
>>>
>>> Gil Portenseigne
>>>
>>
>>
>
>