Nut upsdev - Nov 2008 - Opening the 2.4 commit fest (configuration files)

On Sun, Nov 16, 2008 at 11:08 AM, Arnaud Quette <aquette.dev at gmail.com>
wrote:
> 2008/11/15 Charles Lepple <clepple at gmail.com>:
>> On Fri, Nov 14, 2008 at 5:42 PM, Arnaud Quette <aquette.dev at
gmail.com> wrote:
>>> fellows,
>>>
>>> You can now commit to the trunk everything that is scheduled for
2.4
>>>
>>> For my part, the november month will be mostly dedicated to the
following:
>>> - commit the USB "improved maintenance" code. I'm
about to finish that
>>> one, which allows to extract USB info and generate the various USB
>>> related files (hotplug, udev and hal). so the end of that bothering
>>> era ^_^
>>> - complete & merge the upsdrv-info-struct branch
>>> - complete & merge the make-package branch
>>> - commit the PDUs support
>>> - some more update related to Eaton
>>
>> One thing that was on the plate (but we haven't discussed much) is
the
>> new configuration file format.
>>
>> I prefer that we keep the new configuration file code out of 2.4,
>> since there are a lot of other changes on the TODO list, and we
>> haven't really discussed it much. Also, there is the problem of
>> transitioning people to the new format - since a lot of the NUT users
>> get NUT from a Linux distribution, it will get confusing unless we
>> have some way to support both file formats.
>
> if you refer to Jonathan's work (newconf branch), then sure, it's
out
> of 2.4 scope (though it was initially in!)
Yes, that's what I was referring to.
> now, I'd like to make the bare minimum improvements there by providing:
> - a nut.conf file, whose sole purpose for now will be to store the
> configuration type (none, standalone (inc. redundancy), network server
> / client)
> this will help standardizing nut init and config over the distro, and
> the removal of /etc/default/nut, /etc/sysconfig/ups, ...
> - provide a basic upsconfig(.sh or .py?) with interactive and batch mode...
>
> that should fit in 2.4
It's ambitious, but if we are just wrapping the existing files, that
should be reasonable.

-- 
- Charles Lepple

2008/11/16 Charles Lepple <clepple at gmail.com>:
> On Sun, Nov 16, 2008 at 11:08 AM, Arnaud Quette <aquette.dev at
gmail.com> wrote:
>> 2008/11/15 Charles Lepple <clepple at gmail.com>:
>>> On Fri, Nov 14, 2008 at 5:42 PM, Arnaud Quette <aquette.dev at
gmail.com> wrote:
>>>> fellows,
>>>>
>>>> You can now commit to the trunk everything that is scheduled
for 2.4
>>>>
>>>> For my part, the november month will be mostly dedicated to the
following:
>>>> - commit the USB "improved maintenance" code. I'm
about to finish that
>>>> one, which allows to extract USB info and generate the various
USB
>>>> related files (hotplug, udev and hal). so the end of that
bothering
>>>> era ^_^
>>>> - complete & merge the upsdrv-info-struct branch
>>>> - complete & merge the make-package branch
>>>> - commit the PDUs support
>>>> - some more update related to Eaton
>>>
>>> One thing that was on the plate (but we haven't discussed much)
is the
>>> new configuration file format.
>>>
>>> I prefer that we keep the new configuration file code out of 2.4,
>>> since there are a lot of other changes on the TODO list, and we
>>> haven't really discussed it much. Also, there is the problem of
>>> transitioning people to the new format - since a lot of the NUT
users
>>> get NUT from a Linux distribution, it will get confusing unless we
>>> have some way to support both file formats.
>>
>> if you refer to Jonathan's work (newconf branch), then sure,
it's out
>> of 2.4 scope (though it was initially in!)
>
> Yes, that's what I was referring to.
>
>> now, I'd like to make the bare minimum improvements there by
providing:
>> - a nut.conf file, whose sole purpose for now will be to store the
>> configuration type (none, standalone (inc. redundancy), network server
>> / client)
>> this will help standardizing nut init and config over the distro, and
>> the removal of /etc/default/nut, /etc/sysconfig/ups, ...
>> - provide a basic upsconfig(.sh or .py?) with interactive and batch
mode...
>>
>> that should fit in 2.4
>
> It's ambitious, but if we are just wrapping the existing files, that
> should be reasonable.
exact. I don't plan to read existing files at first, only to warn/backup.

-- Arnaud