[Planetlab-devel] Multiple Information Sources with One View

[Stephen Soltesz]

Hey, guys,

I wanted to summarize what I understood as the feature requests from the 
users and the design goals from planetlab operations perspective after the 
discussion this morning and talking with Reid.  I hope this is helpful in 
discussing any specific proposal, since there are a variety of 
short-term/long-term trade-offs.

## Requests and Goals

It sounds like there were originally two feature requests:

  * have a node view where federated nodes were obvious (Larry)
  * have additional info about nodes on 'All Sites' list (Utah Folks)

Where the general goal of these features could be summarized as:

  * more flexible views on PLC nodes.

Of the second feature above from the Utah folks, they wanted to have 
additional stats displayed such as number of slices, site, last-contacted, 
or other PLC maintained details as a first step.

To the degree that PLC-maintained details are insufficient, they/we 
recognize that it would also be valuable to have a third-party service 
information included in the display.

But, which third-party service do we use?  We currently have *FOUR* 
independent sources of node-labeling services, only one of which is actually 
in the GUI today:

  * PLC db nodegroups
  * CoMon
  * Clue
  * Montior

These are all Princeton administered projects.

## Multiple sources with One view

Thinking about the information that Monitor collects (RT tickets, PL-visible 
state of the nodes, and event histories) I've recognized that some of this 
information would be most valuable *in* the PLC GUI to help with 
administration.  This would help admins (us) identify *why* a site was 
disabled (Monitor did it), or why a slice was disabled (David did it), 
without having to look in two different locations and still not have a 
complete picture of the system.  I identify Monitor as being a branch of 
PLC's Management Authority arm.

The complementary, Slice Authority function is to present users with a list 
of nodes to which they can add their slice (or just list them).  The two 
original feature requests came as a result of the existing interface not 
being expressive enough.

I understood Mike's proposal as being an attempt to define a generic 
mechanism by which the SA GUI integrates information from third-party 
node-labeling services.  A means of addressing the non-expressiveness of the 
current interface.  A big benefit of this is that the API calls already 
exist, it's just a matter of finding a new way to leverage them for the GUI. 
  This sounds like a nice short-term approach. (I don't know maybe long term 
too).

Talking with Reid after the meeting, he mentioned that any changes we made 
to integrate Monitor specific information might have to be conditional for a 
MyPLC installation to continue working.  This applies equally to any 
third-party information we would integrate.  Thus, no matter which 
information we integrate and whatever mechanism we use, MyPLC would have a 
hole that other services could fill only if they knew how to dump 
information into it.

At ROADS, I got interest from Thierry about running Monitor on Onelab, but 
he was disappointed to learn that it depended on CoMon (at the time).  If it 
did not, or if the mechanism by which information like monitor or comon was 
injected into the PLC UI was well defined, then Onelab or whoever could 
write services to use this interface.

So, my thinking is that in terms of resource/development time, because we 
are federating and others are using some of our UI code, a feature or 
framework that allowed additional information to be injected into the PLC 
GUI would benefit not only us but others as well.  All be it, this is a more 
general problem and possibly a more long-term approach to the problem.

The general problem as I understand it, could be phrased as:

   How to both keep PLC and third-party node-labeling services as 
independent packages while creating an interface that combines them with a 
single UI?

Thank you,
Stephen.

Reid Moran wrote:
> 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
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel