Opened 10 years ago

Last modified 10 years ago

#1157 new stitching aggregate url has myplc aggregate_url

Reported by: Owned by:
Priority: major Milestone:
Component: STITCHING Version: SPIRAL6
Keywords: confirmation tests Cc:


This is an enhancement request, which has been previously discussed and is being recorded for the MAX IG Stitching Confirmation Tests.

The current MAX stitching aggregate ( has the aggregate_url ​

The Stitching computation service returns the following when stitching through MAX stitching aggregate:

 { 'aggregate_url': '',   <=== here
   'aggregate_urn': '',
   'hop_urn': '*',
   'import_vlans': False}], 

This is what the user will see from the Stitcher:

12:47:22 INFO     stitcher: Stitched reservation will include resources from these aggregates:
12:47:22 INFO     stitcher: 	<Aggregate>
12:47:22 INFO     stitcher: 	<Aggregate>
12:47:22 INFO     stitcher: 	<Aggregate>
12:47:22 INFO     stitcher: 	<Aggregate>
12:47:22 INFO     stitch.Aggregate: Writing to '/tmp/IG-ST-1-createsliver-request-11-dragon-maxgigapop-net.xml'
12:47:22 INFO     stitch.Aggregate: 
	Stitcher doing createsliver at
12:48:08 INFO     stitch.Aggregate: DCN AM <Aggregate>: must wait for status ready....

This naming may be confusing to experimenter who will see a MyPLC aggregate when stitching to the MAX IG rack.  Should consider renaming this URL to avoid confusion.

Change History (1)

comment:1 Changed 10 years ago by

I had missed the following email when I wrote this ticket:

On 12/3/13 10:52 AM, Xi Yang wrote:
> Tim,
> Good questions. We have actually started looking at the same in the context of 
> upgrading to SFA 3.x with MyPLC 5.2.x on Fedora 18 and higher.
> 1. The newer MyPLC  on Fedora18 only supports LXC, which is similar to OpenVZ. 
> The LXC mechanism to connect extra interfaces to L2 networks is totally different
> than what earlier MyPLC does with vserver.
> It is much harder to work it out. So we may have to stop supporting Planetlab nodes 
> if there is no obvious demand for that. However, we will continue using the MyPLC 
> package itself as it is required by SFA.
> 2. I am developing the new MAX AM to support GENI APIv3 based on SFA 3. I had to 
> create a new Fedora 18 based deployment from scratch. The new development server 
> has URL:
> We will switch to this once the development version is stabilized. This new 
> deployment will only support *networking* (without planetlab nodes) initially. 
> One issue keeping us from switching over is that SFA 3 is not backward compatible,
> meaning GENI API v2 is not supported.
> Before that we will still be using The 
> planetlab nodes are still supported for now as we will use them for some data plane
> tests.
> —Xi
> On Dec 2, 2013, at 4:32 PM, Tim Upthegrove <> wrote:
>> Hi Xi,
>> We were trying out stitching to the MAX IG rack today to see if things
>> are working, and Ali was able to successfully stitch between the GPO
>> rack and the MAX rack.  We'll put that through more thorough testing
>> shortly...
>> Along the way, we did have a couple of things that we noticed though:
>> 1. The MAX stitching AM's advertisement still includes some MyPLC-based
>>   PlanetLab nodes
>> 2. The AM URL for the MAX stitching aggregate is
>> With regards to item #1, do you all plan on keeping those nodes around
>> and supporting them?  If not, then we should probably remove them from
>> the AM advertisement just to avoid confusion.
>> For item #2, it might be good to change the URL for the AM (or at least
>> create a new CNAME).  Even if you all plan on continuing to use the
>> PlanetLab nodes, I think the main function of this aggregate is to act
>> as a transit provider for experiments that utilize GENI stitching.
>> There was some confusion on our end as to whether we were using the
>> correct aggregate, because the URL had "myplc" in the name, which in the
>> mesoscale has traditionally referred to an AM that just supported
>> MyPLC-based PlanetLab node reservation.  If you all do change the AM
>> name or create a new CNAME, you will probably also need to update what
>> is advertised by the SCS, as that is where we got the URL from in our
>> testing.
>> Thanks,
>> -- 
>> Tim Upthegrove
>> Systems Engineer
>> Raytheon BBN Technologies
Note: See TracTickets for help on using tickets.