[Komal Thareja]

Hi Sunjay,

That Modify error was a bug and a patch has been deployed for that. There is also an issue in the notebook. For FabNetv4Ext service, IP allocations can be updated by the Control Framework as the FabNetv4Ext subnet is shared across the slices on a site. Collisions are handled for FabNetv4Ext by ControlFramework instead of the Fablib.

Getting the latest slice topology and retrieving the networks would ensure you have the actual IPs allocated. This should ensure correct IPs are configured on the VMs. The following steps are missing on the example notebook. Will work to update that.


slice = fablib.get_slice(slice_name)
network1 = slice.get_network(network1_name)
network2 = slice.get_network(network2_name)
print(network1.get_public_ips())
print(network2.get_public_ips())


Please try your slice again with above suggestions and let me know if you still see the same issue.

Thanks,

Komal

[Komal Thareja]

Hi Sunjay,

Thank you for reporting this. The collision shouldn’t occur, I will look at this and will share updates on this soon.

Thanks,

Komal

[Komal Thareja]

Maintenance is complete and Jupyer Hub has been updated.

[Komal Thareja]

Hi Prateek,

We currently do not support guaranteed Quality of Service (QoS), but we do offer best-effort QoS. You can request bandwidth by setting it on your interfaces using a command like iface.set_bandwidth(10).

Please note that Basic NICs are essentially Virtual Functions, and the underlying dedicated NIC is shared, so guaranteed bandwidth may not be achievable. However, you should see better performance with ConnectX_6 or ConnectX_5 NICs.

Here’s an example slice request for your reference:


#Create Slice
slice = fablib.new_slice(name=slice_name)
# Network
net1 = slice.add_l2network(name=network_name, subnet=IPv4Network("192.168.1.0/24"))
# Node1
node1 = slice.add_node(name=node1_name, site=site)
iface1 = node1.add_component(model='NIC_Basic', name='nic1').get_interfaces()[0]
iface1.set_mode('auto')
iface1.set_bandwidth(10)
net1.add_interface(iface1)
# Node2
node2 = slice.add_node(name=node2_name, site=site)
iface2 = node2.add_component(model='NIC_Basic', name='nic1').get_interfaces()[0]
iface2.set_mode('auto')
iface2.set_bandwidth(10)
net1.add_interface(iface2)
#Submit Slice Request
slice.submit();


Thanks,
Komal

[Komal Thareja]

Thank you, Prateek, for sharing your slice ID and observations! If you encounter this issue again, please let us know and refrain from deleting the slice. This will greatly assist us in debugging and identifying the problem.

Unfortunately, we can’t do much with a deleted slice. We appreciate your cooperation with this!

Thanks,
Komal

[Komal Thareja]

Hi Sunjay,

Are you still facing this issue? I tried a slice on TOKY and didn’t run into any access issues.

Please let us know.

Thanks,
Komal

[Komal Thareja]

Hi Sunjay,

I just checked all the VMs on your slice. I can ping all FabNetv4Ext IPs from my laptop. I’ll check with Network Team and share more details if we see any issues.

Thanks,
Komal

[Komal Thareja]

Hi Nirmala,

This looks like a bug in fablib which doesn’t have the update regarding the username for default_kali. Could you please try using user kali to access the VM?

I will work to provide a fix for this soon. Apologies for the inconvenience!

Thanks,
Komal

[Komal Thareja]

Sorry for the confusion, Users can still validate their keys against the bastion host using the command above as indicated on the learn article.

Thanks,
Komal

[Komal Thareja]

Hi,

Could you please try running this notebook?

jupyter-examples-rel1.6.1/configure_and_validate.ipynb

This will validate your configuration and update it if needed.

Please try running the Hello Fabirc Notebook after that. This notebook creates a VM and also displays the SSH command to use to login into the VM. Please check if the SSH command works and let us know if the issue still persists.

NOTE: Bastion host is only used as a jump box, we do not allow login to Bastion Nodes.

Thanks,

Komal

• This reply was modified 7 months ago by Komal Thareja.

[Komal Thareja]

Hi Nishanth,

The fix for this issue is now available with fabrictestbed-extensions==1.7.2

Thanks,

Komal

[Komal Thareja]

Hi Nishanth,

We just added support for users to query host level information as well. Examples for this would be available in a couple of days. I am sharing a snippet below on how this can be done:


fablib.list_hosts()
resources = fablib.get_resources()
site = resources.get_site("MAX")
all_hosts = site.get_hosts()
host = site.get_host(name="max-w1.fabric-testbed.net")
print(host)

Please checkout our documentation here to find more details. Please let us know if you have more questions/concerns.

https://fabric-fablib.readthedocs.io/en/latest/resources.html

https://fabric-fablib.readthedocs.io/en/latest/site.html

Thanks,

Komal

[Komal Thareja]

Hi Bjoern,

We just added support for users to query host level information as well. Examples for this would be available in a couple of days. I am sharing a snippet below on how this can be done:


fablib.list_hosts()
resources = fablib.get_resources()
site = resources.get_site("MAX")
all_hosts = site.get_hosts()
host = site.get_host(name="max-w1.fabric-testbed.net")
print(host)

Please checkout our documentation here to find more details. Please let us know if you have more questions/concerns.

https://fabric-fablib.readthedocs.io/en/latest/resources.html

https://fabric-fablib.readthedocs.io/en/latest/site.html

Thanks,

Komal

[Komal Thareja]

Hi Natty,

Apologies for the inconvenience! I looked at your Slice and can confirm from the logs the deletion was triggered by user either via Fablib/Portal.

2024-07-10 21:30:15,216 - CFEL Slice event slc:54466474-bcc2-45ef-a86a-4696b7d1bc5e create by prj:073ee843-2310-45bd-a01f-a15d808827dc usr:4d5326ac-b002-444f-bb44-3b406a038be5:nm3833@nyu.edu:49c50f84eab437103fa7f7863bfbbd5bbe4e303ea017b2912ce0df418b61a3df compute vms:5,cores:48,p4s:0; sites GATECH; components SmartNIC:1,SharedNIC:4; services L2Bridge:0,L2Bridge:0; vmdetails C32/R256/D25:1,C4/R32/D10:4

2024-07-11 14:25:52,610 - CFEL Slice event slc:54466474-bcc2-45ef-a86a-4696b7d1bc5e delete by prj:073ee843-2310-45bd-a01f-a15d808827dc usr:4d5326ac-b002-444f-bb44-3b406a038be5:nm3833@nyu.edu:49c50f84eab437103fa7f7863bfbbd5bbe4e303ea017b2912ce0df418b61a3df

This possibly may have happened because of the Bug reported here With the maintenance next week the delete bug would be addressed.

Thanks,

Komal

• This reply was modified 7 months, 1 week ago by Komal Thareja.

[Komal Thareja]

Hi Nishant,

It appears that a network service has leaked. In a distributed system like our testbed, encountering some leaked resources is not unusual. We plan to deploy updates in the coming week to address this issue. In the meantime, I recommend introducing a delay between deletion and recreation, as the resources are distributed across the testbed.

For now, I have cleaned up the leaked services, so provisioning should work.

Also, if possible could you please share your notebook or code- snippet that might help reproduce this state. Would be super helpful to debug and address this issue? Appreciate your help with this!

Best regards,

Komal

[Author]

Posts