On March 10th, I'll be heading out to Oklahoma City for the next OKCOSUG meeting: OpenSolaris Project: Oklahoma City OpenSolaris User Group. I find the topic to be interesting and I like meeting people who use our product.

You can click on the link above for directions and such - also, please be sure to register to let Bryan know how many to plan for getting refreshments. And a quick summary of the agenda is:

Agenda 

5:00PM to 5:30PM Meet and Greet
5:30PM to 7:00PM Sun Unified Storage 7000 Technical Overview
7:00PM to 7:15PM Summary and open for questions

I got an email asking me what I didn't like about the Fishwork's CLI (see Impressions of Sun Unified Storage Simulator). I thought I would answer here.

I'd say the main complaint I had with it would be I couldn't issue 'ifconfig' or 'share'. I was trying to help someone over on a Linux mailing list with an issue (you can find the thread here -- Permission problem with NFSv4 mount and [Fwd: Re: Permission problem with NFSv4 mount]) and I wanted to just dive right in like it was any other OpenSolaris box.

It was actually easier for me to use the web interface than the CLI. Was the CLI that hard to use? No - just different. It was easy enough to figure out how to move about in with a couple of minutes of experimentation. I never pulled out any documentation.

So, it would be easiest for me if the CLI had normal unix commands. That doesn't mean that it would be easiest for everyone. This new product was the perfect time to change the CLI - you do not want local access on a appliance. Within pNFS, we are struggling with having local access for the MDS and DSes. Rob Thurlow is busy working on Proxy IO in case the MDS needs to read/write directly to the DSes (it also is a cheeky way to provide NFSv3 and CIFS access to the community).

So given that you want to deny local access, why not change the interface? And if you are going to change it, why not start off from scratch?

The whole GUI design reeks of object oriented design. Why not also have a CLI that does that?

Hmm, I'm not hitting specifics, which tells me a couple of things:

1. I missed some common commands.
2. I was quickly able to figure out how to use the new CLI.
3. My lack of real frustration tells me that the ease of use outweighed familiarity.

I can't stress that I went into using the sim convinced I was going to hate it. I liked the NetApp sims, in part because I worked on it. But the NetApp sim was in no way as easy to configure or deploy. It took me a couple of minutes to get it up and running on the VMware network and only a couple of more to get it running across the physical wire. In the meantime, I had Debian Lenny not install on both a VMware machine and a mac mini. I finally got it working on an old laptop.

I walked away from using the simulator very happy with my experience. I think I was able to replicate the issue that a customer was seeing - I'm still waiting on a reply from him to confirm that. I'm confident that I can use it to troubleshoot other issues that might be reported on NFSv3 and NFSv4 for the Sun Storage 7000 Unified Storage Systems.

I also know that a lot of effort was put into observability for these boxes - just look at Bryan's entry on Eulogy for a benchmark or Brendan's entry on Unusual disk latency. My take away from both of these is that we can now measure things that other vendors can not. Before Dtrace, you had to systematically add trace points, recompile, QA, and then ship new bits to customer sites. And they may have had to QA the incoming bits. Now you can just start asking the interesting questions right away and getting answers.

Without delving too deeply, I expect all of this to be more integrated with the new UIs. I suspect there is a power here. I'm pretty sure I can quickly dig through this stuff on the web interface. And I'm just as confident that the CLI has the same power, but it just isn't my parent's '>' prompt...