dragon.maxgigapop.net stitching aggregate url has myplc aggregate_url

[lnevers@bbn.com]

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 (dragon.maxgigapop.net) has the aggregate_url ​http://max-myplc.dragon.maxgigapop.net:12346/.

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

 { 'aggregate_url': 'http://max-myplc.dragon.maxgigapop.net:12346',   <=== here
   'aggregate_urn': 'urn:publicid:IDN+dragon.maxgigapop.net+authority+am',
   'hop_urn': 'urn:publicid:IDN+dragon.maxgigapop.net+interface+clpk:1-1-2:*',
   '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 urn:publicid:IDN+dragon.maxgigapop.net+authority+am>
12:47:22 INFO     stitcher: 	<Aggregate urn:publicid:IDN+instageni.gpolab.bbn.com+authority+cm>
12:47:22 INFO     stitcher: 	<Aggregate urn:publicid:IDN+instageni.maxgigapop.net+authority+cm>
12:47:22 INFO     stitcher: 	<Aggregate urn:publicid:IDN+ion.internet2.edu+authority+am>
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 http://max-myplc.dragon.maxgigapop.net:12346
12:48:08 INFO     stitch.Aggregate: DCN AM <Aggregate urn:publicid:IDN+dragon.maxgigapop.net+authority+am>: 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.

[lnevers@bbn.com]

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:
> 	http://maxam.maxgigapop.net:12346
> 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 http://max-myplc.dragon.maxgigapop.net:12346. 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 <tupthegr@bbn.com> 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
>>   http://max-myplc.dragon.maxgigapop.net:12346
>>
>> 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
>
>
>