[erlang-questions] Common Test and base applications

[Fred Hebert]

After trying some different things with Ahmed, I've found out that the
problem is the config file I'm passing to the slave nodes:

[{kernel, [{distributed, [{m8ball, 5000, ['a@REDACTED',
'b@REDACTED']}]}, {sync_nodes_mandatory, ['
b@REDACTED']}, {sync_nodes_timeout, 5000} ] } ].

This seems to override a few values needed by ct_slave when using
distributed applications. Removing the config file solves the
application:which_applications() problem.

What would be the best way to test distributed OTP applications with CT,
then?

On Mon, Feb 13, 2012 at 7:34 AM, Fred Hebert <mononcqc@REDACTED> wrote:

> I tried it with R14B04 also, and it still doesn't work for me. I'll try a
> few more things to try and discover what it might be. I'm a bit surprised
> this can even happen in the first place, though.
>
>
> On Mon, Feb 13, 2012 at 5:44 AM, Ahmed Omar <spawn.think@REDACTED> wrote:
>
>> I tried to reproduce it using same steps, but i get this when i use
>> ct:pal("~p",[application:which_applications()])
>> i get
>>
>> *** User  2012-02-13 11:39:24.901 ***
>> [{crypto,"CRYPTO version 2","2.0.4"},
>>   {stdlib,"ERTS  CXC 138 10","1.17.5"},
>>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>>
>> maybe i'm doing something different..
>>
>> i'm using Erlang R14B04 (erts-5.8.5)
>>
>> On Sun, Feb 12, 2012 at 4:59 PM, Fred Hebert <mononcqc@REDACTED> wrote:
>>
>>> I start them with distributed test specifications:
>>>
>>> {node, master, 'ct@REDACTED'}.
>>> {node, a, 'a@REDACTED'}.
>>> {node, b, 'b@REDACTED'}.
>>>
>>> {init, a, [{node_start, [{monitor_master, true},
>>>                          {boot_timeout, 10},
>>>                          {startup_functions,
>>> [{application,start,[crypto]},
>>>
>>> {application,start,[m8ball]}]},
>>>                          {erl_flags, "-pa
>>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/"
>>>                                      "-config
>>> dist_m8ball_SUITE_data/main.config"}]}]}.
>>> {init, b, [{node_start, [{monitor_master, true},
>>>                          {boot_timeout, 10},
>>>                          {startup_functions,
>>> [{application,start,[crypto]},
>>>
>>> {application,start,[m8ball]}]},
>>>                          {erl_flags, "-pa
>>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ "
>>>                                      "-config
>>> dist_m8ball_SUITE_data/backup.config"}]}]}.
>>>
>>> And I start it with:
>>>
>>> $ erl -name ct -pa ../ebin/
>>> Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0]
>>> [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G)
>>>
>>> (ct@REDACTED)1> ct_master:run("m8ball_dist.spec").
>>>
>>> And whenever I use ct:pal("~p",[application:which_applications()]) in
>>> the suite, I get [] as a result. Further inspection shows that the
>>> distributed applications I have are read by the controllers, but stdlib and
>>> kernel are not started.
>>>
>>>
>>> On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar <spawn.think@REDACTED>wrote:
>>>
>>>> Hi Fred,
>>>> 1- How do you start the ct_slave nodes?
>>>> (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]).
>>>> {ok,testnode@REDACTED}
>>>> (ct@REDACTED)2> rpc:call('testnode@REDACTED', application,
>>>> which_applications,[]).
>>>> [{stdlib,"ERTS  CXC 138 10","1.17.5"},
>>>>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>>>>
>>>> 2- You can use erl_flags to specify more options to your slave node,
>>>> e.g:
>>>> (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s
>>>> mnesia"}]).
>>>> {ok,testnode1@REDACTED}
>>>> (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application,
>>>> which_applications,[]).
>>>> [{mnesia,"MNESIA  CXC 138 12","4.5"},
>>>>  {stdlib,"ERTS  CXC 138 10","1.17.5"},
>>>>  {kernel,"ERTS  CXC 138 10","2.14.5"}]
>>>>
>>>>  On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert <mononcqc@REDACTED>wrote:
>>>>
>>>>>  I should specify this problem is something I noticed when using
>>>>> distributed tests based on ct_slave; I would suspect that local tests being
>>>>> run from a shell started manually do not suffer from this.
>>>>>
>>>>>
>>>>> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert <mononcqc@REDACTED>wrote:
>>>>>
>>>>>> I've recently discovered that Common Test appears to not be starting
>>>>>> basic applications such as kernel and stdlib, but it still starts things
>>>>>> like application controllers and whatnot.
>>>>>>
>>>>>> This gives me a few problems because it breaks a few behaviours such
>>>>>> as application:which_applications(), being able to start a few applications
>>>>>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually
>>>>>> starting kernel fails because  a bunch of processes already have that
>>>>>> name).
>>>>>>
>>>>>> It will also play negatively with things like manually calling
>>>>>> application:set_env/3 before starting an application to configure it (after
>>>>>> loading it) as just starting it will overwrite all values, etc.
>>>>>>
>>>>>> This causes me a few problems because it forces me to test everything
>>>>>> below the application level, and I can't automate testing of things like
>>>>>> distributed applications and their failover/takeover mechanisms.
>>>>>>
>>>>>> Is there any workaround for these problems?
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20120213/33c64049/attachment.htm>