| 31 | = FOAM = |
| 32 | |
| 33 | Here are some additional introductory details about FOAM. |
| 34 | |
| 35 | == Auto-approval == |
| 36 | |
| 37 | In most GENI aggregates, when an experimenter requests resources, the request is automatically approved if the requested resources are available, and rejected otherwise. For example, if an experimenter requests three ExoGENI VMs, the ExoGENI AM can satsify that request if it has the the resources available to create three VMs, or not if it doesn't, but in any case without affecting anyone else. The situation is more complicated in FOAM, since !OpenFlow resources can be shared, and requests from experimenters can overlap. For example, if an experimenter requests an IP subnet (e.g. 10.42.0.0/16), FOAM needs to check whether any other experimenters have already requested IP space that overlaps with that subnet (such as 10.0.0.0/8 or 10.42.15.0/24). |
| 38 | |
| 39 | Originally, admins were responsible for detecting these overlaps, and thus most admins configured FOAM to require manual approval of new slivers. As of FOAM 0.12.0, FOAM has an analysis engine that can identify whether a new request overlaps with existing requests, and approve it automatically if it doesn't conflict with anything else. Our [wiki:OpenFlow/FOAM#Auto-approval FOAM auto-approval docs] describe this in a fair bit of detail, including how the analysis engine works, and how we decide [wiki:OpenFlow/FOAM#Sliverapprovalworkflow what to do if a sliver isn't auto-approved]. |
| 40 | |
| 41 | Most FOAM slivers will be auto-approved, but our main FOAM page has a section with [wiki:OpenFlow/FOAM#ManagingFOAMslivers commands for managing FOAM slivers], should you need to do that. You can also use GENI credentials of your own to create a sliver to play with, just to see first-hand how this works. |
| 42 | |
| 43 | When in doubt about an approval request, feel free to ask the Infrastructure team at the GPO (gpo-infra@geni.net) -- we're always happy to help. |
| 44 | |
| 45 | == E-mail == |
| 46 | |
| 47 | FOAM will send mail to the FOAM admins and to experimenters when it does various things, such as when a sliver is created, approved, and deleted. There's also a nightly FOAM cron job that reports on "pending" slivers, i.e. anything that wasn't automatically approved; those generally reflect an experimenter who's waiting for resources, so please try to act on those expeditiously. You can generally skim the other messages to make sure they don't contain anything unusual, and otherwise, archive them in case you ever need them later. |
| 48 | |
| 49 | FOAM has two places where e-mail is configured: The site.admin.email setting, which shows up in getversion output, and the configuration for administrative e-mail. Racks generally come with the latter pre-configured, and you can set the former if you like, or not if you don't (see http://groups.geni.net/geni/wiki/OpenFlow/FOAM#Othersettings for instructions). |
| 50 | |
| 51 | == Configuration == |
| 52 | |
| 53 | We have some [wiki:OpenFlow/FOAM#Initialconfiguration guidelines for FOAM configuration], which we encourage GENI sites to follow. If you're a rack admin, these should already be done as part of the rack setup process, but you can check for yourself if you're curious. |
| 54 | |
| 55 | == Upgrades == |
| 56 | |
| 57 | As of 2013-12, the rack teams are responsible for deciding whether and when to schedule FOAM upgrades, so if you're a rack admin, you generally shouldn't upgrade FOAM except when advised by the rack teams. For other FOAM admins, the GPO will typically post to response-team@geni.net to recommend/request that sites upgrade. |
| 58 | |
35 | | As of 2013-07, the rack teams are responsible for deciding whether and when to schedule !FlowVisor upgrades, so if you're a rack admin, you generally shouldn't upgrade FV except when advised by the rack teams. For other FOAM admins, the GPO will typically post to response-team@geni.net to recommend/request that sites upgrade. |
36 | | |
37 | | = FOAM = |
38 | | |
39 | | In most GENI aggregates, when an experimenter requests resources, the request is automatically approved if the requested resources are available, and rejected otherwise. For example, if an experimenter requests three ExoGENI VMs, the ExoGENI AM can satsify that request if it has the the resources available to create three VMs, or not if it doesn't, but in any case without affecting anyone else. The situation is more complicated in FOAM, since !OpenFlow resources can be shared, and requests from experimenters can overlap. For example, if an experimenter requests an IP subnet (e.g. 10.42.0.0/16), FOAM needs to check whether any other experimenters have already requested IP space that overlaps with that subnet (such as 10.0.0.0/8 or 10.42.15.0/24). |
40 | | |
41 | | Originally, admins responsible for detecting these overlaps, and thus most configured FOAM to require manual admin approval of new slivers. As of FOAM 0.12.0, FOAM has an analysis engine that can identify whether a new request overlaps with existing requests, and approve it automatically if it doesn't conflict with anything else. Our [wiki:OpenFlow/FOAM#Auto-approval FOAM auto-approval docs] describe this in a fair bit of detail, including how the analysis engine works, and how we decide [wiki:OpenFlow/FOAM#Sliverapprovalworkflow what to do if a sliver isn't auto-approved]. |
42 | | |
43 | | Most FOAM slivers will be auto-approved, but our main FOAM page has a section with [wiki:OpenFlow/FOAM#ManagingFOAMslivers commands for managing FOAM slivers], should you need to do that. You can also use GENI credentials of your own to create a sliver to play with, just to see first-hand how this works. |
44 | | |
45 | | When in doubt, feel free to ask the Infrastructure team at the GPO (gpo-infra@geni.net) -- we're always happy to help. |
46 | | |
47 | | FOAM will send mail to the FOAM admins and to experimenters when it does various things, such as when a sliver is created, approved, and deleted. You can generally skim these messages to make sure they don't contain anything unusual, and otherwise, archive them in case you ever need them later. There's also a nightly FOAM cron job that reports on "pending" slivers, i.e. anything that wasn't automatically approved; those generally reflect an experimenter who's waiting for resources, so please try to act on them expeditiously. |
48 | | |
49 | | FOAM has two places where e-mail is configured: The site.admin.email setting, which shows up in getversion output, and the configuration for administrative e-mail. http://groups.geni.net/geni/wiki/OpenFlow/FOAM#Othersettings includes instructions for changing the former, and `foamctl config:setup-email` is a simple way to change the latter if you need to. |
50 | | |
51 | | We have some [wiki:OpenFlow/FOAM#Initialconfiguration guidelines for FOAM configuration], which we encourage GENI sites to follow. If you're a rack admin, these should already be done as part of the rack setup process, but you can check for yourself if you're curious. |
52 | | |
53 | | As of 2013-07, the rack teams are responsible for deciding whether and when to schedule FOAM upgrades, so if you're a rack admin, you generally shouldn't upgrade FOAM except when advised by the rack teams. For other FOAM admins, the GPO will typically post to response-team@geni.net to recommend/request that sites upgrade. |
| 65 | As of 2013-12, the rack teams are responsible for deciding whether and when to schedule !FlowVisor upgrades, so if you're a rack admin, you generally shouldn't upgrade FV except when advised by the rack teams. For other FOAM admins, the GPO will typically post to response-team@geni.net to recommend/request that sites upgrade. |