Steps:

1../zebrunner.sh backup
2./zebrunner.sh shutdown
3../zebrunner.sh restore

Actual result : There are unnecessary messages about containers after ./Zebrunner. sh restore

./zebrunner.sh restore**
      Your services will be stopped and current data might be lost. Do you want to do a restore now? y/n [n]:y
sudo: unable to resolve host mcloud
sudo: unable to resolve host mcloud
sudo: unable to resolve host mcloud
sudo: unable to resolve host mcloud
MCloud restore succeed.
removing device-Nokia_3-....... containers...
Error: No such container: device-Nokia_3-......
Error: No such container: device-Nokia_3.....-appium
removing device-Samsung_Galaxy_S10-....... containers...
Error: No such container: device-Samsung_Galaxy_S10-R.......
Error: No such container: device-Samsung_Galaxy_S10-R......-appium
removing device-Samsung_S5-4..... containers...
Error: No such container: device-Samsung_S5-4.....
Error: No such container: device-Samsung_S5-4d.....-appium


      WARNING! Your services needs to be started after restore.
      Start now? y/n [y]:y

we already have docker as pre-requisites so this verification step might be removed from roles/devices/tasks/main.yml (line 8)

    "msg": "Failed to import the required Python library (setuptools) on automation's Python /usr/bin/python. Please read module documentation and install in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter"

opencv components is shared in a little bit different way so there is probability that shared mcloud couldn't detect it.
in scope of the ticket we have to find valid script which use FindByImage annotation to detect any control by image and test.

related ticket: zebrunner/mcloud-device#44

1. we have to setup udev rule to start usbmuxd service if iOS device is connected to Linux
   https://github.com/shamanec/ios-appium-docker/blob/a55f4881b15c8e232b1d77835ed21655c56ed708/services.sh#L131

2. integrate iOS devices into the same udev rules as android or in separate file as implemented by @shamanec
   https://github.com/shamanec/ios-appium-docker/blob/a55f4881b15c8e232b1d77835ed21655c56ed708/services.sh#L105

so after running ansible script all whitelisted devices should be registered in udev rules to remove/create containers asap after reconnections. So far for disconnected device our iOS containers constantly restarting...

as we moved ios pairing onto the agent host server we need go-ios utility on the linux agent server as well (#67).
adjust ansible script accordingly

zebrunner-farm.sh script which should be able continue to support existing operations:

1. add device
2. remove device
3. recreate device
   and provide new options:
4. start-all
5. stop-all
6. verify device (?)
7. verify-all (?)

Steps:

1. Run Zebrunner-farm backup
2. cd backup folder

Actual result: The main.yml file is absent in the backup folder after run zebrunner-farm backup

in scope of 2.0 we reorganized http/https and ws/wss detection using PUBLIC_IP_PROTOCOL env var.
it seems like we can remove NGINX related share and ssl.crt/ssl.key as arguments at all. websockify also removed from the stf provider docker image wehre we used such artifacts

Steps:

1. Sudo service usbmuxd stop
2. Open STF

Actual result: STF is active on iOS devices if service usbmuxd is stopped

Expected result: STF should be inactive on iOS devices if service usbmuxd is stopped

for the case when no mcloud server components deployed we can't start device containers because infra docker network not exists.
let' generate it forcibly dueing ansible preparation.

All below files are not used by mcloud-android anymore and should be removed:
docker-compose.yml.original
setup.sh
start.sh
stop.sh
variables.env.original

after improving udev integration we lost capabilitites to manage devices via shell script directly:

(base) build@mcloud:~/tools/vd/mcloud-android$ zebrunner-farm restart <udid>
ACTION: restart
do nothing as device id/udid missed.

we have to adjust logic to combine both manual and udev usage

range of stf ports let's keep for stf only so let's don't use "STF_PROVIDER_MAX_PORT" for websockify

better to start after finishing with zebrunner/mcloud-device#58 because ideal solution is to deprecate and remove websockify at all.

anyway, make sure to change argument later for appium container either registering dedicated port and renaming env var https://github.com/zebrunner/mcloud-android/pull/38/files#diff-5a9ee23bdc597fc3d40c31d96d7bfb94c1ef8692d774d8e91975d4fb8c350526R83

screen ws url pattern should refer onto the mcloud-agent host as this particular instance has access to devices via private network.
screenWsUrlPattern: 'ws://52.7.165.168:80/d/demo.zebrunner.farm/d6afc6b3a65584ca0813eb8957c6479b9b6ebb11/7434/',

in the same manner connecturlPattern already work:
connectUrlPattern: 'demo.zebrunner.farm:<%= publicPort %>',

Dear mcloud team,
I'd like to ask a support related to enhance mcloud, it would be great if mcloud can support to run the test on android emulator.
In the meantime, do we have any workaround solution to deal with it?

Many thanks and best regards,
Binh

as we have both Android and iOS supported by udev we have to rename template file.
note: think about upgrade process, as minimal add manual steps to remove old 51-android.rules

we do generate defaultcapabilities.json for iOS as minimal which include default data for appium per device, for example:

{
  "udid":"$DEVICE_UDID",
  "mjpegServerPort": ${MJPEG_PORT},
  "clearSystemFiles": "false",
  "webDriverAgentUrl":"http://${WDA_HOST}:${WDA_PORT}",
  "preventWDAAttachments": "true",
  "simpleIsVisibleCheck": "true",
  "wdaLocalPort": "${WDA_PORT}",
  "platformVersion": "${PLATFORM_VERSION}",
  "automationName":"${AUTOMATION_NAME}",
  "platformName": "${PLATFORM_NAME}",
  "deviceName": "${DEVICE_NAME}"
}

We have to provide DEFAULT_CAPABILITIES=true to be able to init these values. Also think about similar approach for Android as well.

Without default capabilities it is impossible to run iOS without explicitly adding: udid, webDriverAgent, automationName, and platformVersion

to be able to configure fully trusted connection between iOS devices and Linux server we have to identify requirements and steps to make it happen.
It might be done via Apple Configurator 2 or iMaizing app. Both approaches seems not free...

to fulfil configuration we have to provide valid values for:
STF_TOKEN=
AUTHKEY=
SECRET=

During mcloud setup such values must be prepopulated by secured data: zebrunner/mcloud#115. We have to ask these creds during mcloud-agent setup.
Information howto generate and provide valid STF_TOKEN should be added in readme steps

To solve the issue with "Trust iOS devices" we need to integrate iOS Devices in Supervised mode and for this we need to use the Apple Configurator 2 on Mac OS

1. rename mcloud-android to mcloud-agent (it supposed to be used for both android and ios devices)
2. integrate regular zebrunner.sh with common actions (move most of the common operations from zebrunner-farm which should be able to manage devices only)
3. add dedicated mcloud-grid component as part of the services to have selenium grid as close as possible near the devices (in 2.0+ it might be a must to have several grids per each device lab which is going to be combined on CE level under NGiNC or GGR)
4. add into the default docker-compose stf-processor service to have it also as close as possible near the devices

{"err":"Could not start service:com.apple.instruments.remoteserver.DVTSecureSocketProxy with reason:'InvalidService'. Have you mounted the Developer Image?","level":"fatal","msg":"processcontrol failed","time":"2021-12-09T09:25:08Z"}

https://github.com/zebrunner/stf/pull/263/files#diff-dd2c0eb6ea5cfc6c4bd4eac30934e2d5746747af48fef6da689e85b752f39557R22
and
https://github.com/zebrunner/stf/pull/263/files#diff-e20bab65472b09a5c0acf0c33982552c9f46745b1fdd23a65c76ec33cefb8c3eR23

we have to declare a volume as part of mcloud-agent and push into aws s3 default content... think about re-downloading or symlinking missed images on the fly

example of the implementation:
https://github.com/shamanec/ios-appium-docker/blob/a55f4881b15c8e232b1d77835ed21655c56ed708/services.sh#L131

as of now let's add prerequisite to install and start usbmuxd service to be able to connect iOS devices on Linux. later let's automate install and start of the service if possbile

let's return tag and comment in readme about possibility to reregister new devices faster without ssl etc roles execution

let's organize default pac share and place sample pac file for proxying setup

related ticket: zebrunner/mcloud#94
for mcloud-android default name should be "mcloud-android".
Let's add new parameter into main.yml. And inside readme we should recommend to specify actual physical short city name like NYC

I'd like to see status of each whitelisted device via ./zebrunner.sh status

https://github.com/openstf/stf/blob/master/doc/DEPLOYMENT.md#stf-processorservice

as stf-processor the main horse of the STF let's investigate if it might resolve the issue with distributed setup when in 8-24 hours android screen became gray/unavailable in spite of the fact that ws connection is good.

test single stf-processor per all android devices or independent processor inside every android container.

if we go with a single stf-processor per server it might have sense to investigate posssibility to start local selenium grid for them as well.

1. shutdown existing zebrunner env with mcloud
   device containers are being restarted until new setup appear
2. setup new one with mcloud
3. devices try to start services and connect to grid but fail on

/usr/bin/env: 'node': Too many levels of symbolic links
/opt/start_all.sh: line 65: node: command not found
/opt/websockify/websockify/websocket.py:31: UserWarning: no 'numpy' module, HyBi protocol will be slower
  warnings.warn("no 'numpy' module, HyBi protocol will be slower")
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 174, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.5/runpy.py", line 133, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.5/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/opt/websockify/websockify/__init__.py", line 2, in <module>
    from websockify.websocketproxy import *
  File "/opt/websockify/websockify/websocketproxy.py", line 389, in <module>
    'tlsv1_1': ssl.PROTOCOL_TLS | ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 |
AttributeError: module 'ssl' has no attribute 'PROTOCOL_TLS'
/usr/bin/env: 'node': Too many levels of symbolic links
/usr/bin/env: 'node': Too many levels of symbolic links

let's remove one manual steps and automate pulling appium-device container as part of ansible script

we have to recommend to enable:
Settings -> Developer -> Enable UI Automation
and
Settings -> Safari -> Advanced -> Web Inspector

To be able to reuse dynamic browsermob proxy we have to start jenkins-slave in "host" network mode.
Also on this slave java proxy is started i.e. we have to use proxy_port in reality on slave but declare it on android device just for reference

Test scenario:

1.git clone --recurse-submodule --https://github.com/zebrunner/mcloud-android.git
2.configure main.yml from nano/roles/devices/vars/main.yml
3.Run ansible script
4.docker images -a
5.docker ps -a

Actual result : Device containers don't launch with the same identical images

https://github.com/zebrunner/mcloud-android/blob/bedf208637b529f0de19ddbdd2259c42dbe7eb20/defaults/main.yml#L11

it seems like operations we did b ypython not exists anymore so we can try to remove it completely and test

Steps:

Case 1:

1.zebrunner-farm stop [udid]
2.zebrunner-farm start [udid]

Actual result: The Appium containers don't start after it has been stopped

Note: The same case without [udid]

zebrunner/appium#28

Steps:

1. Run zebrunner-farm shutdown

Actual result : Error:bash: /usr/local/bin/zebrunner-farm: No such file or directory

Note: All docker containers are present

zebrunner/mcloud-appium#64
due to the above changes we have to simplify ansible script as appium already delivered with opencv4nodejs on board

device2docker recreate
adjust code to read and parse correctly full device docker container name.

For now we have to run:
device2docker recreate UDID-Name
but wanna to support
device2docker recreate device-UDID-Name

let's provide default sync script with cron schedule aka every hour which can inspect all device containers and if unheathly or Created or similar is detected just do several attempts to start. If not, think about warn devops engineers about it

zebrunner/mcloud#76

subj

device2docker script can react on udev rules and remove/create containers on device disconnect/connect.
At the same time during development we wanna to have possibility to recreate android device container too often which is rather problematic due to the remote work and pandemic situation.
Please, investigate possibility to recreate container via command line like
/usl/local/bin/device2docker <id>
where id might be device name, existing container id etc (something which uniqie identify device/container to recreate).
device2docker script should identify existing container, collect required parameters, remove existing container and start the same using detected args

we can try to start with independent appium image from hub.docker.com (1.22 or 2.0) and start it in parallel with device container on the same server.
it suppose to combine each device inside single unique docker network and provide stable naming for containers inside aka:
appium
android
etc

Communication between appium and android device should be done via "wi-fi" which is regular tcp/ip connection especially if we talk about single host usage.

Benefits:

1. fully independent standard appium image (ability to improve via custom docker also exists)
2. quick movement to new appium without any build steps in mcloud-appium project which is going to be deprecate
3. potential movement of videorecording on low level (custom appium) with s3 compatible storage integration

Potential negative aspect:

1. lost customization of error messaging we used to provide info about device udid and name for unsuccessful start attempt
2. n/a