max / alloy
| 1 | # Shared settings for the layertest scripts. Sourced, not run. |
| 2 | # |
| 3 | # The ports differ from anything else on a dev box on purpose: vmtest already |
| 4 | # forwards ssh to 2222, and running both harnesses at once should not need a |
| 5 | # conversation about which one owns a port. |
| 6 | |
| 7 | HERE="" |
| 8 | STATE="" |
| 9 | |
| 10 | IMAGE=localhost/alloy-layertest |
| 11 | REGISTRY_PORT=5000 |
| 12 | REPO_PORT=8080 |
| 13 | SSH_PORT=2223 |
| 14 | |
| 15 | # Under qemu user networking the host is 10.0.2.2 from inside the guest. Both |
| 16 | # the RPM repo and the registry are reached through it. |
| 17 | HOST_FROM_GUEST=10.0.2.2 |
| 18 | |
| 19 | # The variants, as mark:shape:version. |
| 20 | # |
| 21 | # n1 through n4 are the upgrade sequence, and they are the run that answers the |
| 22 | # question. n1 and n2 do not carry the component, so the hotfix is a layered |
| 23 | # package; n3 carries it at the hotfix version (the base has caught up) and n4 |
| 24 | # carries it one version further on (the base has moved ahead). |
| 25 | # |
| 26 | # r1 and l1 are not part of that sequence. They exist to reproduce the two dead |
| 27 | # ends: a component that is a base RPM cannot be replaced, and a component that |
| 28 | # is an unowned file cannot be layered over. |
| 29 | # |
| 30 | # c1 and c2 are the shape Alloy actually takes: the image carries the RPM as a |
| 31 | # file in a file:// repo and does not install it. c1 carries 0.0.2 and c2 |
| 32 | # carries 0.0.3, so c1 -> c2 is "the image shipped a newer component" and the |
| 33 | # question is whether a machine's layer follows it without the n4 conflict. |
| 34 | VARIANTS=( |
| 35 | "n1:none:" |
| 36 | "n2:none:" |
| 37 | "n3:rpm:0.0.2" |
| 38 | "n4:rpm:0.0.3" |
| 39 | "r1:rpm:0.0.1" |
| 40 | "l1:loose:0.0.1" |
| 41 | "c1:carry:0.0.2" |
| 42 | "c2:carry:0.0.3" |
| 43 | ) |
| 44 | |
| 45 | |
| 46 | |
| 47 |