[freeside-devel] svc_broadband refactor

[Richard Siddall]

Jeff Finucane wrote:
> freeside-devel:
> 
>   Should address information be stored in svc_broadband or is it time for
> FS::address?  
> 
>   The proposal at present calls for speed_down_mir, _cir, and corresponding
> speed_up_*.  What of 802.1D/802.1P without 802.1q (or similar possibilities
> stated at layer3)?  In particular, Motorola Canopy SMs allow for setting
> MIR and CIR separately for 'priority' and 'standard' traffic.  A list
> could provide the reservation information for each of the priorities
> any particular device allows.
> 

Jeff,

Guessing you mean FS::ip_address (ISA FS::net_address?) and not 
FS::street_address, I'd say yes.

Bear in mind that I don't work with broadband at the moment.  However, 
I'd guess that we want to:

1/ Enter IP address blocks into Freeside only once.
2/ Automate allocation of addresses to broadband customers and web 
hosting customers.  This probably means having an extensible class 
hierarchy to accommodate different allocation algorithms.
3/ Obviously, keep track of which IP addresses have been allocated to 
which objects (routers, Canopy Subscriber Modules, DHCP servers, hosting 
servers, etc.)
4/ Deallocate addresses back into a pool when a customer cancels, etc.

I suspect that the svc_broadband class will encounter the same problems 
as the svc_acct class, namely there's a growing list of attributes that 
you need in some cases, but are confusing if you mandate them for all 
uses.  (In svc_acct, there are some cases where you need just the 
password, others where you need username and password, still others 
where you need username, password, UID/GID, GECOS, etc., others where 
you need username, password, RADIUS realm, RADIUS groups, etc.)

If you meant FS::street_address, then I'd agree with Jayce that there 
are some times when the 1-to-1 customer to address mapping doesn't cut 
it.  For example, selling high speed lines there are plenty of cases 
where the customer has more than one service address.

Regards,

	Richard Siddall