[erlang-questions] Release upgrade of an app without a top supervisor

[Roberto Ostinelli]

Done that already, to no avail unfortunately.

On Tue, Feb 16, 2016 at 2:30 PM, Ulf Wiger <ulf.wiger@REDACTED> wrote:

> You could perhaps create a setup.appup file in setup-1.5.0/ebin/ with
> roughly the following content (not tested):
>
> {“1.5.0",
>  [{“1.4.6", [{restart_application, setup}]}],
>  [{“1.4.6", [{restart_application, setup}]}]
> }.
>
> BR,
> Ulf W
>
> On 16 Feb 2016, at 13:55, Roberto Ostinelli <roberto@REDACTED> wrote:
>
> Thank you Ulf.
> Anything I can do with an already running system, that obviously doesn't
> have that PR in? The only application using setup is, as you have guessed,
> exometer_core.
>
> On Tue, Feb 16, 2016 at 1:43 PM, Ulf Wiger <ulf.wiger@REDACTED> wrote:
>
>> It’s true that setup didn’t play well with the release handler [blush].
>>
>> That was addressed in the PR you mention.
>>
>> The start_setup option was added mainly because some applications (not
>> least exometer) use setup simply to expand and read environment variables,
>> and therefore do not require setup to be started.
>>
>> Off the top of my head, I can recall the following reasons to start setup
>> at all:
>>
>> - When using it for installation, setup generates a boot script that
>> loads all required apps and sets the code path, then starts setup. Thus,
>> you can fire up a node where only setup is running, but all code and
>> environment data are available. Setup then finds environment variables
>> identifying code hooks to run in different phases of the installation. A
>> corresponding process can be used for upgrades.
>>
>> - When making use of setup’s home(), data_dir() and log_dir(), i.e.
>> locations where applications can safely store data and logs. During
>> startup, setup will verify that those directories exist, creating them if
>> necessary. This behavior can be disabled with the env variable -setup
>> verify_directories true | false.
>>
>> - You could actually run code hooks even during normal startup. Whether
>> or not that’s a good idea is perhaps up for debate. It is possible, though.
>>
>> Predecessors of setup have done more during startup, including reading
>> the boot script and preparing to respond to various configuration queries.
>> But setup currently does little at startup, so most people might prefer it
>> not to start at all. Most functions  - e.g. expanding environment variables
>> or upgrading applications on the fly - are usable even when setup isn’t
>> running.
>>
>> BR,
>> Ulf W
>>
>> On 16 Feb 2016, at 12:27, Roberto Ostinelli <roberto@REDACTED> wrote:
>>
>> I found an old PR of Ulf here:
>> https://github.com/uwiger/setup/pull/23
>>
>> However I don't understand how to use the start_setup option. If any kind
>> soul can help me out it would be great.
>>
>> Thanks,
>> r.
>>
>>
>> On Tue, Feb 16, 2016 at 12:22 PM, Roberto Ostinelli <roberto@REDACTED>
>> wrote:
>>
>>> Dear all,
>>> I'm building a release upgrade however I'm encountering an error during
>>> the release install:
>>>
>>> 1> release_handler:install_release("1.5.0").
>>> <0.1497.0>: reason: {'EXIT',{timeout,{sys,get_status,[<0.1497.0>]}}}
>>> 11:58:30.647 [error] release_handler: cannot find top supervisor for
>>> application setup
>>>
>>> It looks like the application setup [1] does not have a top supervisor,
>>> hence the install fails.
>>>
>>> The app setup itself has not been upgraded, it's the same app; however,
>>> it is packaged as 1.5.0 in comparison to the 1.4.6 currently running in
>>> production.
>>>
>>> Is there any way I can go around this?
>>>
>>> Thanks,
>>> r.
>>>
>>> [1] https://github.com/uwiger/setup
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160216/6d2308a5/attachment.htm>