Demo UI proposal

[ncoghlan]

The current demo is hardcoded to migrate from a particular local VM hostname to a particular target VM hostname. The demo is also hardcoded to assume a particular port will be exposed on the target machine, and it implicitly deletes all previously migrated macrocontainers from the target machine when doing a migration.

These limitations combine to make it difficult to conduct a fluid demo that covers multiple different migration scenarios.

Changing that requires at least the following:

1. A way of choosing the target machine
2. A way of choosing the source machine
3. A way to trigger a migration from the chosen source to the chosen target
4. A way to explicitly clear previously migrated containers from the target machine
5. A way to customise the ports exposed post migration

My proposal for handling the first three points would be to do the following:

• split the machine listing into two different tables:
  • a "Target" table, listing the machines with "target" in their name
  • a "Source" table, listing the remaining machines
• in the Target table, include a radio button selector as the leftmost column for choosing the destination machine (first in list selected by default)
• in the Source table, include an Actions column as the rightmost column, with a Migrate button in each row

For the fourth point (assuming the above changes):

• move the clearing of previously migrated macrocontainers to the Ansible provisioning playbook for the target VM
• add an "Actions" column with a "Reprovision" button to the Target VM table
• (optional) for consistency, also add the Reprovision action to the Source VM table

For the final point (assuming the above changes):

• the best I've come up with so far is to just have an optional text box in each Source row to specify --tcp-port arguments to migrate-machine as a comma-separated list (defaulting to 9000:9000 to match the current demo app)

[ncoghlan]

A couple of possible simplifications to the above:

1. Keep centos7-target as a hardcoded target for now. This means being able to skip the radio selection buttons and the UI logic to pass the selected target to the migration command, and may be worth doing, since we don't have any current plans or questions that would require a demo with multiple target VMs.

2. For the initial restructuring of the UI, keep centos6-app-vm as the only supported source, and then update the Migrate button to be row dependent later. This seems less beneficial, since we already know we want to handle multiple source VMs in a single demo session, so there's no chance of a "maybe we'll never need it" outcome.

[ncoghlan]

A solid argument in favour of allowing selectable targets: it pre-empts the question of "Can I choose a different target?" :)

[ncoghlan]

Adding a note prompted by @pcahyna: as part of this, we should add an integration test that actually starts the demo.

Some complications that brings beyond any of the current integration tests:

• the VMs should be started using the "demo/vmdefs.sh" script, not directly by the test harness
• Cockpit will need to be installed and running on the host running the tests
• the LeApp checkout will need to be symlinked into the Cockpit instance (as described in the README)
• we'll need to pick a web UI testing client (hopefully we can just use the same client that Cockpit uses for their testing)

[ncoghlan]

@podvody looked up what Cockpit uses, and it's PhantomJS: https://github.com/cockpit-project/cockpit/blob/master/test/common/phantom-command

Looking at https://github.com/dhamaniasad/HeadlessBrowsers doesn't give me any reason to question their choice, so I think we should run with it as well.

[ncoghlan]

A bit of research into the current state of the art for PhantomJS based testing from behave brought me to Nicole Harris's write-up here: http://whoisnicoleharris.com/2015/03/19/bdd-part-two.html

Her recommendation is to use http://splinter.readthedocs.io/en/latest/index.html as a higher level abstraction layer over Selenium & PhantomJS, and that seems like a good idea to me.

[ncoghlan]

I spent some time looking at/thinking about the automated testing problem this morning, and I think it's tricky enough that it should be separated into its own issue: https://github.com/leapp-to/prototype/issues/46

Specifically, consider the suggested basic test scenario that just goes to the plugin page and checks it renders within a certain time limit:

Given that the Cockpit service is running on the testing host # skip scenario if not
  And the demonstration plugin is installed # ensure appropriate symlinks are in place
  And the demonstration user exists  # create unique-to-the-test-run user (destroy at end)
  And the demonstration VMs are running  # run demo/start_vms.sh as the demo user
When the demonstration user visits the Kernel Flexibility page
Then the local VMs should be listed within 15 seconds

While all of that is feasible (given that the tests will be run either as root, or by a user with sudo access), adding the required testing infrastructure and step definitions is all orthogonal to the actual changes we want to make to the demo itself.

[mfranczy]

Regarding to fourth point of this issue:

A way to explicitly clear previously migrated containers from the target machine

For the fourth point (assuming the above changes):

move the clearing of previously migrated macrocontainers to the Ansible provisioning playbook for the target VM

Maybe it would be better to implement destroy-container within leapp-tool than clear previously migrated containers by Ansible playbooks.

It should be quick to implement, how I see it: leap-tool destroy-container centos7-target

I could take docker rm command from start_container function https://github.com/leapp-to/prototype/blob/master/src/leappto/cli.py#L90 and then add new destroy_container function

What do you think?

[ncoghlan]

@mfranczy The main downside I see to that is that the affected test cases would need a new "Given" step to see "And any existing macrocontainers on {target} have been destroyed".

That's not a big downside though, since we don't have many test cases at this point, so if it's easier than the Ansible option, go for it.

We can always refactor it again later if we decide we want to.

[ncoghlan]

Closing this based on the layout updates in #51 that switched to a two-column layout with source selection on the left and target selection on the right.