Opened 6 years ago

Last modified 6 years ago

#1157 new

dragon.maxgigapop.net stitching aggregate url has myplc aggregate_url

Reported by: lnevers@bbn.com Owned by: xyang@maxgigapop.net
Priority: major Milestone:
Component: STITCHING Version: SPIRAL6
Keywords: confirmation tests Cc:
Dependencies:

Description

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.

Change History (1)

comment:1 Changed 6 years ago by 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
>
>
>
Note: See TracTickets for help on using tickets.