[Mami Hayashida]

I went through all the files and updated everything. Unfortunately, these edits will not be automatically installed until the next release of various software.  For now, you could follow these steps to see how to make OWL work:

1. Find the most updated jupyter notebook example for OWL on the “owl” branch of FABRIC jupyter notebooks repo (https://github.com/fabric-testbed/jupyter-examples/blob/owl/fabric_examples/complex_recipes/owl/owl.ipynb)
2. Since the mflib package does not contain the latest owl.py, please obtain the up-to-date version of that script from the owl branch (https://github.com/fabric-testbed/mflib/blob/owl/mflib/owl.py)
3. Place those two files in the same folder and make the following change to the first code cell in owl.ipynb

#from mflib import owl as owl
import owl as owl

Restart the Kernel to make sure the import is updated. At that point, you should be able to run owl.ipynb using the local copy of owl.py. I just tested it and everything ran as it should. Please reach out again if you have any questions or run into any issues.

• This reply was modified 1 week ago by Mami Hayashida.

[Mami Hayashida]

I updated the owl code a few months ago, but perhaps forgot to update the example notebook. Let me look into this.

[Mami Hayashida]

Confirmed that my VM is up again. Thank you!  (sorry, I should not have posted this question under the FABRIC Announcement section — realized afterwards…)

[Mami Hayashida]

Thanks for checking on this. Is the GATECH issue fixable? Or will it be simpler to try creating another slice?

[Mami Hayashida]

slice ID

bf124347-9e91-4ac2-9bcd-a3623b0a3d5e

[Mami Hayashida]

Sure, I totally understand. Please know the intention of my comment was not to criticize you or anyone else, but rather, to make this testbed (esp. the slice creation) as user-friendly as possible. Thanks!

[Mami Hayashida]

Thanks, Mert, for a quick response.  Im that case, however, shouldn’t its state be “Maint” rather than “Active”?  It’s frustrating to users to have to submit a slice, wait for a long time, see it fail, rinse, repeat.

[Mami Hayashida]

Sorry, my fault!  I deleted that feature branch after it was merged into ‘main’!   Try this: https://github.com/fabric-testbed/jupyter-examples/tree/main/fabric_examples/public_demos/KNIT7/one_way_latency_measurements.

[Mami Hayashida]

Sounds good. And I will be at KNIT7 as well, doing an OWL demo. So I’ll probably see you then.

[Mami Hayashida]

Prateek,

What is shown in the owl-demo notebook (not the prep one) will work on any slice, whether it is an MF slice or not. All it is doing, basically, is: 1) pulling fabrictestbed-owl image from Docker Hub to each remote node; 2) start docker containers for senders + receivers using the image; 3) download the collected data from the receiver (destination) node(s).  Because your slice has a measurement node, it is possible that 1 or more of the for node in nodes: may have to be edited to exclude the meas-node. (and that may not even be necessary). Let me know if you run into any issues.

The second question: It just so happens that my colleagues from the University of Kentucky will be giving a tutorial at the KNIT7 on PTP timestamp experiment which involves sending a probe packet from one node that will be forwarded through multiple nodes to a destination node while recording the packet arrival time at all intermediary nodes. Yours sounds quite similar, so if you will be at KNIT7 (and can wait till then), you may want to attend that session and talk to the presenters there. In their case, I believe, a packet being “time-traced” is a ping packet while you are sending a file — but you may very well be able to make minor adjustments to their script.  If you won’t be at KNIT7, those notebooks should become available around that time, if not earlier.

If this does not satisfy your needs, however, do let me know. I will need more information, but I am sure, with what we have already implemented, you can run this experiment without much trouble.

[Mami Hayashida]

Yes, this is caused by a rather major change in the mflib.owl code that I made recently.  Please refer to the new version of OWL examples I am preparing for KNIT7 found here (Notice it is still on a feature branch): https://github.com/fabric-testbed/jupyter-examples/tree/mflib-owl/fabric_examples/public_demos/KNIT7/one_way_latency_measurements.  With the mflib version you have posted, these two notebooks should work. The “prep1” notebook is for creating a slice and installing/setting up all the prerequisites on each remote node; “demo1” uses the same slice and runs OWL in 3 different ways.  Please do let me know if you run into any problems.

We will continue to add minor edits to the OWL-related sections of Measurement Framework, mflib, and jupyter examples throughout next week and will have a demo at KNIT7. At that point, the newest version of demo notebooks will also be available.

[Mami Hayashida]

Restarting the kernel did not help, but stopping and starting the server again fixed the issue.

[Mami Hayashida]

I’m encountering exactly the same issue.

[Mami Hayashida]

Paul, it looks like calling fablib.get_slice(“<slice_name>”) worked. I got the management IP for the (one and only) node in that slice and I can ssh into it.

[Mami Hayashida]

I am having the same issue when running hello_fabric.ipynb.
`

—————————————————————————
Exception Traceback (most recent call last)
/tmp/ipykernel_279/774655997.py in <module>
—-> 1 slice.wait_jupyter(timeout=1000, interval=60)

/opt/conda/lib/python3.9/site-packages/fabrictestbed_extensions/fablib/slice.py in wait_jupyter(self, timeout, interval)
1174
1175 print(“Running post_boot_config … “, end=””)
-> 1176 self.post_boot_config()
1177 print(f”Time to post boot config {time.time() – start:.0f} seconds”)
1178

/opt/conda/lib/python3.9/site-packages/fabrictestbed_extensions/fablib/slice.py in post_boot_config(self)
1112
1113 for node_thread in node_threads:
-> 1114 node_thread.result()
1115
1116 for interface in self.get_interfaces():

/opt/conda/lib/python3.9/concurrent/futures/_base.py in result(self, timeout)
436 raise CancelledError()
437 elif self._state == FINISHED:
–> 438 return self.__get_result()
439
440 self._condition.wait(timeout)

/opt/conda/lib/python3.9/concurrent/futures/_base.py in __get_result(self)
388 if self._exception:
389 try:
–> 390 raise self._exception
391 finally:
392 # Break a reference cycle with the exception in self._exception

/opt/conda/lib/python3.9/concurrent/futures/thread.py in run(self)
50
51 try:
—> 52 result = self.fn(*self.args, **self.kwargs)
53 except BaseException as exc:
54 self.future.set_exception(exc)

/opt/conda/lib/python3.9/site-packages/fabrictestbed_extensions/fablib/node.py in network_manager_stop(self)
1206 except Exception as e:
1207 logging.warning(f”Failed to stop network manager: {e}”)
-> 1208 raise e
1209
1210 def network_manager_start(self):

/opt/conda/lib/python3.9/site-packages/fabrictestbed_extensions/fablib/node.py in network_manager_stop(self)
1190 # logging.info(f”No conn for device. conn: ‘{conn}'”)
1191
-> 1192 stdout, stderr = self.execute(f”sudo systemctl stop NetworkManager”)
1193 logging.info(f”Stopped NetworkManager with ‘sudo systemctl stop ”
1194 f”NetworkManager’: stdout: {stdout}\nstderr: {stderr}”)

/opt/conda/lib/python3.9/site-packages/fabrictestbed_extensions/fablib/node.py in execute(self, command, retry, retry_interval, username, private_key_file, private_key_passphrase)
655 src_addr = (‘0:0:0:0:0:0:0:0’, 22)
656 else:
–> 657 raise Exception(f”node.execute: Management IP Invalid: {management_ip}”)
658 dest_addr = (management_ip, 22)
659

Exception: node.execute: Management IP Invalid: None
`

[Author]

Posts