Adding devel list
On Thu, Aug 21, 2014 at 9:01 AM, Louis Munro <notificati...@github.com>
wrote:
> Speaking to others here, I may be the old fuddy-duddy unix greybeard
> (without the beard, but still...).
> My love of text files is not universally shared it would seem.
>
> I wish other would speak up about this. I think it's worth discussing.
> In any case, the support tools would have to be written and tested well
> before we move everything to the database.
> pfcmd is still a work in progress in that respect I believe.
>
> To be frank, I am not sure this is the most critical thing keeping us from
> having an active/active HA setup, which I think is the ultimate goal here.
> We already know how to have an active/passive setup even though there may
> be room for improvement there too.
>
> What I see as things to fix first is the issue of services running on
> every
> node of the cluster when they might conflict:
> active/active dhcp (with shared list of leases between nodes),
> active/active dhcplistener (currently may cause database issues if running
> more than one simultaneously), SNMP traps, iptables and ipsets in inline
> mode etc.
>
> Some of them require rewriting a service (DHCP), while others require that
> we decide how to deal with devices that may only send packets to a single
> IP (SNMP in the case of some switches).
> Do we use a virtual IP for the cluster? That's one more thing to manage,
> one more thing that can fail.
>
> Fixing some of these issues would at the same time make an active/passive
> setup easier, so the benefits may be compounded and a valid strategy may
> be
> to do this incrementally until full active/active HA is acheived.
>
> None of these issues are unsolvable. I am not trying to belittle the idea,
> in fact in think it's a worthwhile goal.
> But we should not underestimate the tradeoffs and choices it will entail,
> and operability should remain a primary concern.
>
> Ok, rant off :-)
> Please do chime in people...
>
> L.
>
>
>
> On Wed, Aug 20, 2014 at 11:31 AM, mullagain <notificati...@github.com>
> wrote:
>
> > I can see your points, but support tools could be written to gather the
> > same information. Also automation becomes much more predictable and
> > manageable when you move to a DB, not to mention data consistency. Plus
> > with the goal of active/active flat files become less than ideal.
> >
> > I asked the question because I have written several
> > network(switch/router/ap/controller) discovery engines over the years at
> > different companies. It would be incredibly easy for me to create one
> for
> > pf, but these systems use a database and managing/syncing the db to a
> flat
> > file could become cumbersome. I am not even sure if there is an interest
> in
> > a discovery engine, but it sure would make managing the switches
> easier...
> > because it would be fully automated.
> >
> > If there is an interest in this, I contend that a single data source
> would
> > be needed, A flat file is not the answer for network discovery or any
> type
> > of automation.
> >
> > Also, support tools could be created to gather troubleshooting
> information.
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <
> https://github.com/inverse-inc/packetfence/pull/213#issuecomment-52795433>
>
> > .
> >
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/inverse-inc/packetfence/pull/213#issuecomment-52923518>
> .
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
PacketFence-devel mailing list
PacketFence-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-devel
