Opened 10 years ago

Closed 9 years ago

#46 closed (fixed)

Standardize version of FOAM

Reported by: jbs@bbn.com Owned by: nick.bastin@gmail.com
Priority: major Milestone:
Component: OpenFlow Version: SPIRAL4
Keywords: Cc:
Dependencies:

Description

The InstaGENI rack in Utah is currently running a forked-off version of FOAM that Nick handcrafted for it, to allow ProtoGENI to tell FOAM about things that FOAM could then auto-approve. Figure out what the future of that is, and get InstaGENI running a standard version of FOAM.

Change History (12)

comment:1 Changed 10 years ago by jbs@bbn.com

Nick and I had been talking about this, but I wanted to make a ticket about it to make it harder to lose track of.

comment:2 Changed 10 years ago by jbs@bbn.com

Nick, any further thoughts on this? It'd be really nice to get this squared away before more racks ship.

comment:3 Changed 10 years ago by nick.bastin@gmail.com

I'm 99% decided to just run stock FOAM on IG racks until someone complains. The only place this really causes a problem is if you want the shared mesoscale VLAN and don't want the uplink - otherwise you have to ask for reasonable flowspace (IP, dl_type, etc.) that FOAM already checks. If you ask for mesoscale with no uplink (is that possible? perhaps not) you could in theory ask for a port that you weren't allowed to have (although asking for an IP subnet that causes overlap would still fail).

comment:4 Changed 10 years ago by jbs@bbn.com

Sounds good to me. I'm not sure about the "only place this causes a problem" part -- how does uplink enter into it? What happens differently if I say I want flowspace that includes my subnet (or ethertype or whatever), including the uplink port, or if I say that I want that but not the uplink port?

(I do agree that usually if you want to flowspace on the mesoscale VLAN, you also want the uplink port; I just want to understand what would happen if you made a request that didn't include it for some reason.)

comment:5 Changed 10 years ago by jbs@bbn.com

Rob commented:

It's not possible with the current design to ask for OF mesoscale  
without asking for the uplink - asking to be put in the shared VLAN  
necessarily includes the uplink (well, assuming it works, of course. :) 

Rob, I'm not sure what you mean here. If you ask ProtoGENI to give your node a link to the shared mesosocale VLAN, you still have to ask FOAM for the flowspace, right? So if you don't ask FOAM for the uplink, then you won't get it. (The *VLAN* will be on the uplink port, but your FOAM sliver won't include the uplink port unless you ask for it.)

Or are you talking about something else here?

comment:6 Changed 10 years ago by jbs@bbn.com

Off-ticket, Rob agreed:

My statement was probably  confusing because of the multiple layers  
going on here. :) From my perspective, if you are in the mesoscale  
OpenFlow VLAN locally, you have connectivity to the uplink port. You are  
correct that it's certainly not required that you actually ask for any  
flowspace that includes that port. 

Makes sense. So I'm back to my question for Nick, who had said

The only place this really causes a problem is if you want the shared mesoscale VLAN and don't want the uplink - otherwise you have to ask for reasonable flowspace (IP, dl_type, etc.) that FOAM already checks. If you ask for mesoscale with no uplink (is that possible? perhaps not) you could in theory ask for a port that you weren't allowed to have (although asking for an IP subnet that causes overlap would still fail).

I had asked:

how does uplink enter into it? What happens differently if I say I want flowspace that includes my subnet (or ethertype or whatever), including the uplink port, or if I say that I want that but not the uplink port?

(I do agree that usually if you want to flowspace on the mesoscale VLAN, you also want the uplink port; I just want to understand what would happen if you made a request that didn't include it for some reason.)

Nick, whatcha thinkin'?

comment:7 Changed 10 years ago by jbs@bbn.com

Nick said via e-mail:

I'm not entirely sure I rememberâ\200¦.I had in mind an attack or mistake that isn't really possible if you have to contend for flowspace on uplink port, but I can't come up with it at this moment.

I can't offhand think of what this might be, so my inclination is to shift to FOAM 0.8.2 on the racks; and if we come up with a problem later, we can revisit. Sound ok?

comment:8 Changed 10 years ago by jbs@bbn.com

Nick and I talked on IRC about this, and he said that it sounded ok to him.

Nick, any estimate on when would be a good time to do this?

comment:9 Changed 10 years ago by jbs@bbn.com

Hey Nick! Any thoughts on when would be a good time to do this?

comment:10 Changed 10 years ago by jbs@bbn.com

We talked about this at the InstaGENI call on Friday, and concluded that only Nick and GPO folks cared about this; and I talked to GPO folks at our infra meeting today and concluded that only Tim and I care about this (Tim because he's working with UEN to bring their OpenFlow? switch into the dataplane path, and we don't want to make that change and this one at the same time.)

Nick, want to pick a time?

comment:11 Changed 10 years ago by jbs@bbn.com

We talked about this at the call last week, where we brought up a point that I hadn't realized: The current FOAM installation on the Utah InstaGENI rack isn't a custom package, it's actually (a) installed from *source*; (b) installed from a tag that's identical to the FOAM 0.8.2 release.

In light of that, we agreed that it would be more complicated to upgrade than just a simple package remove/install, and that we'd wait to do it until we wanted to upgrade FOAM anyway -- that is, when 0.8.3 (or 0.10, or whatever) comes out, we'll normalize this then.

Meanwhile, other InstaGENI racks should get the standard 0.8.2 binary package.

Nick, sound right? If so, I think we should keep this open so we don't forget about it, but there's nothing to do here until the next FOAM release.

comment:12 Changed 9 years ago by jbs@bbn.com

Resolution: fixed
Status: newclosed

Just to catch up to the present: New racks are in fact being deployed with a standard FOAM binary package, so the concern that this ticket was created to address is in fact being addressed.

We'll eventually want the Utah rack to come into synch with the others, but I think that may be beyond the scope of this ticket, and that we don't actually ned to keep poking it. (Among other things, the Utah rack is a dev rack, so it may never fully be in synch with the others, and I don't think we need these tickets to track the ways in which it's different, unless anyone else thinks we do).

So, I'm closing this one out, but we can re-open it if others think we should.

Note: See TracTickets for help on using tickets.