GitLab

waiting till it finished setting up (or fails). This is really nice when a
1000 node experiment has gone awry and it is pointless to wait for it to
finish. When we do this, we mark the instance as canceled in the DB, and
then wait for create_instance() to notice it. When it does, it stops
waiting and invokes terminate with a new cancel option at the backend.

wait time to 15 minutes, but watch for progress. Any time a node changes
bump the waiting time above five minutes. Just a start point, lets
see how it goes.

big topologies.

with BADARGS; stitcher always exists with 1, and I've not been able to
fix that.

dashboard page.

to be decrypted using the per-exp ssl keypair we create and store on the
nodes. In this case, you can add this to your rspec in the node element.
You can add as many as you want, use the name attribute. We generate a
random password and encrypt the plain text:

  <emulab:password></emulab:password>

which becomes:

    <emulab:password name="foo" encrypted="true">-----BEGIN PKCS7-----
MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQAxggFMMIIBSAIBADCBsDCBqDELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5
MR0wGwYDVQQKExRVdGFoIE5ldHdvcmsgVGVzdGJlZDEPMA0GA1UECxMGQVBUTEFC
MRcwFQYDVQQDEw53d3cuYXB0bGFiLm5ldDEoMCYGCSqGSIb3DQEJARYZdGVzdGJl
ZC1vcHNAZmx1eC51dGFoLmVkdQIDAs8NMA0GCSqGSIb3DQEBAQUABIGAKeyo7mPO
rHRF2G9t0h8/ALBBh7ChD1zCYvRFi2qvvUIIv/kfCNPhujRfodIYR65dP3tfM+BH
VTRxjJrMYH63m8Fz9KMZlVYn+DhMeiwerqTxvVs823zyxcDrOUzTzzakWmJVSqvl
33Po/7CYZ2iq67ATF1Xym3DsRQbQSuwgzu8wPAYJKoZIhvcNAQcBMB0GCWCGSAFl
AwQBKgQQRw0kmvwhIur/ZlfFbB75qoAQXTKjzwN1HDJW4x5GAcWNPA==
-----END PKCS7-----
    </emulab:password>

which can then be decrypted using the private key to get the plaintext
password.

when there is an error so that we can more easily find it when reviewing
the apt_instance_failures table.

exitcode and the exit message (the one we show to the user). Show the
counts on the dashboard page.

For now, I am not breaking out the errors on the dashboard page. Need
to think about how we break them out, also do we want to show any details
about failures.

the jacks image constraint code is operating nicely.

1. Use information from sliverstatus to indicate that nodes have startup
   execution services running, and then tell then when they have finished,
   and they exited with non-zero status, indicate that they failed. We also
   hold saying the "ready" in the upper panel until all the services have
   exited, we say "booted" instead, and also say that nodes are running
   startup services.

2. For snapshot, when we know an image has to be copied back to its origin
   cluster, tell the web interface, so that we can add another step to the
   imaging modal ("copying"). We know the copy is done when the origin
   cluster has posted the new image data to the IMS, so we do an additional
   poll in the backend waiting for the image server to get the data, and
   then we mark the image as ready for use.

stitcher log file.

by not enough free nodes.

See USEABACCREDS toplevel variable in APT_Geni.

not just the experiment creator.

we cannot get their project list, which causes create_instance to fail.

that and in fact, it needed a change to libaudit. I am still pondering
this, the change I put in needs more thought.

multi-site experiments.

used to make API calls. We use our alternate CA though (valid only in Utah)
since the key is unencrypted.

private key.

The goal is to distribute an experiment wide certificate and private
key. At the moment this is just a self signed x509 certificate and the
accompanying rsa key. In PEM format. The same cert/key will be distributed
across multiple aggregates.

An openssh key pair can be trivially derived from the private key. Or the
public part can be derived from the certificate. A quick google will show
show.

Initially, you will need to run tmcc directly to get them, using the
geni_certificate and geni_key commands.

is just like importing images (by using a url instead of a urn), which
makes sense since image backed datasets are just images with a flag set.

Key differences:

1. You cannot snapshot a new version of the dataset on a cluster it has
   been imported to. The snapshot has to be done where the dataset was
   created initially. This is slightly inconvenient and will perhaps
   confuse users, but it is far less confusing that then datasets getting
   out of sync.

2. No image versioning of datasets. We can add that later if we want to.