Re: Some semi-architectural things to think about

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jesus M. Rodriguez wrote:
Adrian Likins wrote:
By DB, I mean of course something like bsddb or even a config file, not an actual DB :)
Hrm. Is the config enough? How small are these groups? If we go with
a DB, anything that SQLAlchemy can use would be fine with me. That way
when func gets big and needs a REAL DB it would be easier to switch
and not have to gut a lot of code.

    Ugh. What do we forsee func needing a REAL DB for? I'd like to
avoid that at pretty much any cost.

World domination which requires the bullet point of a REAL DB :)
Someone will inevitably will ask "will it work with Oracle? or Postgres?..." "I have 10,000 groups will it scale".


The strategy here should be (as someone else brought up) YAGNI. If we need it, we'll do it. The Func globbing system does not need a DB, and even so, the groups features can represent 10k w/o a DB regardless of storage.

Would an evolved Func-inventory that turned into a fancy webapp eventually want to storage something in a DB? Maybe, but if so that could go in the app using Func, not the DB.

What would you see the need to put in a DB? I can't think of anything ATM.

Just saying that if we go the DB route, choose SQLAlchemy to
minimize the work in the future.

Sure.

And my question wrt to config is that I've never thought of
using a config for storing things *from* an application aside
from configuration properties needed to run the system.  As far
as application data such as "system groups", I'd naturally reach
for a DB.  Not saying I'm right, just trying to understand how
it will work.


Groups will just be a shorthand from having to saying "mailservers*,alpha,beta,webservers*"
on the command line.

Since this is going to be expanded to an in-memory list by the Client module anyhow, I don't see the storage
of that being a bottleneck.

The network side IMHO is the interesting part, and for scaling there, that's about multi-process, async, and possibly overlord-chaining. And of course minion-to-minion to minimize the need for everything to go through one box.

Other than the certs, func doesn't save much state at all... the apps using the Func API (like inventory for intstance) may.

Sound reasonable?

--Michael

_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux