On Mon, Sep 06, 2010 at 03:09:33PM +0100, Guido Trotter wrote:
> On Mon, Sep 6, 2010 at 3:03 PM, Iustin Pop wrote:
>
> > Not true, because a 2.0 config file won't even be opened by a 2.1
> > ConfigWriter.
>
> Ok, this is fair enough, I wasn't arguing for this to happen.
Nod.
> > The *marking*
On Mon, Sep 6, 2010 at 3:03 PM, Iustin Pop wrote:
> Not true, because a 2.0 config file won't even be opened by a 2.1
> ConfigWriter.
Ok, this is fair enough, I wasn't arguing for this to happen.
>
> The *marking* of a config file as version x.y must be done via
> cfgupgrade from version x.y; t
On Mon, Sep 06, 2010 at 02:55:57PM +0100, Guido Trotter wrote:
> On Thu, Aug 26, 2010 at 4:29 PM, Iustin Pop wrote:
> > On Thu, Aug 26, 2010 at 16:05, Guido Trotter wrote:
> >> Until now this just meant that major upgrades could have more complex
> >> changes that were done with cfgupgrade, not t
On Thu, Aug 26, 2010 at 4:29 PM, Iustin Pop wrote:
> On Thu, Aug 26, 2010 at 16:05, Guido Trotter wrote:
>> Until now this just meant that major upgrades could have more complex
>> changes that were done with cfgupgrade, not that each and every change had
>> to be done that way, right? The must w
Am 27. August 2010 15:14 schrieb Manuel Franceschini :
> Resending with ssconf stuff omitted (based on ssconf patch before).
>
> tools/cfgupgrade | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
LGTM
Signed-off-by: Manuel Franceschini
---
Resending with ssconf stuff omitted (based on ssconf patch before).
tools/cfgupgrade | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/tools/cfgupgrade b/tools/cfgupgrade
index 00dbb22..f1df288 100755
--- a/tools/cfgupgr
On Thu, Aug 26, 2010 at 6:14 PM, Michael Hanselmann wrote:
>> Actually no. It is not a hard prerequiste, as in it won't stop the
>> daemon from starting. It can just not figure out which any address to
>> bind to and will default to 0.0.0.0. In the case of an upgrade from
>> 2.2 -> 2.3 this is ok,
Am 26. August 2010 18:03 schrieb Manuel Franceschini :
> On Thu, Aug 26, 2010 at 5:30 PM, Iustin Pop wrote:
>> On Thu, Aug 26, 2010 at 17:00, Michael Hanselmann wrote:
>>> Am 26. August 2010 15:53 schrieb Iustin Pop :
You don't need to to this, this is taken care via redist-conf, which
On Thu, Aug 26, 2010 at 5:30 PM, Iustin Pop wrote:
> On Thu, Aug 26, 2010 at 17:00, Michael Hanselmann wrote:
>> Am 26. August 2010 15:53 schrieb Iustin Pop :
>>> You don't need to to this, this is taken care via redist-conf, which
>>> will update all ssconf keys.
>>>
>>> What you need to do is w
On Thu, Aug 26, 2010 at 17:00, Michael Hanselmann wrote:
> Am 26. August 2010 15:53 schrieb Iustin Pop :
>> You don't need to to this, this is taken care via redist-conf, which
>> will update all ssconf keys.
>>
>> What you need to do is write out the updated version, that's all.
>
> Isn't the ssc
On Thu, Aug 26, 2010 at 16:05, Guido Trotter wrote:
> Until now this just meant that major upgrades could have more complex
> changes that were done with cfgupgrade, not that each and every change had
> to be done that way, right? The must was on the user side, not dev side.
IIRC we agreed and st
Am 26. August 2010 15:53 schrieb Iustin Pop :
> You don't need to to this, this is taken care via redist-conf, which
> will update all ssconf keys.
>
> What you need to do is write out the updated version, that's all.
Isn't the ssconf file required to start the daemons? This means it's a
requisite
Until now this just meant that major upgrades could have more complex
changes that were done with cfgupgrade, not that each and every change had
to be done that way, right? The must was on the user side, not dev side.
Thanks,
Guido
On 26 Aug 2010 14:53, "Iustin Pop" wrote:
On Thu, Aug 26, 2010
On Thu, Aug 26, 2010 at 15:46, Guido Trotter wrote:
> I'm wondering: do we need cfgupgrade for this or could it be done inside the
> upgrade config code done at each load?
No, the between-major upgrades must be done via cfgupgrade.
> Also, is it good to raise an error if
> we find the family rat
I'm wondering: do we need cfgupgrade for this or could it be done inside the
upgrade config code done at each load? Also, is it good to raise an error if
we find the family rather than just not add anything and be idempotent?
Thanks,
Guido
On 26 Aug 2010 14:17, "Manuel Franceschini" wrote:
Sign
Signed-off-by: Manuel Franceschini
---
tools/cfgupgrade | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/tools/cfgupgrade b/tools/cfgupgrade
index 00dbb22..b200c73 100755
--- a/tools/cfgupgrade
+++ b/tools/cfgupgrade
@@ -32,6 +32,7 @@ import os.
16 matches
Mail list logo