[freeside-devel] Merge problems

[ivan]

i looked over ticket #332 again (for those following along at home: 
http://pouncequick.420.am/rt/Ticket/Display.html?id=332).

I assume you're talking about the second half of the ticket, wrt. export
changes.  While I'm unlikely to pick up the original requestor's idea of
"external scripts for each service definition", I did implement something
along these lines, except with "FS::part_export subclasses for each
service definition". 

Exports are now tied to a particular service definition (FS::part_svc),
have an arbitrary set of parameters and have hooks for
Insert/Update/Delete.  Using this framework, you could actually implement
a "runscript" export that *did* call external scripts for each function...

In any case, all the groundwork the export code rewrite has been
completed, and if you're at all interested in working on the export code
you should sync up to CVS and have a look.  The export code UI is done and
there are two "new-style" exports done and working ("ICRADIUS/FreeRADIUS
export and "InfoStreet" export).  The other "old-style" exports will be
moved over soon.

Some specific comments below:

On Tue, Mar 26, 2002 at 09:45:50AM -0800, Kristian Hoffmann wrote:
> I was looking at ticket #332 (Wish list/Ideas relating to svc_*), and was
> wondering how interested you were in doing something like that.  We are
> still trying to rewrite one of our major changes so it isn't such a kluge.
> Our biggest problem is finding a good way to export the service.
> 
> It's a two part service.  The first part is a layer 2 transport service,
> or svc_l2.  With all high speed internet connections these days, there is
> some sort of ethernet transport.  Wireless, DSL, CoLo, etc. are all fancy
> ways of distributing a bridged ethernet connection.  So, this service
> reflects the physical ethernet connection and information like where the
> connection was installed, what type of equipment was used, and how much
> bandwidth should be allowed over the connection.
> 
> The second part is the IP service, or svc_ip.  It keeps track of the MAC
> address and IP address of one, several, or a subnet of devices connected
> to the other side of the ethernet connection.
> 
> The first problem is with the svc_l2.  Different types of svc_l2's are
> necessary because of the different kinds of services available.  And each
> different type of svc_l2 needs it's own type specific fields in the
> database.  We are thinking about having tables like l2_wireless, l2_dsl,
> and l2_colo to store the type-specific information.  When you want to add
> a new type, you just add the tables and write your check functions to do
> data type checking and validation.  Comments?

Do you really think these differnt types of services are similar enough
that they shouldn't just have their own svc_ tables?  I'd be inclined to
just have separate svc_ types for these, perhaps each inheriting from
svc_L2_Common or something if there's code that can be shared.

> The biggest problem is exporting.  We've working out the IP address
> provisioning but that will take forever to go over.  Basically, there is a
> table of access concentrators (could be DSLAM, Wireless AP, ethernet
> switch), and a table of available IP subnets from which each access
> concentrator can allocate addresses.  So in theory, even for the same type
> of service, you could have a Cisco 1600 at one location, and a Nortel
> A92392, at another.  So, you would need different export scripts for each
> access concentrator. |Brick wall here|

Seems to me you could (with the new export code) use a different
svcpart (and thus be able to define different exports) for each of your
different devices.

> That brings me back to the ticket mentioned at the top.  We've been
> playing with the idea of setting up an event-based export system.  For our
> case, the code for doing Add, Replace, Delete, ... could each be stored in
> a table along with each access concentrator.  So when a service is
> modified, it would call a notify fucntion, passing itself, that would
> lookup it's AC and run the correct event code.  This could be generalized
> to any service with different event scripts being stored either in
> part_svc or in a way similar to the invoice event.
> 
> Comments Ivan, or anyone else?  We can't decide.

If I understand you correctly, sounds like the framework for what you're
looking for is done.  You just need to implement your specific exports in
the new framework.

-- 
_ivan