-
Notifications
You must be signed in to change notification settings - Fork 15
Omni Troubleshooting
For help troubleshooting issues with Omni or Stitcher, see https://groups.google.com/forum/#!forum/geni-users, and ask a question there if you don't find a solution to your problem.
Subscribe to the geni-users google group
Information is available in the guide to contributing to geni-tools.
Every time Omni contacts an Aggregate or your clearinghouse, it needs to unlock your passphrase-protected private key. For security reasons, Omni does not store your key.
Some users may find the following script helpful, thanks to Chris Benninger.
This is a simple shell wrapper script to keep a user from having to continuously enter their Passkey when using Omni. Just pass in the omni command you want to run in quotes as a parameter to the script. Note: The expect command used within the script does not have a large enough buffer to handle all the output to stdout, so if you don't want the output truncated use the -o flag and write out to file.
Dependency
-
Expect - The scripts requires the expect commandline utility. On Ubuntu and Debian the package is simply named 'expect'. To install, type:
sudo apt-get install expect
Usage
./epasswd.sh "python omni.py -t geni 3 listresources -c ~/.gcf/omni_config -o"
You will be asked for your password once, and any further matching prompts will be entered by the script for you.
epasswd.sh script to only enter your passphrase once
Save this as epasswd.sh.
#!/bin/sh
exists()
{
if command -v $1 &>/dev/null
then
return 1
else
return 0
fi
}
#Make sure we have expect
exists expect
if [ $? -le 0 ]
then
echo " This script requires the 'expect' commandline tool. Please install it."
echo " If you are on Debian or Ubuntu, install it with:"
echo " sudo apt-get install expect"
echo " Then rerun this script"
exit 1
fi
#Start
stty -echo
read -p "Enter PEM pass phrase:" PASS
stty echo
cmd=$1
expect -c "
spawn $cmd
stty -echo
expect {
-re \"Enter PEM pass phrase:\" { send \"$PASS\r\"; exp_continue }
}
stty echo
wait
exit
"Your username URN is needed for omni configuration to define the credentials to be used with the clearinghouse. The URN can be found with the following command:
$ openssl x509 -noout -text -in ~/.ssl/encrypted.pem | grep 'urn:publicid'
URI:urn:publicid:IDN+pgeni.gpolab.bbn.com+user+lnevers, email:[email protected]
Make sure to remove the leading "URI:", with the above example, the urn is ''urn:publicid:IDN+emulab.net+user+lnevers''.
Keep a passphrase on your certificate for security best practices. If you just want a way to type your passphrase only once per session look here.
If you are using ProtoGENI as your clearinghouse, then you you have probably downloaded a pem file which contains both your certificate and your private key. The encrypted certificate must be passphrase protected and should be downloaded into the ''~/.ssl '' directory.
If you are using Planetlab as your clearinghouse then you have probably downloaded your certificate in a gid file. The difference here is that the gid file contains only your certificate and thus you will need to have a cleartext version of your private key.
Omni comes with a script clear-passphrases.py that you can use to remove the passphrase from your cert and/or private key. User clear-passphrases.py -h to see how to specify which cert and which keys you want to clear. If you used the omni-configure.py script to configure omni, you can simply run the clear-passphrases.py script with no arguments.
You can validate both your RSpec against the base schema and the extensions, using rspeclint (which is part of the GENI RSpec repository, posted here. rspeclint relies on the LibXML Perl module from CPAN. On Ubuntu Linux this is the libxml-libxml-perl package ("apt-get install libxml-libxml-perl").
For instructions on using rspeclint and other RSpec debugging tips, see
this ProtoGENI wiki page.
Alternatively, try running xmllint (which is part of libxml2).
EG:
xmllint --noout myRequestRSpec.xml
And if you know what type of RSpec you are generating, you can validate it against the schema.
For GENI v3::
xmllint --noout --schema http://www.geni.net/resources/rspec/3/request.xsd myGENIV3RequestRspec.xml
If your RSpec uses an extension, use rspeclint to validate against both the base schema and the extension.
Currently only one user can have access to the resources, but you can give access to multiple users, by adding their public keys, to the keys that are installed in the compute resources when the slivers are created. In this way all the users can have access to the resources sharing the same account, but still use different keys. You will need to modify the omni_config file. Basically the only change that is needed is in the Users section, change the keys entry to be a comma separated list of all the public keys that need to be installed.
[omni]
default_cf = pgeni
users = alice
# ---------- Users ----------
[alice]
urn = urn:publicid:IDN+pgeni.gpolab.bbn.com+user+alice
keys = ~/.ssh/user1_id_rsa.pub, ~/.ssh/user2_id_rsa.pub
If you have already created a sliver, you would need to delete the sliver and recreate it in order for the change to take effect.
First, make sure you have users listed under users in your omni_config (see example below).
Second, make sure that you are using the correct private key. The private key used should be the one that corresponds to the public key that you specify in your omni config file. For example if you have a user <geniuser> in your omni config like this:
[omni]
<snip>
users = geniuser
[geniuser]
<snip>
keys = ~/.ssh/gcf_id_rsa.pub
Then the private key to use when trying to login to your nodes would be the key that corresponds to gcf_id_rsa.pub key (eg ~/.ssh/gcf_id_rsa).
If you are sure that the key used is the correct one, check your user urn. In your omni_config file you can find the urn at:
[omni]
<snip>
users = geniuser
[geniuser]
<snip>
urn = urn:publicid:IDN+pgeni.gpolab.bbn.com+user+geniuser
In ProtoGENI, the urn used when creating your slice, should match exactly the urn on your credential. To figure out what is the urn in your credential file check here.
A. If you've had your account for a while, your user certificate may have expired.
Do you get an error like this?
[Errno 1] _ssl.c:480: error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired
You can confirm your certificate is expired by using this command to find your certificate validity dates:
openssl x509 -in ~/.gcf/my-user-cert.pem -dates -noout
ProtoGENI users should log in to their account at the ProtoGENI website and create and download a new certificate.
PlanetLab users should email PlanetLab support ([email protected]) to get a new user certificate.
First of all keep in mind that renewing you slice will not automatically renew your existing slivers,
but you will have to manually renew them.
Also, when you create a sliver with an AM, in most cases the expiration of your sliver will not exceed the expiration of your slice, but it might be shorter.
For ProtoGENI AMs the expiration time of the sliver is the same as the once of the slice as long as it is not exceeding a maximum sliver lifetime policy of the AM. In this case, immediately renewing your sliver won't have any effect. However, when you get close to the expiration time you can renew your sliver.
For PlanetLab AMs all slivers default to a maximum of two weeks expiration time. However in PlanetLab you can renew the expiration of your sliver immediately.
The best way to figure out the exact expiration time of your sliver is to run sliverstatus and look for an '*_expires' attribute in the response.
Omni 2.0+ uses AM API v2 by default. Omni2 will also default to using GENI v3 format RSpecs. As a result, no special action is required to use Omni v2 with AM API v2 aggregates. However, for AM API v1 aggregates (like FOAM), see below.
In earlier versions of Omni, Omni defaults to AM API version 1.
Most aggregates now use GENI AM API version 2. AM API versions 1 and 2 are not compatible.
If you want to or are required to use AM API version 2, and cannot update to Omni v2, then you must supply the optional argument --api-version 2. For example, PlanetLab now requires AM API version 2.
Additionally:
Starting with AM API version 2, Omni users must explicitly specify the version of RSpecs that they want to use with ListResources. Omni v2 will default to GENI v3 RSpecs, but earlier versions do not provide a default. In AM API version 1, Aggregates had a a default RSpec format, but that is no longer true in AM API version 2. So you must use the -t option to specify an RSpec type and version # when using Omni v1.6.2 or earlier. For example: -t geni 3.
For example:
An AM API version 2 call to ListResources using Omni v1.6.2 might look like:
python src/omni.py listresources --api-version 2 -t geni 3
An AM API version 2 call to CreateSliver might look like:
python src/omni.py --api-version 2 -a http://www.planet-lab.org:12346 createsliver myslice myRequestRspec.xml
This answer applies if you are using Omni v1.6.2 or earlier, and get an error like this:
$ python src/omni.py -a http://www.planet-lab.org:12346 listresources
....
Result Summary: Got no resources. No resources from AM http://www.planet-lab.org:12346: : ListResources:
Invalid argument: Must specify an rspec version option. geni_rspec_version cannot be null
This error doing ListResources (at PlanetLab or any aggregate) indicates that the aggregate requires the named option, and you did not supply it. To supply this option, use the -t argument to specify an RSpec type and version.
This option is required in GENI AM API version 2, so this aggregate is likely talking AM API version 2. Be sure to follow the instructions on using AM API v2 with Omni.
This answer applies if you are using Omni v1.6.2 or earlier and get this error:
$ python src/omni.py -a http://www.planet-lab.org:12346 listresources -t geni 3
....
WARNING:omni:AM GetVersion has no ad_rspec_versions key for AM unspecified_AM_URN [http://www.planet-lab.org:12346]
....
Result Summary: Got no resources. AM http://www.planet-lab.org:12346 did not advertise RSpec versions
This error doing ListResources (at PlanetLab or any aggregate) indicates that the aggregate is using GENI AM API version 2, and Omni was using AM API version 1. You should update to Omni v2, or supply the option --api-version 2 to all Omni calls with this aggregate, to use GENI AM API version 2. Follow the instructions on using Omni with AM API v2 aggregates.
If you are using Omni v1.6.2 or earlier and get errors that look like this, then this answer applies:
$ python src/omni.py -a http://www.planet-lab.org:12346 createsliver ahtest ./req.xml
....
Asked http://www.planet-lab.org:12346 to reserve resources. No manifest Rspec returned. : CreateSliver: Expected 5 arguments, got 4
or
Failed to get SliverStatus on ahtest at AM http://www.planet-lab.org:12346: : SliverStatus: Expected 3 arguments, got 2
or
Failed to renew sliver urn:publicid:IDN+plc:bbn+slice+ahtest on unspecified_AM_URN (http://www.planet-lab.org:12346) : RenewSliver: Expected 4 arguments, got 3
or
Result Summary: Failed to delete sliver urn:publicid:IDN+plc:bbn+slice+ahtest on unspecified_AM_URN at http://www.planet-lab.org:12346 : DeleteSliver: Expected 3 arguments, got 2
This error (at PlanetLab or any aggregate) indicates that the aggregate is using GENI AM API version 2, and Omni was using AM API version 1. You should update to Omni v2, or supply the option --api-version 2 to all Omni calls with this aggregate, to use GENI AM API version 2. Follow the instructions on using Omni with AM API v2 aggregates.
A. Try the google group archives at https://groups.google.com/forum/#!forum/geni-users
If you don't find your answer there please post a question to the geni-users google group and include the following information:
- The exact command you are trying to run including any error messages.
- Output from rerunning the command with the "--debug" option turned on.
- A copy of your omni_config.
- A copy of your cert (eg ~/.gcf/plc.bbn.sedwards.gid in the above examples).
Q. I tried running a command at a ProtoGENI AM and it hung a long time and then gave me an error. (This used to work.)
Check the port in the aggregate URL you are trying to connect to.
Note that in Dec 2012, Emulab/ProtoGENI switched to using port 12369 instead of 443.
Here are instructions about the change.
Here's an example of trying to run getversion against a wrong port (12368 not 12369)...
$ src/omni.py -a https://www.emulab.net:12368/protogeni/xmlrpc/am/2.0 getversion
INFO:omni:Loading config file /home/geniuser/.gcf/omni_config
INFO:omni:Using control framework pg
ERROR:omni.protogeni:Call for GetVersion at https://www.emulab.net:12368/protogeni/xmlrpc/am/2.0 failed.: Unknown socket error: [Errno 110] Connection timed out
ERROR:omni.protogeni: ..... Run with --debug for more information
WARNING:omni:Couldnt get api version supported from GetVersion: AM https://www.emulab.net:12368/protogeni/xmlrpc/am/2.0 failed getversion (empty): [Errno 110] Connection timed out
ProtoGENI uses ssh keys as an authentication mechanism. If you are prompted for
a password that probably means that there is a problem with the ssh keys that
are loaded to the hosts. The keys that are loaded in the hosts are specified in
your omni_config file. For each user that is specified in the omni_config file
there is an attribute called keys that is a comma separated list of public keys.
These are the keys that are loaded to the host and not the key that is specified
in the different control framework sections.
Make sure that :
- the path to the key you are using is correct in the omni_config file
- that you have specified the path to the public key and not to the private one of the pair.
- that you are using the private key to login (you might need to use the -i option in the ssh command)
The .pem file that is downloaded from the Web UI, is your user's certificate that is used to authenticate you with the clearinghouse, this file should not be used to login to any of the nodes. For further instructions on how to upload ssh keys to your hosts read here
A. ProtoGENI slice credentials format times in a way that older SFA (pre- June 2011 / SFA 1.0-27) cannot handle. You have two options
- Use a different slice authority, like PLC or pgeni.gpolab.bbn.com which may format dates differently.
- Contact the admin of the MyPLC aggregate, and have them update their SFA code.
A. As of AM API v3, and earlier at ProtoGENI aggregates, slice names are restricted:
- at most 19 characters
- contain only the following characters: a-z,A-Z,0-9,-
- A slice name can not start with '-'
Note: The '_' character can not be used.
For AM API v3 slice name restrictions, see: https://github.com/GENI-NSF/geni-docs/blob/master/GeniApiIdentifiers.adoc#name
Omni v2.0+ will check these restrictions for you.
A. ProtoGENI and AM API v3 have restrictions on what the slicename can be. Please look here for valid slice names in PG and AM API v3.
Omni v2.0+ will check these restrictions for you.
As of January 4, 2012 and SFA version 2.0-7, PlanetLab aggregates (PLC, PLE, and others) support only GENI AM API version 2. AM API version 1 is no longer supported by those aggregates. Omni users attempting to reserve resources from PLC and PLE aggregates must use AM API version 2, as described here.
Note that MyPLC installations may not have updated, and so may still use AM API v1 only. This includes the mesoscale campuses in particular.
A. Make sure you have used the right slice name. There are two common issues:
-
The slices as listed on your account at https://www.planet-lab.org/ are of the form '<site_name>_<slice_name>'.
When you specify the slice name in the omni client you should omit the '<site_name>_' part.
For example a slice that is part of the 'bbn' site is listed on the Planetlab web UI as 'bbn_slicename', but when using the omni client the actual slice name is 'slicename'.
-
You specified the slicename of the form
plc.<site_name>.<slice_name>(egplc.bbn.sampleslice). Use only<slice_name>instead (eg.sampleslice).
A. Look up the filename you have listed for your planetlab cert.
The cert is listed in your omni_config as follows:
[plc]
<snip>
cert=~/.gcf/plc.bbn.sedwards.gid
Run the following command on that file:
> openssl x509 -in ~/.gcf/plc.bbn.sedwards.gid -text
Look at the output:
Certificate:
Data:
Version: 3 (0x2)
<snip>
X509v3 Subject Alternative Name:
URI:urn:publicid:IDN+plc:bbn+user+sedwards, URI:urn:uuid<snip>
If the X509v3 Subject Alternative Name does not contain the string "+user+" then, contact [email protected] for support. Please include a copy of your user cert (eg ~/.gcf/plc.bbn.sedwards.gid). This indicates a problem at Planetlab.
If "Version" says 1 instead of 3, you need to download your cert from planetlab again.
-
Move your cert out of the way:
mv ~/.gcf/plc.bbn.sedwards.gid ~/.gcf/plc.bbn.sedwards.gid.old -
Set the value of "key" in your omni_config to point to the private key that corresponds to to the public key that you uploaded to your account on planetlab.org.
[plc] <snip> cert=~/.gcf/plc.bbn.sedwards.gid key = ~/.gcf/pl_id_rsa1 -
Run:
omni.py -f plc getversionThe "-f plc" is to make sure you are using the planetlab control framework. Adjust appropriately to be consistent with the configuration in your omni_config.
-
When asked if you want to download your certificate, say "Y".
A. You get an SSL error that looks like the following:
SSLError: [Errno 1] _ssl.c:480: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message
This means one of two things:
-
the value of
keyin youromni_configisn't consistent with your PL User gid file.You may find the steps 1-4 here helpful.
-
You've encountered a rare PL error. Follow the steps here to see if the credential is for a slice instead of a user.
A. There are a couple of things that might be wrong:
-
If you get an SSL error you might have mistyped your passphrase, so try again. Example error messages you might see if you mistyped your passphrase include the following:
[Errno 336265225] _ssl.c:337: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM libOpenSSL.crypto.Error: [('digital envelope routines', 'EVP_DecryptFinal_ex', 'bad decrypt'), ('PEM routines', 'PEM_do_header', 'bad decrypt')]If you want to remove the passphrase from your key, check [wiki:OmniTroubleShoot#Q.Iwanttoremovethepassphrasefrommyprivatekey here].
-
If you are sure that you are typing the passphrase correctly, then you might be using the wrong key. If you have uploaded more than one public key to your account on planetlab.org, then your credential might have been created with any of those keys. This includes ANY key you EVER uploaded in planetlab, even if you have later deleted them. Planetlab creates your credential file once and then stores it, so when you try to redownload it you HAVE to use the key with which the credential file was created. For EACH public key, which you have EVER uploaded to your account on planetlab.org do the following:
-
Set the value of "key" in your omni_config to point to the corresponding private key.
[plc] <snip> cert=~/.gcf/plc.bbn.sedwards.gid key = ~/.gcf/pl_id_rsa1 -
Run:
omni.py -f plc getversionThe "-f plc" is to make sure you are using the planetlab control framework. Adjust appropriately to be consistent with the configuration in your omni_config.
-
When asked if you want to download your certificate, say "Y".
-
If you get an error, repeat with the next private key. Error will be similar to:
$ ./src/omni.py getversion INFO:omni:Loading config file omni_config INFO:omni:Using control framework plc Your certificate file (/home/lnevers/.gcf/plc.bbn.sedwards.gid) was not found, would you like me to download it for you to /home/lnevers/.gcf/plc.bbn.sedwards.gid? (Y/n)Y Failed to download a user certificate from the PL registry: Using SFA Failed to get User credentials from registry http://www.planet-lab.org:12345 cert file /home/lnevers/.gcf/plc.bbn.sedwards.gid, user plc.bbn.sedwards: <Fault 102: ': GetSelfCredential: Connection Key GID mismatch: plc.bbn.sedwards'>
-
I am trying to use the account I have with PL but I get an error that looks like:
ERROR:omni.sfa:Call for Get SFA user credential from registry
http://www.planet-lab.org:12345 for user plc.bbn.niky.riga using
cert file /home/nriga/.gcf/planetlab_key.gid failed. Server says:
<Fault 2: ': GetSelfCredential: Missing authority: plc.bbn.niky'>
Failed to download your user credential from the PL registry: <Fault
2: ': GetSelfCredential: Missing authority: plc.bbn.niky'>
There is a know issue for PlanetLab for user accounts with ".". In the above example the PL username is "niky.riga" . In your omni_config make sure that the urn of the user uses a '_' instead of a '.'.
So the urn in this case will be:
urn:urn:publicid:IDN+plc:bbn+user+niky_riga
When trying to use your PlanetLab account and you get an error that is similar to this
ERROR:omni.sfa:Call for List Aggregates at SFA registry
http://www.planet-lab.org:12345 failed. Server says: <Fault 13:
'Invalid method get_aggregates'>
The error is an omni bug. To get around this problem make sure you always specify an aggregate (-a) on the command line, e.g. " -a http://www.planet-lab.org:12346".
Sometimes the Planetlab central registry gets busy.
The symptom in Omni is something like:
<Fault 106: ': GetSelfCredential: Database
error: FATAL: connection limit exceeded for non-superusers\n'>
At the same time you will often find that the website ([http://www.planet-lab.org]) does not load.
Wait a while and try again later.
A. I try to look at planetlab resources (eg omni.py -a http://www.planet-lab.org:12345 listresources) and get an error containing the following string (possibly with a different site ID):
ERROR:omni:Call for List Resources at http://www.planet-lab.org:12346
failed. Server says: <Fault 108: ': ListResources: Invalid RSpec: site
ID 11553 not found'>
If you get the above error, please send mail to [email protected] with a copy of the command you are trying to run and the error. This is a known recurring error at PLC that we believe has been fixed, but therefore want to know if anyone sees it.
If your error is similar to :
ERROR:omni:Call for Create Slice urn:publicid:IDN+plc:bbn+slice+pathint failed.
Server says: <Fault 108: ': GetCredential: Permission error: plc.bbn.nriga has no rights to BBN Technologies'>
it means that you don't have the permission to create a slice. In Planetlab, only the PI of a site can create a slice. Please ask the PI of your site to create the slice for you. She can do that through the Web UI as well, and add you as a user in that slice.
First make sure that you have waited enough for your sliver to be activated. It usually takes a while (~ 15minutes) before your account is created on the reserved hosts.
If you have waited enough, but you still can't login to the nodes, make sure that you are using the right login name. To find out what is your login, run sliverstatus and look for a line in the output that looks like:
'pl_login': 'pgenigpolabbbncom_inkitest'}
If you get an error that looks like this:
Failed to renew sliver urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+<slicename> on
unspecified_AM_URN (https://myplc.gpolab.bbn.com:12346/)
<Fault 111: "Internal API error: can't compare offset-naive and offset-aware datetimes">
this probably means that the AM you are talking to runs an older versions of SFA (pre- June 2011 / SFA 1.0-27) that cannot handle timestamps that specify a timezone. Depending on which version of Omni you are running you have different options:
- Omni 1.4 and later : use the --no-tz omni flag
- Omni 1.3.* : unfortunately there is no easy way around this problem in this version. Omni will specify a timezone even if you timestamp does not specify one (the default timezone used is the Zulu timezone, which is the same as UTC (http://www.timeanddate.com/library/abbreviations/timezones/military/z.html)). Your option is other to upgrade to a newer version of Omni (recommended), or downgrade to Omni 1.2.*
- Omni 1.2.* : do not specify a timezone in your renewsliver command (e.g. 20111001T19:00:00)
If for some reason none of these solutions work for you, send an email to [mailto:[email protected]]
If your error looks like that :
Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+mebvisualization
expires within 1 day(s) on 2011-09-27 23:54:19 UTC
> Asked http://myplc.gpolab.bbn.com:12346/ to reserve resources. No manifest Rspec returned.
<Fault 111: "Internal API error: <Fault 102: 'person_id 2: GetSlices:
Invalid slice_filter value: expected struct, got array'>">
> INFO:omni: ============================================================
This error probably means that your login name to the hosts exceeds 32 characters. If you are using a ProtoGENI CH, to get PL resources then your login name is <ch_specific_string>_, so even if you slicename is less than 32 characters, the whole login name might exceed the 32 character limit. Usually the <ch_specific_string> is the CH's hostname without the dots, so for pgeni.gpolab.bbn.com this is :pgenigpolabbbncom Try to limit the length of your slice name and try again.
If your error looks like that:
Internal API error: <Fault 102: 'person_id 1: AddPerson: Invalid argument: E-mail address already in use'>
Then make sure that your username does not contain a capital letter. If it does please contact us at [mailto:[email protected]]. Include in your email the following information: account name, the authority you have an account with (emulab.net, planet-lab.org, pgeni.gpolab.bbn.com, etc).
Try using an account with a different clearinghouse, e.g. the pgeni.gpolab.bbn.com authority. FOAM gives a ProtocolError if it does not trust your certificate.
Q. Using Expedient (the old OpenFlow Aggregate Manager), I try to create a sliver and I get a Permission error.
If you are still using an Expedient aggregate (obsolete and replaced by FOAM), and you get an error that looks like this :
ERROR:omni:FAILed to create sliver
urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+mzhang_pgof_gpo at
https://tulum.gpolab.bbn.com:1443/openflow/gapi/. Server says: <Fault
1: '<class 'expedient.common.permissions.exceptions.PermissionDenied'>:Permission
'can_edit_project' was not found for permittee
'[email protected]' for target object 'Project PG-OF-test':
File "/usr/lib/python2.6/dist-packages/expedient/common/rpc4django/xmlrpcdispatcher.py",
line 46, in dispatch\n response = self._dispatch(method, params,
**kwargs)\n File
"/usr/lib/python2.6/dist-packages/expedient/common/rpc4django/xmlrpcdispatcher.py",
line 92, in _dispatch\n return func(*params, **kwargs)\n File
"<string>", line 2, in CreateSliver\n File
"/usr/lib/python2.6/dist-packages/openflow/plugin/gapi/rpc.py", line
74, in require_creds\n return func(*args, **kw)\n File
"/usr/lib/python2.6/dist-packages/openflow/plugin/gapi/rpc.py", line
100, in CreateSliver\n return gapi.CreateSliver(slice_urn, rspec,
kwargs["request"].user)\n File
"/usr/lib/python2.6/dist-packages/openflow/plugin/gapi/gapi.py", line
100, in CreateSliver\n project.save()\n File
"/usr/lib/python2.6/dist-packages/expedient/common/permissions/utils.py",
line 176, in save\n must_have_permission(permittee_kw, self,
edit_perm)\n File
"/usr/lib/python2.6/dist-packages/expedient/common/permissions/shortcuts.py",
line 84, in must_have_permission\n permittee,
allow_redirect=allow_redirect)\n'>
Then this means that there is already a project in the Aggregate Manager with the same name. In your rspec file there is a line that looks like :
<project description="my-proj" name="my-proj-name"/>
Change the value for "name" attribute of the above line in the rspec to something unique, and try again.
Expedient OpenFlow does not currently use the slice name for creating projects, but creates them based on the rspecs. If a project does not exist it will create one, and only the user that originally created the project can reuse it.
Q. Using an Expedient aggregate, I try to create an OpenFlow sliver, but the result does not contain the flowspace I requested.
If you ran a createsliver command against an Expedient OpenFlow AM (which is obsolete), and the command succeeds but the results is an empty rspec, that means that you are probably asking for resources that the AM does not know about. A potential problem when requesting flows on ports that a host is connected to, is that the interface on the host might be down and thus the AM does not know it exists. If that is not the problem, email the operator of the AM to help you resolve the problem.
If you try to do ListResources using credentials issued by the GPO you may see the following error:
$ ./src/omni.py -a https://geni.renci.org:11443/orca/xmlrpc listresources
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
Traceback (most recent call last):
File "./src/omni.py", line 2497, in <module>
sys.exit(main())
File "./src/omni.py", line 2491, in main
API_call(framework, config, args, opts, verbose=opts.verbose)
File "./src/omni.py", line 2235, in API_call
result = handler._handle(args)
File "./src/omni.py", line 149, in _handle
return getattr(self,call)(args[1:])
File "./src/omni.py", line 551, in listresources
(rspecs, message) = self._listresources( args )
File "./src/omni.py", line 404, in _listresources
rspec = zlib.decompress(rspec.decode('base64'))
File "/usr/lib/python2.6/encodings/base64_codec.py", line 42, in base64_decode
output = base64.decodestring(input)
File "/usr/lib/python2.6/base64.py", line 321, in decodestring
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding
Alternatively if you use the --no-compress option, you may see:
$ ./src/omni.py -a https://geni.renci.org:11443/orca/xmlrpc listresources --no-compress
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Listed resources on 1 out of 1 possible aggregates.
INFO:omni:<!-- Resources at AM:
URN: unspecified_AM_URN
URL: https://geni.renci.org:11443/orca/xmlrpc
-->
INFO:omni:Credendial Exception: javax.security.auth.login.CredentialException: No credential was found with appropriate privileges.
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed listresources:
Options as run:
aggregate: https://geni.renci.org:11443/orca/xmlrpc
framework: pgeni
geni_compressed: False
native: True
Args: listresources
Result Summary: Retrieved resources from 1 aggregates.
Wrote rspecs from 1 aggregates.
INFO:omni: ============================================================
Both of these errors are because the GPO credentials are not yet trusted by the Orca aggregate.
ORCA maintains a page where common errors are described. Please refer to this page: https://geni-orca.renci.org/trac/wiki/orca-errors
If your error is not covered there, please email mailto:[email protected] with the exact error you are seeing.
GENI is sponsored by the National Science Foundation.