GitLab

(This var just had to be defined for the blockstore case.)

This has support for generating arguments to AddNodes() and
DeleteNodes(), which means re-reading the current manifest to know what
the original parameters were, so that the appropriate args (like which
image, which lans to join, etc) go to AddNodes().

This was to try to solve the performance problem; no luck here.

Liberty didn't seem to like the disable_vnc flag to Nova on aarch64 that
we relied on so that images would boot.  Fortuitously, qemu/libvirt have
been upgraded enough so that you can actually attach a VGA adapter to an
aarch64 KVM qemu instance.  So we do that, and now we mark images with a
specific flag that says to use the vga display driver instead of the
'cirrus' default, which qemu/libvirt aarch64 does *not* support.

Probably I should just find a way to fix the vnc disablement :).

Apparently oslo.service handles stop signals (like those from systemd)
in a bad way.  When systemd stops a service, it can drive the service
into an exception (in one of its threads, I think) and I assume systemd
waits until its timeout and then kills it more firmly.  This patch went
in to oslo.service 1.2.0 or so, but of course we're stuck back in the
stone age still, around 0.9 or whatever.  So apply the patch, stupid.
We start and stop services a lot as we're setting up.

Memcache + Keystone + WSGI/Apache seems to cause a problem where
Keystone is effectively unavailable (internal errors) for about a
minute... then it comes back by itself.

So we disable it by default.  The docs default to using it, but this is
far from the first time the doc defaults trigger bugs or are simply bad
configuration!

Add Liberty support.

Add keystone v3 support.  Now you can choose which version of keystone
to run... all combinations tested exception Juno with v3.

Make node type and link speed configurable.

Make token and session timeouts much longer by default (so people don't
get logged out so quickly), but also configurable.

Keystone is now served by WSGI through Apache on Kilo and Liberty.

Memcached keystone token caching is disabled for now; it causes
intermittent problems; so using SQL for now.

Add localhost to /etc/hosts file.  This doesn't cause problems anymore,
if it ever did.

We now use the `openstack' CLI command for >= Kilo, instead of the
per-service client CLI tools.

Stick with ovs agent even in Liberty -- even though the default is now
linuxbridge, it seems.

In general, get rid of nearly all the rest of the cat <<EOF ... EOF
stuff and replace it with crudini --set/--del.  A touch slower, but much
cleaner.

Also in general, improve the Kilo support so that it more closely
matches the docs.

If you instantiate a portal expt on Emulab (where you might have a real
account), the swapper is you, not geniuser.  So, check geniuser via
geni-get slice_urn success/failure.

Also, adds a geni-lib script that generates an rspec instead of printing
it (although print still works at portal) and generates input for
CM::AddNodes() when requested.  This generator is stateful; it tries
to avoid generating new nodes with previously-used IPs or client_ids;
thus it is a separate object.  It is designed so that it can be imported
into a script, and the importing script can look for special
DYNSLICE_GENERATOR variables to use its rspec foo to create a slice and
add nodes in some semantic way.

We want to use only local AM tmcd info in this case...

(Of course this will suffer from the problem of the limited tmcd buffer
for getmanifest.)

This is the fallback if we don't get an encrypted passwd from the
manifest.

Quit trying to apt-get packages if they're installed, unless the
user selects the new DO_APT_UPGRADE option.  Always install was nice
in the beginning, but it is no longer the best use case, and it can
cause uncertainty when failures happen (i.e., if new versions of
packages get installed that the scripts can't handle).  So now there
are three apt options in the scripts and in the geni-lib script:

DO_APT_UPDATE -- updates the apt cache (often hard to do pkg
  install/upgrade if the cache is out of date); defaults to 1
DO_APT_INSTALL -- if this is set 0, we don't install *anything*
  other than critical deps (think python-m2crypto); defaults to 1
DO_APT_UPGRADE -- if this is set 1, we always run apt-get install
  to either install and/or upgrade OpenStack packages and deps.
  The big change is that this now defaults to 0 -- so packages are
  not upgraded from their current versions if they exist.

Not sure why I did this... hopefully it still works for Juno this
way.

Hm, I have no idea why this is happening again, but whatever.
I previously fixed it on x86_64, now on aarch64.  Strange...

Mostly, we keep trying to start the app until it succeeds.  It seems
that the server needs some time to get started before it's safe to
start up the app.  Could be as long as 5-6 seconds.  We (and openstack)
can't do anything if the app isn't running in the server.

There's a fallback to this too -- if for whatever reason, we don't get
a password, we generate a random one and email it to the user.  Not
perfect, but still better than letting a null passwd through.

Also, on x86_64, make sure ubuntu user is in the VM image passwd
file, so that our fixed passwd is meaningful.

So far only have to handle utopic.