Moving filesystem-centric code?

[kula]

I'm looking at adding support for Consul (a distributed key-value store, although Consul has a bit more in it) as a backend for reclass. The storage layer looks to make this fairly easy, so I don't think it will be much work, but some of the other code in reclass assumes that your backend is filesystem-centric --- for example, in config.py the get_options function sets various options based on what's in a filesystem.

I wanted to start a discussion about if it everyone would be amenable to a refactor (and what that refactor would look like) that would put the filesystem-centric bits of the code down in the storage module. Some parts will be a bit messy, I think, so I wanted to talk about it first.

[madduck]

Hey, I completely agree, it's not nice and I've been trying to find time for a refactor for months.

Basically, I think it'd be ideal if each storage module exported its own configuration settings so that config.py would only honour e.g. --base-uri only if the yaml_fs backend was in use, e.g.

./reclass.py --storage yaml_fs --help
…
./reclass.py --storage yaml_fs --base-uri …
…

But

./reclass.py --storage consul --base-uri …
Error: --base-uri: unknown option

[lottspot]

With the proliferation of k/v stores, this seems like a worthy feature. I'd like to be able to roadmap this eventually once we've had more time to plan out our next steps.