Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »


  1. I'm getting an error about "UnmanagedComponent" saying that a DPID is "unknown to this aggregate", but I'm sure it's a valid DPID!

    One common cause of this is that the datapath URN format changed in FOAM 0.6.2, to have a plus character between the word "datapath" and the DPID rather than a colon character. They should now look like


    To update your rspecs, do something like

    sed -i -e 's/\+datapath:/+datapath+/' thing-1.rspec thing-2.rspec ...

    If that doesn't help, you may in fact have a typo in your rspec – compare it very carefully to the output of listresources from that aggregate.

  1. All requests from Omni return "400 Bad Request"
    This typically means that your SSL client certificate is signed by a CA that the FOAM application server (usually nginx) isn't configured to trust. If the CA cert was installed for FOAM, this can usually be resolved by running sudo foamctl bundle-certs and restarting nginx.

  2. All requests from Omni fail with "Couldn't validate credential for caller [...] with target [...] with any of 1 known root certs"
    This typically means that your SSL client certificate is signed by a CA the FOAM application server (usually nginx) is configured to trust, but FOAM itself isn't configured to trust. This can happen if the admin has added certificates and restarted nginx, but not restarted FOAM; or if the admin has removed certificates and restarted FOAM, but not nginx.

  3. All requests from Omni fail with "Couldn't validate credential for caller [...] with target [...] with any of 1 known root certs: can't compare offset-naive and offset-aware datetimes"
    This often means that you have installed FOAM on a machine that previously had Expedient installed and there are old "geni" and "sfa" libraries in your PYTHONPATH (in dist-packages somewhere).  You need to remove these old libraries so that the ones shipped with FOAM can take precedence.

  4. Omni calls fail with "502 Bad Gateway"
    This typically means that the application server is running, but FOAM is not.

  5. Omni fails with "class 'lxml.etree.DocumentInvalid'>:Element '{\}rspec': No matching global declaration available for the validation root."
    This is an example of an rspec parsing error; the rspec schema validator is saying that your rspec seems invalid. In this particular case, it's because FOAM only supports GENI v3 rspecs, and does not support ProtoGENI v2 rspecs.

  6. foamctl fails with "Basic auth failed: invalid password" but my password is correct
    This can happen if nginx is running and FOAM is not.

  7. I can reserve ports that aren't advertised!
    This isn't actually an error: Due to the ephemeral nature of ports (especially virtual ones such as those configured as tunnel endpoints) you are permitted to reserve a port which may not currently exist, but which may exist in the future.

  8. I tried to approve a sliver, but got an error, but when I checked, the sliver did get approved. So I guess it worked?
    Only sort of: If you get an error with foamctl geni:approve-sliver, chances are the sliver will be marked as approved (i.e. FOAM thinks an admin has said "I want to approve this"), but not enabled (i.e. active in the FlowVisor). Check closely; and pay attention to the error condition, and see if it makes sense (e.g. if it says FlowVisor is down, or a slice already exists with that controller, or some such, that's worth investigating). And if you get an error about something that you can't fix yourself, consider reporting it as a FOAM bug.

  9. Omni fails with "(OperationalError) database is locked".
    If this happens once, retry the command; if the second time succeeds, it's probably the issue described here. If it happens consistently, something else may be wrong, and you should drop a note to the FOAM admin.

  10. Omni returns an error "Fault 1: "<type 'exceptions.TypeError'>:'NoneType' object is unsubscriptable"", but the operation seems to have succeeded.

    This typically means that e-mail hasn't been configured in FOAM. This can generally be resolved by running foamctl config:setup-email.

Known Issues

  1. Controllers of types other than "primary" have no effect
    Flowvisor doesn't currently natively support either backup or monitor controllers. These functionalities will likely be emulated in a future release of FOAM.

  2. I can't figure out how to extend the maximum lease time for slivers at my aggregate

    You can do this with foamctl(the value is in hours):

Migration from Expedient

  1. Is there an opt-in manager?
    No. Slivers created by experimenters require approval, which may be automatic in some cases, or require manual approval from a FOAM admin in others. There is no support for end-user opt-in yet.

  2. Where's the web interface?
    FOAM has a web-services interface that speaks multiple APIs; there isn't a human-friendly web UI yet, although in principle anyone could create one, communicating with FOAM via one of the APIs.

  3. How do I use the command-line interface?
    See the foamctl docs for more details.

  4. Can I run FOAM and Expedient at the same time, managing a shared FlowVisor?
    Not on the same machine, at least not at the moment. You can run them on separate machines, if you don't mind the complexity of having a single FlowVisor controlled by multiple aggregate managers (e.g. neither Expedient nor FOAM will have a complete view of the FV slices, flowspace, etc).


  1. I've installed FOAM, how do I test if it's working? When I browse to, I don't get anything useful.
    FOAM doesn't have an HTML interface, so there's nothing useful to see with a web browser. You may want to test the GENI AM API interface; you'll need GENI credentials for that. (Contact if you need more information about how to do that.)

  2. SSL client verification keeps failing, and I need more information to figure out why

    If you add the following line to your /etc/nginx/sites-enabled/foam.conffile, you can generate a significant amount of debug output from nginx that will give you all the verification data from the client certificates:


  1. Why does FOAM installation require a compiler?
    In order to support older systems the package installation will build some dependencies for you rather than installing the older (incompatible) binary packages that may be provided by some systems.

  2. Does FOAM require nginx?
    No. FOAM is a WSGI application that can be served from any WSGI-compliant application server. However, FOAM does require the use of SSL and an application server which can validate client certificates. The default installation uses FastCGI with nginx, however it could be configured to work with Apache httpd and mod_wsgi, and possibly other application servers.

  3. Why are there certs in two places?
    The files in the /opt/foam/etc/gcf-ca-certs directory are used by FOAM; the sudo foamctl admin:bundle-certs command puts them into a single file, in the format that the nginx front-end uses (in /etc/nginx/ca-certs/foam-ca-certs.pem).

  • No labels