Forum Replies Created
-
Posts
-
Hi Suhib,
To use P4 Tofino switches, your project lead can request the Switch.P4 permission directly through the FABRIC portal.
FABRIC also offers BlueField-3 DPUs, which support P4, as well as FPGAs—both of these resources similarly require explicit permission requests. You can find details on project roles and permissions here:
https://learn.fabric-testbed.net/knowledge-base/fabric-user-roles-and-project-permissions/#project-permissionsYou may also want to explore several example artifacts available at:
https://artifacts.fabric-testbed.net/artifacts/Best,
Komal
Hi Tejas,
Could you please check the logs:
/tmp/fablib/fablib.logand also check if your bastion keys are not expired?Please re-run
jupyter-examples-*/configure_and_validate.ipynbnotebook to renew your SSH keys. Please try creating the slice again after this.Best,
Komal
@yoursunny – Please consult this page for detailed CPU specifications.
Please let us know if you need anything else.
Best,
Komal
Hi Jacob,
Thanks for reaching out. Based on the last discussions around this within our team, Intel RAPL metrics were not driven up into the VM plane, and we decided not to expose energy monitoring (or estimations) via the VM APIs. So at this time, this capability is not available on FABRIC.
Best regards,
KomalHi Fatih,
I hope you are doing well too, and thank you for reaching out with the detailed description.
The slice is currently in a StableError state because some slivers encountered failures during the earlier modification attempt and were subsequently closed. This behavior is intentional: FABRIC reports the slice as StableError to preserve visibility into past sliver failures, even after the problematic resources have been cleaned up.
At this point, since the affected network service has already been closed and no longer appears in the slice, there is no further action required to delete it. Your remaining active resources should continue to function normally, and their operation is not impacted by the slice being in StableError. In other words, this state is informational rather than blocking.
If you would like to proceed with a clean state, the recommended option is to create a new slice with the desired topology. Otherwise, you may continue using the current slice as-is if the active slivers meet your needs.
Please let us know if you have any additional questions or if you’d like help recreating the slice or network service.
Best regards,
KomalHi Ilya,
Happy New Year to you as well!
The slice is still up and running; however, your project has expired, which is preventing the CM from issuing tokens.
I’ve requested Michael to extend your project, and that should resolve the issue shortly.
Best regards,
KomalHi YoursSunny,
Thank you for reaching out! This information is not currently exposed through the API. However, it is documented here and may be helpful:
https://learn.fabric-testbed.net/knowledge-base/fabric-site-hardware-configurations/I’ll also raise this with our team to discuss whether we can extend the API to support this in the future.
Best regards,
KomalHi,
I’ve fixed NS6 as well. Please try to update your experiment scripts to avoid overwriting the
authorized_keysfile in the future.Best,
KomalHi Fatih,
Just wanted to check if you were able to acquire resources for longer duration. Please let us know if we can help in anyway.
Best,
Komal
Hello Danilo,
I’ve restored the keys used by the Control Framework. You should now be able to add your keys via POA.
Please be careful not to overwrite any existing keys, and make sure to take a backup of your data beforehand.
@yoursunny — great suggestion. So far, we’ve avoided building our own images to reduce additional effort, but we’ll explore ways to either avoid this altogether or introduce a new user without requiring custom OS images.
Best regards,
Komal
