[Planetlab-devel] denoting peer nodes

[Reid Moran]

Yeah, the color scheme idea wont work as well b/c it wont scale well 
with multiple peers.  I am in the process of making a peers page that 
shows any role the basic information about each peer, this will include 
nodes/slices/etc public info only.  The node display page as well as 
slice node selection page both need a revamp in regards to federation 
and overall use.

How useful is the full node list?  Most users do not peruse this list 
and will generally only look at their site nodes.  With the addition of 
peered PLCs, however, users may want to view their availible nodes, but 
as Thierry said, there isn't much relevant data here that users would 
want to see unless we start adding Monitor and/or Comon data to these 
pages.  This may be a useful next step.  I'll query some users and find 
out which they would prefer.

How do you think we should select nodes?  If not by site, how would you 
group them?  Site was chosen before I got here since the DB already 
broke nodes down that way, but I agree that it may not be the best way.  
Most users will use the --all sites--, but any ideas on how to break 
this huge list down more logically?  This is obviously a big thing to 
look into and any ideas/opinions would be appreciated!

lets get this thing user-friendly!!! post any ideas, im cramming web 2.0 
and ajax tech right now and hopefully we can do just about anything we 
can think of.

Thierry Parmentelat wrote:
> The first (current) iteration was, in a quick&dirty approach, to show 
> foreign objects (that includes nodes) with a light-gray background. 
> We've actually forgotten some views - like, I just checked, the 
> manage-slice's-nodes view - but that was the simplest we came up with 
> for a 2-peer federation.
> I had also planned to provide for a multi-colored scheme, that could 
> have scaled to a few peers, but that didn't happen yet - not sure 
> that's worth it in fact. (btw, there's also a 'peers' view that's 
> probably restricted to admins right now, but that could/should have 
> wider audience)
> Now of course for scaling beyond that, we might come up with an 
> alternative naming scheme, like the ones you are discussing within the 
> geni arch.
>
> About this slice-nodes view, I've personally never been quite happy 
> with the way it works. Having to select a site first is not 
> user-friendly, so I expect more or less everyone uses the --all 
> sites-- magic. We should have a more complete set of filters there, 
> upon node name, peer, site, or whatever - like also comon information 
> if we were determined enough to partially cache it in the DB.
> It was probably more important to have filtering on that view than 
> where I've put it first, my mistake.
>
> Larry Peterson wrote:
>> I'd like to establish how we're going to reveal what
>> nodes are managed by what peers (MAs). Not that people
>> peruse the nodes list, but for starters, they should
>> see the peer (for non-local nodes) when they do. When
>> users add nodes to their slices, they should also be
>> able to filter based on peers.
>>
>> Specific proposals? Reid?
>>
>> Larry
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel