incorrect or wrong component_manager_id results in unreported bad state sliver

[lnevers@bbn.com]

Created a sliver with 2 VMs using the "routable_control_ip" tag, the sliver is ready, but the manifest contains no login information.

Here is the sliver manifest:

<?xml version="1.0" ?>
  <!-- Reserved resources for:
	Slice: lnroute
	at AM:
	URN: unspecified_AM_URN
	URL: http://instageni.gpolab.bbn.com/protogeni/xmlrpc/am/2.0
 -->
  <rspec expires="2012-12-15T16:14:16Z" type="manifest" 
xmlns="http://www.geni.net/resources/rspec/3" 
xmlns:flack="http://www.protogeni.net/resources/rspec/ext/flack/1" 
xmlns:planetlab="http://www.planet-lab.org/resources/sfa/ext/planetlab/1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.geni.net/resources/rspec/3   
http://www.geni.net/resources/rspec/3/manifest.xsd">    
    <node client_id="VM" component_manager_id="urn:publicid:IDN+nstageni.gpolab.bbn+authority+cm" exclusive="false">    
        <emulab:routable_control_ip xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1"/>    
        <sliver_type name="emulab-openvz"/>    
        <interface client_id="VM:if0">      
        </interface>    
    </node>  
    <node client_id="VM-0" component_manager_id="urn:publicid:IDN+nstageni.gpolab.bbn+authority+cm" exclusive="false">    
        <emulab:routable_control_ip xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1"/>    
        <sliver_type name="emulab-openvz"/>    
        <interface client_id="VM-0:if0">      
        </interface>    
    </node>  
    <link client_id="lan0">    
        <component_manager name="urn:publicid:IDN+nstageni.gpolab.bbn+authority+cm"/>    
        <interface_ref client_id="VM-0:if0"/>    
        <interface_ref client_id="VM:if0"/>    
        <property dest_id="VM:if0" source_id="VM-0:if0"/>    
        <property dest_id="VM-0:if0" source_id="VM:if0"/>    
        <link_type name="lan"/>    
    </link>  
</rspec>

Also rspeclint on the manifest generates the following error:

$ rspeclint lnroute-manifest-rspec-instageni-gpolab-bbn-com-protogeniv2.xml 
Line 8: Failed validation with root at element: Schemas validity error : Element '{http://www.geni.net/resources/rspec/3}link': The attribute 'vlantag' is required but missing.
: rspec

Is this feature supported? Had syntax changed?

Attaching original Request RSpec.

[lnevers@bbn.com]

After submitting the ticket, notices that the component_manager_id was incorrect, so I updated it and recreated the sliver. Here is the new manifest rspec:

<?xml version="1.0" ?>
  <!-- Reserved resources for:
	Slice: lnroute
	at AM:
	URN: unspecified_AM_URN
	URL: http://instageni.gpolab.bbn.com/protogeni/xmlrpc/am/2.0
 -->
  <rspec expires="2012-12-15T16:14:16Z" type="manifest" xmlns="http://www.geni.net/resources/rspec/3" xmlns:flack="http://www.protogeni.net/resources/rspec/ext/flack/1" xmlns:plane
tlab="http://www.planet-lab.org/resources/sfa/ext/planetlab/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.geni.net/resources/rspec/3   htt
p://www.geni.net/resources/rspec/3/manifest.xsd">    
    <node client_id="VM" component_manager_id="urn:publicid:IDN+instageni.gpolab.bbn+authority+cm" exclusive="false">    
        <emulab:routable_control_ip xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1"/>    
        <sliver_type name="emulab-openvz"/>    
        <interface client_id="VM:if0">      
        </interface>    
    </node>  
    <node client_id="VM-0" component_manager_id="urn:publicid:IDN+instageni.gpolab.bbn+authority+cm" exclusive="false">    
        <emulab:routable_control_ip xmlns:emulab="http://www.protogeni.net/resources/rspec/ext/emulab/1"/>    
        <sliver_type name="emulab-openvz"/>    
        <interface client_id="VM-0:if0">      
        </interface>    
    </node>  
    <link client_id="lan0">    
        <component_manager name="urn:publicid:IDN+instageni.gpolab.bbn+authority+cm"/>    
        <interface_ref client_id="VM-0:if0"/>    
        <interface_ref client_id="VM:if0"/>    
        <property dest_id="VM:if0" source_id="VM-0:if0"/>    
        <property dest_id="VM-0:if0" source_id="VM:if0"/>    
        <link_type name="lan"/>    
    </link>  
</rspec>

Which still fails:

$ rspeclint lnroute-manifest-rspec-instageni-gpolab-bbn-com-protogeniv2.xml 
Line 8: Failed validation with root at element: Schemas validity error : Element '{http://www.geni.net/resources/rspec/3}link': The attribute 'vlantag' is required but missing.
: rspec

[lnevers@bbn.com]

Modifying ticket to capture discussions that took place outside the ticket. Requesting non existing or wrong component_manager_id does not report error. For example requesting component_manager_id="urn:publicid:IDN+idonot.exist.com+authority+cm" creates a sliver without reporting problem. Also, requesting the wrong component_manager_id (example request component_manager_id="urn:publicid:IDN+utah.geniracks.net+authority+cm" at IG GPO) also does not report error.

Following is the email exchange that took place outside the ticket. Capturing for tracking purposes:

On 12/14/12 12:21 PM, Gary Wong wrote:

I think the component_manager_id is _still_ wrong (the "i" to instageni
was added, but the ".com" is missing from "bbn.com").  The reason that
the manifest you are getting back has no annotation is that the AM
thinks the requested nodes and links belong to somebody else, so it
is happily creating a degenerate (empty) sliver for you and leaving
the "foreign" parts of the rspec (i.e. all of it) alone.

Please add ".com" to all the component_manager_ids, and try again.
(Note that the "emulab:routable_control_ip" feature will not succeed
until at least two routable addresses are added to the free pool; I
understand that Leigh and Josh are working on this at the moment.)

On 12/14/12 12:28 PM, Aaron Helsinger wrote:

This raises an interesting question:

PG/IG returns a manifest RSpec from CreateSliver, leaving elements
(nodes or links) that do not have its own component_manager_id alone.

Question:
What was the thinking behind having the aggregate include in the
manifest request elements that it ignored, as opposed to dropping those?

This approach clearly has 2 problems:
- the resulting RSpec does not pass the schema it claims to follow
- it is very difficult to detect a mistaken component_manager_id

(The alternative would be to include in the manifest only elements that
have actually been allocated by this aggregate.)

On 12/14/12 12:39 PM, Nicholas Bastin wrote:

On Fri, Dec 14, 2012 at 12:28 PM, Aaron Helsinger <ahelsing@bbn.com> wrote:
> PG/IG returns a manifest RSpec from CreateSliver, leaving elements
> (nodes or links) that do not have its own component_manager_id alone.
>
> Question:
> What was the thinking behind having the aggregate include in the
> manifest request elements that it ignored, as opposed to dropping those?

It seems that you requested this behaviour for FOAM:

https://openflow.stanford.edu/bugs/browse/FOAM-137

I guess the question is where do you draw the line on "information you
don't understand".

On 12/14/12 12:48 PM, Gary Wong wrote:

On Fri, Dec 14, 2012 at 12:28:02PM -0500, Aaron Helsinger wrote:
> - it is very difficult to detect a mistaken component_manager_id

Yes, that's unfortunate.  The AM makes it quite clear in its stderr
output that it hasn't done anything:

  snmpit: pgeni-gpolab-bbn-com/lnroute has no VLANs to create, skipping
  *** eventsys_control:
  ***   There are no nodes in [Experiment: pgeni-gpolab-bbn-com/lnroute]. Not
  ***   starting a scheduler.
  Debugging is on.

When coming through the Emulab interface, this information would be
prominently shown to the user.  Unfortunately, when making the
corresponding request through GENI, this information is at best wrapped
up in e-mail to the user and at worst ignored completely.  Regardless
of what we think the correct specified behaviour should be in this
case, it would be nice to have a good channel for conveying free-form
(but helpful) information from the AM to the user.

On 12/14/12 12:50 PM, Jonathon Duerig wrote:

I've brought up the idea before of having 'no-op' requests result in an error. 
But so far, it hasn't had much traction. 

On 12/14/12 12:52 PM, Nicholas Bastin wrote:

FWIW, given that I think we want to allow you to have multi-AM rspecs,
having the AM "detect" a mistake component_manager_id is going to be
impossible, and constantly telling you things that would allow the
user to possibly do it (via warnings, info, etc.) would probably just
be so annoying to also be of no help (since you'd get a pile of them
from every aggregate).

On 12/14/12 12:56 PM, Leigh Stoller wrote:

> I've brought up the idea before of having 'no-op' requests result in an
> error. But so far, it hasn't had much traction.

I'm fine with this, given an override option in the options array. I can
imagine there are things that we know we don't know, also unknown unknowns,
and things we don't know we don't know. (Thank you Donald)

On 12/14/12 1:25 PM, Aaron Helsinger wrote:

For stitching, I expect we will want to pass each AM involved a multi-AM
RSpec. And so yes, there isn't a simple answer here. I was really just
wondering what the argument was for that choice.

For comparison, SFA returns a manifest that excludes nodes/links that
are not for it.

Note Nick that including sub-elements from an unknown extension seems
different somehow, though I agree it's a rather gray area.

Anyhow, this isn't an instageni-design issue per se.

On 12/14/12 1:27 PM, Aaron Helsinger wrote:

On 12/14/12 12:48 PM, Gary Wong wrote:
> On Fri, Dec 14, 2012 at 12:28:02PM -0500, Aaron Helsinger wrote:
>> - it is very difficult to detect a mistaken component_manager_id
>  Regardless
> of what we think the correct specified behaviour should be in this
> case, it would be nice to have a good channel for conveying free-form
> (but helpful) information from the AM to the user.
>
>
We can always return an extra top level element in the return struct
from AM API calls - something parallel to 'value'.
Or we could allow you to fill in extra information in the 'output' field
even when the geni_code is 0.